From my initial testing, it appears that a fieldset's "form" attribute does not get passed to child controls.
I can't tell if I've got a different issue, or if that's the way fieldset is supposed to work. Seems like a fairly useless attribute on fieldset if so...
<body>
<section>
<form id="separate-form"></form>
</section>
<fieldset form="separate-form">
<input type="text" value="this doesn't get submitted to #separate-form ?">
<button>submit</button>
</fieldset>
</body>
As of April 2018, and testing on Chrome/Firefox, it seems as the though the answer is "No". A fieldset's form attribute does NOT apply to its child controls.
I had to iterate through all form elements setting the attribute for each.
Related
According to the developer.mozilla.org's description of the "form" attribute of an "input" element,
If this attribute isn't specified, the element is associated
with the nearest containing form, if any.
I struggle to understand what is that supposed to mean. If an "input" element, outside a "form" container, does not have a "form" attribute, it will simply not be connected in anyway to that form. How exactly is it going to get "associated with the nearest form container"? I don't understand what they mean by this.
Can anybody explain?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#htmlattrdefform
If an "input" element, outside a "form" container, does not have a "form" attribute, it will simply not be connected in anyway to that form.
Your understanding is correct. An <input> which is not contained within a <form> will not by default be associated with any <form>, and thus won't be included when submitting any <form>. For example, this <input> isn't part of any <form>:
<input name="test" />
<form>
<!-- other inputs, etc. -->
</form>
But this one is:
<input name="test" form="myForm" />
<form id="myForm">
<!-- other inputs, etc. -->
</form>
How exactly is it going to get "associated with the nearest form container"?
That's not what the documentation you're reading says. It's a small but important distinction (emphasis added):
If this attribute isn't specified, the element is associated with the nearest containing form, if any.
So if the <input> is contained within a <form> then it doesn't need to specify. For example, this <input> isn't part of any <form>:
<input name="test" />
<form>
<!-- other inputs, etc. -->
</form>
But this one is:
<form>
<input name="test" />
<!-- other inputs, etc. -->
</form>
By "nearest" containing form it's likely indicating that nested <form> elementss are legal, and the <input> will by default be associated only with the closest ancestor <form>. Though nested <form> elements sounds to me like a recipe for confusion. Allowed and useful in edge cases, but in the vast majority of cases really not necessary.
The "nearest" in "nearest containing form" may just be redunant. The <input> should only exist within a single ancestor <form> element.
I just noticed an interesting way of placing input elements outside of form tag today.
<html>
<!-- the form element -->
<form id="testform" method="post" action="index.asp">
<label for="text1">Text: </label>
<input type="text" id="text1" name="text1" />
<button type="submit">Submit</button>
</form>
<!--- element outside form tag -->
<label for="text2">Additional Text: </label>
<input type="text" id="text2" name="text2" form="testform" />
</html>
I am just wondering if it is common to practice to do this. Should this method be avoided?
Tried googling for similar discussions but i really don't know how to phrase this.
It is not common practice. In most cases, it offers no benefits but has a drawback: some old browsers do not support the form attribute, so things just don’t work on them.
An input element outside a form element has always been permitted. Such an element just won’t participate in any form submission, if it has no form attribute. But it can be used with client-side scripting.
The form attribute associates, in supporting browsers, the element with a form just as if the element were inside the form. This can be useful in complicated cases where e.g. one row of a table should contain fields of a form, another row fields of another form, etc. You cannot wrap just one row inside a form, and here the attribute comes to rescue: you put a form element inside one cell of the row and refer to that element in fields in other cells with the form attribute.
Yes, you can definitely do this as of HTML5, using the form attribute on inputs that are located outside the form element; just like you did.
For more details and examples, see HTML <input> form Attribute at W3 Schools.
There is nothing wrong with putting them there, and they will be available within the DOM if you are doing something with javascript, etc. but when you submit the form, the values of your fields will not be in the results submitted.
yes you can put input element outside the form but how would you decide how and where you 're going to post values of these elements.
I have a form with a set of inputs, and I want my page to refresh when one of them changes. I have a second set of inputs on the OTHER side of the page, and the css layout doesn't make it convenient for me to put them in the same <form> </form> tag. I was wondering if there is a way that I can make sure those "inputs" that are located outside of the <form> tag are still associated with that form.
Is there some way we can assign a "form id" to the inputs?
In HTML5, you can use the form attribute:
A form-associated element is, by default, associated with its ancestor form element, but may have a form attribute specified to override this.
If a form-associated element has a form attribute specified, then that attribute's value must be the ID of a form element in the element's owner Document.
Example:
<form id="myform">
<input id="something" type="text">
</form>
<button form="myform" type="submit">Submit that form over there</button>
You should however make sure that it is clear to the user that these visually separated form elements are in fact connected.
<input type="text" form="myform" /> worked for me.
Update
This worked great with FireFox, however gave me trouble in IE 11 as the form attribute is not recognized with IE (as of writing this).
I had to just set a hidden input field inside the form, and transferred value to hidden input field from input outside form; with onclick using jQuery.
<input class="checkbox" id="staff_recruiting" name="company_type"
value="staff_recruiting" type="checkbox">
<input type="hidden" value="all" name="keyword" id="search-keyword-input">
$('#search-keyword').keyup(function() {
$('#search-keyword-input').val($(this).val());
});
Your problem will be solved bro:
Add a hidden input field in your form.
Using jQuery or JS to change that hidden input field value with that outside input box.
Your page will refresh and your outside box value will be grabbed.
Can I use the <caption> tag inside a form ? If not, why not?
Example:
<form>
<caption>description</caption>
<label>name:</label>
<input />
</form>
Have you actually tried it first?
Answer: no. (Well, you can, but it would break standards).
The <caption> element is used to caption a table, not a form.
Alternative solution:
If you really want to caption forms, simply add a valid element that can be styled with CSS to it, like so:
<form>
<div class="caption">This is my form caption</div>
<input .../>
</form>
Another approach, that would probably be more semantically correct, would be to use a <fieldset> to group your form:
<fieldset>
<legend>This is my form caption</legend>
<form>
<input .../>
</form>
</fieldset>
You are looking for the <legend> tag, perhaps?
No, the caption element pertains specifically to tables. One may argue it's a strange case of omission on part of whoever helped make HTML what it is today, but be it as it may, it cannot be used with forms. Furthermore, there are semantical implications of trying to use caption for a form, since it captions tables and not forms.
The idiomatic way to "caption" or "head" content in HTML, including announcing forms and form content, is to use the heading tags h1, h2 etc. These are generic with regard to what they help announce and you may therefore well precede or nest these within a form element.
In your case you would then have:
<form>
<h1>description</h1>
<label>name:</label>
<input />
</form>
or you could also put the heading element directly preceding the form element:
<h1>description</h1>
<form>
<label>name:</label>
<input />
</form>
I think the former is more semantically applicable, but sometimes certain factors like abilities of CSS, will necessitate use of the latter. Either should be valid, regardless.
Alright, I know how the fieldset/legend works out in HTML. Say you have a form with some fields:
<form>
<fieldset>
<legend>legend</legend>
<input name="input1" />
</fieldset>
</form>
What should I use the legend for? It's being displayed as a title, but isn't a legend semantically an explanation of the contents? In my view, preferably you'd do something like this:
<form>
<fieldset>
<legend>* = required</legend>
<label for="input1">input 1 *</label><input id="input1" name="input1" />
</fieldset>
</form>
But that doesn't really work out with how fieldsets are rendered. Is this just a ambigious naming in HTML, or is it my misunderstanding of the English word 'legend'?
Edit: fixed some errors ;-)
Yes, the naming is ambiguous. It’s best to consider it as a caption for the fieldset.
See the HTML spec on FIELDSET and LEGEND elements if you haven’t already:
The LEGEND element allows authors to assign a caption to a FIELDSET. The legend improves accessibility when the FIELDSET is rendered non-visually.
I guess you meant to write
<form>
<fieldset>
<legend>legend</legend>
<input name="input1" />
</fieldset>
</form>
but you're right in part. The word legend has several meanings including
An explanatory caption accompanying
an illustration.
An explanatory
table or list of the symbols
appearing on a map or chart.
So it can in fact mean both.
When you say that the legend "It's being displayed as a title".. clearly it depends on the CSS involved. When you don't specify CSS yourself, each browser uses its own built-in styles, which may or may not be the best thing ever.
I agree that a legend is different than a title... I don't necessarily think that the legend is the right place for something like "* = required" (that seems just a cautionary piece of information for the user, not really an explanation of the fieldset itself).
A legend, after all, can be defined as a caption, or brief description accompanying an illustration (usually; something other than an image in this case).
As far as how it gets displayed, again, CSS gives you power to make it appear (or not) as you see fit.
Think of the legend as a title of a groupbox. You use it to group similar form elements together. You could have all of the input fields for a shipping address in one fieldset with a legend of "Shipping Address" and the set of all input fields for a billing address in another fieldset with a legend of "Billing Address".
Here's an example:
Fieldsets in Skiviez Checkout http://piasecki.name/fieldset-legend-example.jpg
They can be tricky to style via CSS (because Internet Explorer displays the background of the fieldset incorrectly. Our IE stylesheet has some good examples; look in the "#content form fieldset" section.
The <legend> element is the semantic equivalent of a "headline" or "title" for the group of form controls contained by the <fieldset>.
The FIELDSET element allows authors to group thematically related controls
which means fieldsets should group together several form controls -- not just a single pair of <input> and <legend>.
In fact <div>s, <p>s, or <li>s are quite suitable containers for <input> + <legend> pairs.