If I have a SELECT tag that will filter a table based on a user choice, does the SELECT tag need to be in a FORM tag (to be valid HTML5), if the resulting functionality will not work if JS disabled (i.e. we'll show the entire table or a 'more' link instead of doing a server-side filter on select of the form action/submit option (We may write the select in JS so it disappears from the markup if JS disabled.
Or do all form elements need to be in a form tag regardless of usage (and therefore a null 'action' attribute value).
I know HTML5 allows almost anything, I just couldn't find a definitive answer on W3, so thought I'd get your thoughts. Hope that makes sense.
Cheers.
All the form controls can be used anywhere where phrasing content is expected, which means they can appear just about anywhere in the body of the document. If you don't need to have them submitted back to a server then there's no need for them to be associated with a form, however I've noticed that in some browsers you can't take advantage of the form validation features unless the elements can potentially be submitted.
One feature new to HTML5 is that form controls no longer need to be the direct child of a form element in order to be submitted with that form, the form attribute allows you to specify the id of the form the element should be submitted with.
It would appear that in HTML5 form elements can be outside of a <form> tag and still be valid;
<!DOCTYPE html>
<html>
<head>
<title>Just making this valid</title>
</head>
<body>
<select>
<option value="1">One</option>
<option value="2">Two</option>
<option value="3">Three</option>
</select>
</body>
</html>
The above code validates successfully (minus the obvious character encoding errors).
I haven't read the entire HTML5 Spec, however the validator is usually correct on these sorts of matters.
The HTML5 spec specifically allows <input>s (and other form-associated elements) not to have a <form>:
A form-associated element can have a relationship with a <form> element, which is called the element’s form owner. If a form-associated element is not associated with a <form> element, its form owner is said to be null.
So feel free to use them wherever your heart desires!
Related
I am using the Facelet Templating Technology to layout my page in a JSF 2 app that I am working on.
In my header.xhtml, primefaces requires that menubar be enclosed in h:form.
<h:form>
<p:menubar autoSubmenuDisplay="true">
Menu Items here!
</p:menubar>
</h:form>
So, in my contents pages, I will have another h:form or more.
Will it just work if I just place the h:form in my template.xhtml?
<h:body>
<h:form>
<div id="top">
<ui:insert name="header"><ui:include src="sections/header.xhtml"/></ui:insert>
</div>
<div>
<div id="left">
<ui:insert name="sidebar"><ui:include src="sections/sidebar.xhtml"/></ui:insert>
</div>
<div id="content" class="left_content">
<ui:insert name="content">Content</ui:insert>
</div>
</div>
<div id="bottom">
<ui:insert name="footer"><ui:include src="sections/footer.xhtml"/></ui:insert>
</div>
<h:form>
</h:body>
I am actually thinking of a use case where I need multiple h:form in a page.
Thanks
You can safely use multiple forms in a JSF page. It's not different than when using plain HTML.
Nesting <form> elements is invalid in HTML. Since JSF just generates a bunch of HTML, it's not different in JSF. Nesting <h:form> is therefore also invalid in JSF.
<h:form>
...
<h:form> <!-- This is INVALID! -->
...
</h:form>
...
</h:form>
The browser behavior as to submitting a nested form is unspecified. It may or may not work the way you expect. It may for instance just refresh the page without invoking the bean action method. Even if you move the nested form (or a component that contains it) outside of the parent form with dom manipulation (or by e.g. using the PrimeFaces appendTo="#(body)"), it still won't work and there should be no nested forms at time of loading the page.
As to which forms you need to keep, having a single "god" <h:form> is actually a poor practice. So, you'd best remove the outer <h:form> from the master template and let the header, sidebar, content etc sections each define its own <h:form>. Multiple parallel forms is valid.
<h:form>
...
</h:form>
<h:form> <!-- This is valid. -->
...
</h:form>
Each form must have one clear responsibility. E.g. a login form, a search form, the main form, the dialog form, etc. You don't want to unnecessarily process all other forms/inputs, when you submit a certain form.
Note thus that when you submit a certain form, other forms are NOT processed. So, if you intend to process an input of another form anyway, then you've a design problem. Either put it in the same form or throw in some ugly JavaScript hacks to copy the needed information into a hidden field of the form containing the submit button.
Within a certain form, you can however use ajax to limit the processing of the inputs to a smaller subset. E.g. <f:ajax execute="#this"> will process (submit/convert/validate/invoke) only the current component and not others within the same form. This is usually to be used in use cases wherein other inputs within the same form need to be dynamically filled/rendered/toggled, e.g. dependent dropdown menus, autocomplete lists, selection tables, etc.
See also:
commandButton/commandLink/ajax action/listener method not invoked or input value not set/updated - point 2
What is <f:ajax execute="#all"> really supposed to do? It POSTs only the enclosing form
Understanding PrimeFaces process/update and JSF f:ajax execute/render attributes
<p:commandbutton> action doesn't work inside <p:dialog>
I was confounded by this issue for a while. Instead of a series of independent forms, I converted to a template, that is, rather than making a call to a xhtml with listed forms, usually as ui:include, I make a call to those formerly ui:included xhtml pages that ui:content captured in a parent template.
I wonder the difference between:
<form method="post" action="">
and
<form method="post" action=".">
I have read this interesting thread. It looks like blank action is handled by all browsers. Some say the period is not a good idea but they don't say why.
Furthermore, this thread is quite old now so i think it would be useful to have an update on the subject.
Thanks.
The blank represents that the result display of the form will display within the same page. Let say if you input the name, address, tel # etc.... and press the submit button. The collected information will display within the same page (probably below the form). I usually do this when i design a form to make sure it works. But there are various reason why they leave it blank instead putting another target page.
In my application I have back end code as perl and front end development using jquery mobile. When I submit a form on jqm page using the variables x=10 y=20, in the query string instead of replacing the parameters like jqm.com/?x=10&y=20 I get it appended as
jqm.com/ id=1000&x=10&y=20. Again I change my values and submit the form I get
jqm.com/?id=1000&x=10&y=20&id=1000&x=newvalue&y=newvalue
You have this problem because you haven't specified an action attribute in your form. So, by default, it'll send the data to the page itself, thus you have the parameters appended to the current page url every time.
To fix this problem, simply add the action attribute like the following example:
<form action="a-page-to-send.php" method="post">
<!-- code goes here -->
</form>
I've got a standard HTML form, which is split into two sections using fieldset elements. One section is to enter name, email address etc and the second section is to enter the postcode for an address auto-complete feature (the postcode lookup field in the second section does not have a required attribute).
Each section has its own submit button. Each of the fields in the first section has a form field with a HTML5 required attribute.
My question is, when a user enters their postcode into the postcode lookup field without entering anything in the first section, all fields in the form are submitted in browsers which don't support this attribute (e.g. Firefox 3.6). In Firefox 4 (for instance), it honours the required attribute and prevents submission of the form if there are empty fields with a required attribute. However, this breaks my implementation of the error-checking and validation of the form (server-side, in PHP).
So, is there a way of being able to tell the browser to (in this case) ignore the "required" attributes of the first section when the submit button of the second section is pressed?
I understand this may be going against the point of the required attribute, but I've built the form so it doesn't have to be completed in a certain order, i.e. A user may choose to complete the postcode lookup field before entering their personal details, but the required attribute is currently forcing the user to complete the form in a certain way, when it isn't necessary to do that.
Also, any solution must be able to work without JavaScript. Please don't mention any answers advocating replacing the postcode lookup section with Ajax, it has been decided for me that this is not an allowed option.
I think I see your problem. I don’t believe there’s anything in HTML that lets you specify this more complicated validation rule. I think you’ll have to either:
Split these fieldsets out into two separate forms on the page;
Use two separate forms on two different pages; or
Re-write your server-side code so that the non-postcode form fields only include the required attribute when the user has submitted a postcode.
Is there any nested form in your page?. first form tag not work in nested forms like below. in that case use empty form tag to avoid error. and also do not write class with form tag starting like form.filed{}
<form>
main form
<form> </form>
<form> form1 </form>
<form> form2 </form>
</form>
I am wondering if anyone can give a "best practices" response to using blank HTML form actions to post back to the current page.
There is a post asking what a blank HTML form action does here and some pages like this one suggest it is fine but I'd like to know what people think.
The best thing you can do is leave out the action attribute altogether. If you leave it out, the form will be submitted to the document's address, i.e. the same page.
It is also possible to leave it empty, and any browser implementing HTML's form submission algorithm will treat it as equivalent to the document's address, which it does mainly because that's how browsers currently work:
8. Let action be the submitter element's action.
9. If action is the empty string, let action be the document's address.
Note: This step is a willful violation of RFC 3986, which would require base URL processing here. This violation is motivated by a desire for compatibility with legacy content. [RFC3986]
This definitely works in all current browsers, but may not work as expected in some older browsers ("browsers do weird things with an empty action="" attribute"), which is why the spec strongly discourages authors from leaving it empty:
The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces.
Actually, the Form Submission subsection of the current HTML5 draft does not allow action="". It is against the spec.
The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces. (emphasis added)
The quoted section in mercator's answer is a requirement on implementations, not authors. Authors must follow the author requirements. To quote How to read this specification:
In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example Web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.
The change from HTML4—which did allow an empty URL—was made because “browsers do weird things with an empty action="" attribute”. Considering the reason for the change, its probably best not to do that in HTML4 either.
Not including the action attribute opens the page up to iframe clickjacking attacks, which involve a few simple steps:
An attacker wraps your page in an iframe
The iframe URL includes a query param with the same name as a form field
When the form is submitted, the query value is inserted into the database
The user's identifying information (email, address, etc) has been compromised
References
Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution
This will validate with HTML5.
<form action="#">
IN HTML 5 action="" IS NOT SUPPORTED SO DON'T DO THIS. BAD PRACTICE.
If instead you completely negate action altogether it will submit to the same page by default, I believe this is the best practice:
<form>This will submit to the current page</form>
If you are sumbitting the form using php you may want to consider the following. read more about it here.
<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">
Alternatively you could use # bear in mind though that this will act like an anchor and scroll to the top of the page.
<form action="#">
I think it's best to explicitly state where the form posts. If you want to be totally safe, enter the same URL the form is on in the action attribute if you want it to submit back to itself. Although mainstream browsers evaluate "" to the same page, you can't guarantee that non-mainstream browsers will.
And of course, the entire URL including GET data like Juddling points out.
Just use
?
<form action="?" method="post" enctype="multipart/form-data" name="myForm" id="myForm">
It doesn't violate HTML5 standards.
I used to do this a lot when I worked with Classic ASP. Usually I used it when server-side validation was needed of some sort for the input (before the days of AJAX). The main draw back I see is that it doesn't separate programming logic from the presentation, at the file level.
I use to do not specify action attribute at all. It is actually how my framework is designed all pages get submitted back exact to same address. But today I discovered problem. Sometimes I borrow action attribute value to make some background call (I guess some people name them AJAX). So I found that IE keeps action attribute value as empty if action attribute wasn't specified. It is a bit odd in my understanding, since if no action attribute specified, the JavaScript counterpart has to be at least undefined. Anyway, my point is before you choose best practice you need to understand more context, like will you use the attribute in JavaScript or not.
When you put empty action then some security filtration consider it malicious or phishing. Hence they can block your page. So its advisable not to keep action= blank.