Is it valid to have <input> without it being in a <form>?
Have a process for marking up some fields in pages and just found a page with input fields that where not being marked up as I expected.
It's taken me a while but worked out that the process of getting the form elements then getting the fields is what caused these to be missed because there is no form.
<input> without a <form> appears valid, yes (at least for html 4.01, look near the end of 17.2.1):
The elements used to create controls
generally appear inside a FORM
element, but may also appear outside
of a FORM element declaration when
they are used to build user
interfaces. This is discussed in the
section on intrinsic events. Note that
controls outside a form cannot be
successful controls.
I checked the following with the W3C validator and it confirms this is valid.
<!DOCTYPE html>
<html>
<head>
<title>test</title>
</head>
<body>
<input type='text' />
</body>
</html>
Reference to a more up-to-date specification:
HTML 5.2 - W3C Recommendation (14 December 2017)
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.
According to MDN it is possible:
Note that it's always possible to use a form widget outside of a element but if you do so, that form widget has nothing to do with any form. Such widgets can be used outside a form, but then you should have a special plan for such widgets, since they will do nothing on their own. You will have to customize their behavior with JavaScript.
HTML5 introduces the form attribute on HTML form elements. It should let you explicitly bind an element with a form even if it is not enclosed within a form tag. Unfortunately, for the time being, the implementation of this feature across browsers is not yet good enough to rely on it.
I know this question is quite old, however, I have successfully built many complex data entry pages without form tags. Although it isn't considered "standard" by many, it is NOT inappropriate to use inputs without a <form>. My projects were instances where I needed complete control over how the page behaved and the default form behavior was getting in the way. Was able to perform page and field level validation ( using JS ) and "submitted" the data with Ajax calls etc...in fact, this is my preferred way these days.
Lots of JS is required, but its not that difficult and is easily done as reusable code.
There are also other instances where I def do NOT use forms with inputs such as Login Pages.
Hope this testimonial helps someone.
in my point of view , we can use input outside the form and even send data to the server without put the input in the form ,but for SEO and website readability(for visually impaired people)(just the same reason for the some
semantic content tags in HTML5 , like section ,footer, header something like that ), we have to use input in the form tag.It is important that we ensure the code we use is available to all people including the visually impaired people because it is not just about websites, it is about providing access to information for everyone.
Yes, you can have a valid input without a form.
Related
I have a question about correct nesting and syntax with using form element in HTML. I understand basics but is it okay to put there divs, paragraphs, spans, etc.? Because using nice CSS need sometimes more elements and because I am front-end learner I am not sure if these elements inside form influence some data and inputs. If you have some examples of using very advanced HTML in forms I would really appreciated some already used HTML real examples. Also if you can explain how it works with data collecting from forms, it could also help me understand this nesting.
Btw: is it important to have button inside the form or it can be outside this element?
Thans for any answer.
First place to go when you want to know anything about HTML/CSS and JavaScript in the browser is MDN. In your case: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Form
As you can see there, forms can indeed include any types of elements (a <form> behaves like a <div> for all visual design purposes), except for nested <form> elements
Data collection for a form is typically (as in plain HTML/HTTP) made by sending a request to the URL given in its action property. How this request is exactly formed can be controlled through the use of attributes method and enctype.
Basically, the request body (for POST) or query string (for GET), will contain all data inside the form as key/value pairs, where the keys are the name attribute of the input fields, while the value is their value attribute.
This can vary a little depending on field type. For instance a <textarea> will send its text contents as a value instead.
The sending of this request (and browser navigation) is triggered when the user clicks a submit button on the form (either <input type="submit"> or <button>). This is called submitting the form.
is it okay to put there divs, paragraphs spans etc.
Yes, that's perfectly fine.
is it important to have button inside the form or it can be outside this element?
You can have a button outside of a form - depends on what functionality you are trying to achieve.
If you have some expamle of using very advanced html in forms
Your question is quite basic so I don't know how much of an advanced example you are looking for, but you can find examples of css classes being used with forms on this Bootstrap 5 tutorial (Bootstrap is a CSS library/framework): https://getbootstrap.com/docs/5.0/forms/layout/
I have read that the role attribute was added to Bootstrap for accessibility, and I would like to know how <form role="form"> helps accessibility. See http://getbootstrap.com/css/#forms-example for an example of this specific usage.
I searched Bootstrap's repo for "role" to no avail.
My issue is that the information seems redundant. The notion that the element is a form is already expressed by the HTML tag itself (<form>), so what does it help if we also add that the element is playing the role of form? It would make sense to add role="..." if role was going to be different than form (I don't know what - but let's pretend); as it stands (especially without concrete reasoning / use case examples), it is puzzling at best.
If you add a role="form" to a form, a screen reader sees it as a region on a webpage. That means that a user can easily jump to the form with his/her region quick navigation keys (for example, in JAWS 15 you use R for this). And also, your user will be able to easily find where the form starts and ends because screen readers mark start and end of regions.
I'd like to point out that the article #user664833 mentioned in a comment states that role="form" shouldn't go on <form> elements, but rather on a <div> or some other element which does not semantically indicate that it contains form elements.
The <form> element is probably already handled properly by modern screen readers.
Quote (link):
Recommend using [role="form"] on a semantically neutral element such as a <div> not on a <form> element, as the element already has default role semantics exposed.
In fact, the ARIA 1.1 W3C recommendation states clearly one should not change the host language semantics in section 1.4 (source):
"It is not appropriate to create objects with style and script when
the host language provides a semantic element for that type of object.
While WAI-ARIA can improve the accessibility of these objects,
accessibility is best provided by allowing the user agent to handle
the object natively."
So, writing <form role='form'> is not only redundant but against the recommendation.
Semantically speaking, a form by default is, well, a form. However, not all accessibility applications(screen readers, etc) are designed the same and some can use elements (even the form element) with the role=form attribute differently even if they understand that the parent form element will have the same semantic meaning with or without the role=form attribute.
My question stems from the context of a web application, rather than a web page. In that context it often does not make any sense to submitt data. You want to modify state in your application using controls.
To me, it then does not make any sense to use a form. However I still need controls/widgets to modify. Meaning I need tags such as input, which I understand is a "form control", indicating that they should always be contained inside a form. Furthermore I want to organize my controls in fieldset tags.
So I was left wondering if I now have to wrap all of my controls in form-tags, even though this to me seems symantically incorrect (since I'm not going to submit).
After a few quick searches I found the two following two breif forum discussions on topic:
http://www.webmasterworld.com/forum21/8837.htm
http://doctype.com/can-fieldset-outside-form
To sum them up, using form controls outside of a form will validate on w3c. However rendering might not work in really old browsers (like Netscape 4, which I really don't care about.)
In the first link there seems to be support for using form controls outside of forms as the symantically correct thing to do in my sort of scenario. However in the other it seems that using fieldsets should strictly be done within a form when caring about being symantically correct.
Does this mean I should feel free to use controls outside of forms, but I must wrap them in divs rather than fieldsets, or should I read this some other way?
The w3c states:
17.2.1 Control types
The elements used to create controls generally appear inside a FORM element, but may also appear outside of a FORM element declaration when they are used to build user interfaces. This is discussed in the section on intrinsic events. Note that controls outside a form cannot be successful controls.
17.10 Adding structure to forms: the FIELDSET and LEGEND elements
The FIELDSET element allows authors to group thematically related controls and labels.
17.10 doesn't make any mention of the form element, to me this means that there is no limitation on where it can be used except that it should surround controls and labels. 17.10.2 Seems to allow me to use those outside of a form. Hence I can also use the fieldset outside of a form, as long as it wraps controls and labels.
I have come across use cases where I have required to have form controls without the need for actually submitting the form.
Sometimes, enclosing within the tag only makes the things worse, because I might be interested in calling a JS function whereas the form simply submits and reloads the page. I have encountered this using PhoneGap application on a WindowsPhone.
As for me, I wouldn't be too bothered about W3C validation, given it makes life much more simpler.
I just noticed that, in soundcloud, the "action" buttons on a track (like, repost, etc...) are all html button tags. Moreover, they are neither inside a form nor they bind to a form a la html5 nor submit a form (they apparently are being handled through javascript). Is this valid HTML? Can a button exist without a form? Or does that just make these buttons plain clickable divs? And how valid/unvalid would that be for screenreaders?
A button element is valid anywhere in the document body where text-level markup may appear. Such an element need not have any relationship to a form element. The currently authoritative reference is the HTML 4.01 specification, and the formal rules are in the DTD, but you can take a shortcut and use the W3C Markup Validator to check whether a document is valid.
When not associated with a form, a button element is not very different from a span element (rather than div, which is block-level by default), but button has special default rendering. Browsers and assistive software may treat button as otherwise special too, and it is safest to use button only for elements that are supposed to trigger some action when clicked on. Conversely, such elements are often best represented using button markup, though you can create visually button-like elements in other ways too (images or CSS, mostly).
Outside a form, a button element has type=button as default (and that’s normally the only sensible type for it then). This means that it can only have an effect via JavaScript. This does not make it invalid in any way. However, you may consider generating such buttons via JavaScript instead of having them as static HTML content, so that when scripting is disabled, there won’t be a (valid, but) confusing button that does nothing.
To address clarifying questions in the comment below:
A button type=button element is similar to input type=button; the difference is that the latter has no content but takes the text shown in the button from the value attribute, whereas button has content that can be “rich” (with markup).
For either element, if using them causes a server action (typically, via an Ajax call), then we can indeed ask how the page works with JavaScript disabled. But this question might be irrelevant (perhaps the page is an application that is supposed to run with JavaScript anyway), and in any case there is nothing formally wrong with the idea.
Why do they exist? For author convenience and for legacy reasons, I would say. Similarly, one might ask why HTML has event attributes at all, when they cannot possibly work without client-side scripting and you can assign event handlers to elements in JavaScript. But in the early days, that was not possible, and even at present, it might be more convenient to use the button element or the onclick attribute than to do things in JavaScript (and, for making an element look like a button, CSS). There is also the point that button and input type=button create browser-dependent appearance for elements, and it might be argued that for most users, anything that has the style of his browser’s default style for buttons is perceived as a button.
Yes. Since a very long time.
From whatwg.org :
Contexts in which this element can be used:
Where phrasing content is expected.
In the era of ajax, most inputs aren't just send by submitting a form. And most buttons are just used to execute an action on click while using a recognizable widget.
I am seeing some attribute I have never seen before in a div tag. I haven't touch html for a while but googling the attribute didn't return much useful info.
<div dataquery="#item_1306" comp="box.components.Flashplayer" id="box_Flashplayer_2" propertyquery="#box_Flashplaye_2" class="box_Flashplaye_style2"...
My question is, do you know what are these "dataquery" "comp" and "propertyquery" attributes?
Thanks alot folks.
HTML is often enhanced with custom attributes these days, and HTML5 explicitly allows for that. Normally these attributes should be prefixed with "data-", but obviously this is not the case here.
The meaning depends most probably on a script included in the page.
For example, in twitter bootstrap it is common to see attributes like <body data-spy='scroll'> which is than interpreted by a script and allows for monitoring the amount a user scrolls.
When including Facebook like buttons you may have attributes like data-style which controls whether a box, or a button, or hwatever is used.
You can add you own attributes to elements. I don't think theese atributes are standard attributes lika class and name but an attribute that the programmer has added self for some purpose.
Those are not W3C attributes, they have used to perform some task, may be to the lagulage it used and may performance some special tags, But its not best practice because it gives HTML validation errors, better thing is use data-xxxx tag for extra attributes.
More readings.
http://www.javascriptkit.com/dhtmltutors/customattributes.shtml
http://ejohn.org/blog/html-5-data-attributes/
http://html5doctor.com/html5-custom-data-attributes/