Should controls be used outside of a `<form>` element?

[chancancode]

In the HTML 4.01 specification contained the following (presumably non-normative) text about controls:

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.

Since HTML 5 the specification no longer include this or similar text. It could be interpreted the omission meant that authors are now discouraged from doing so, but my read is more likely that it was just lost in the giant rewrite of the spec. In terms of validity, the spec does say the control elements are valid in any parents that accepts phrasing content, so there is that.

While I agree that most use cases of controls on the web do fall into the use case of a logical/semantic form – whether styled as such or not – there are good reasons to use them as user interface elements outside of a form. Some examples:

• <button>s are regularly used for performing actions outside of a form
• An <input type="range"> can be used to control the zoom level in a photo editor/document viewer, or playback/volume control of a media player.
• A <select> element can be used to switch between different UI modes – such as "slide" vs "outline" vs "table of content", in a presentation app, or to switch between different sources in a file browser/explorer.

Am I correct in understanding that there is no intended change between HTML 4.01 and newer versions in terms of whether the above patterns are considered "appropriate"? Is this something worth clarifying in the spec (by way of adding back a similar sentence that was found in HTML 4.01)? If the patterns are still valid, does the spec have an opinion on what constitutes a <form> semantically to help determine when (not) to wrap a <form> around these controls? Are there any accessibility benefits/hazards one way or the other?

[domenic]

There is an intended change. The HTML standard has its own validity rules that are not related to those of HTML 4. To find out what contexts each control can be used in, you need to consult that control's specification. For example, look at the specification for button. As you see, it can be used where phrasing content is expected. It has no expectations around a form ancestor.

This is one of many differences between the HTML Standard and HTML 4, so I don't think it's worth calling out specifically.

[chancancode]

Sure, I understand the how to find out when an element is "valid" (the "Contexts in which this element can be used" sections in each element), what I was looking for is a higher level of guidance/confirmation.

For example, while the <table> element is a valid anywhere in there is additional text around like "Authors are encouraged to..." and "Tables must not be used as layout aids.", etc. Similarly, The <p> or <div> elements are valid in a lot of places, but there is text around it saying they should not be used when a more specific element is appropriate.

Given that there used to be a text calling out that it can be appropriate to use controls outside of the context of a <form>, and that text no longer exists, it is a bit ambiguous whether that is now discouraged or what, especially that there is a big section of non-normative text discussing the topic and these use cases are not mentioned at all.

The specific thing that came up was that we had a discussion on our project where someone pointed out we used a <select> element outside of a form and that is invalid/bad practice/semantically wrong/inaccessible. I am pretty sure that is not true, and I figured it would be easily answered by referencing the spec. Whether it's "valid" or not was easily settled, in terms of "Contexts in which this element can be used", but whether it is a "bad idea", or whether the spec even has an opinion on that, was somewhat harder to interpret given the use case was not mentioned in the otherwise very detailed introductory text, plus the omission/change between HTML 4.01 and HTML 5+.

IMO, since there is already so much non-normative introductory text around forms, a sentence pointing out there exists some non-form use cases of "form" controls wouldn't hurt. It's about the use cases/appropriateness, not the structural validity of the document, so it doesn't duplicate the new format, and there are IMO plenty of other precedences of that in the spec already.

Secondary to (and maybe separately form) that, the spec just doesn't do a very good job of defining semantically what a <form> is or is not. My intuition is that it has to be logically "submittable", whether there is literally a submit button and whether it is using the native/default submit behavior or not, but that was kind of hard to validate using the spec.

The closest thing it said was:

The form element represents a hyperlink that can be manipulated through a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing.

What felt like it's at the same time too specific ("to a server") and too vague ("represents" a hyperlink) at the same time. For example, if a group of controls exists to filter data that exists only on the client (e.g. filter/search controls for the TodoMVC), should it not be wrapped in a <form> tag?

[chancancode]

Part of what complicates the issue is that the text of the form section points out the primary reason that form controls are allowed to appear outside of a <form> tag it to workaround the restriction that <form> tags cannot be nested, which could be inferred to imply that is the only reason to not nest them inside a <form>.

[domenic]

This is a lot of text, but I think the following might get at the core of your issue:

The spec does not have an opinion outside of validity on this subject. We always welcome more examples; if you can't find any examples of controls used outside of forms, then a pull request adding those would be great. (But, not in the forms section! In the individual controls sections'!)

[chancancode]

Well, I can try to summarize. I think there are a couple of related issues:

1. The general Forms section – probably somewhere in "4.10.1 Introduction" – should explicitly affirm/acknowledge that there are use cases for using "controls" to build user interfaces outside of a "form".

2. Sure, specific examples for each individual control suggesting what else they can be used for other than in a "form", would be great, and I am happy to provide them, but it wasn't really what I am after originally.

3. The semantic meaning of the <form> element could be improved.

---

The first issue is what I am mostly after here. I am happy to split the rest to separate issues.

It is unfortunate that there isn't a separate "Controls" section separate from "Forms" as a parent for all the input types, select, button, etc, but I think it's understandable. Absent of that, the logical place to describe that would be a sentence in the Forms Introduction section since that's the closest shared parent.

It doesn't have to go into details, just to point out the fact that this section isn't necessarily exclusively about <form>s, despite the title. This is unlike the similarly structured Tabular Data section, which is exclusively about <table>s.

All I am suggesting we add back is a sentence along the lines of:

4.10.1 Introduction

This section is non-normative.

A form is a component of a web page that has form controls, such as text, buttons, checkboxes, range, or color picker controls. A user can interact with such a form, providing data that can then be sent to the server for further processing (e.g. returning the results of a search or calculation). No client-side scripting is needed in many cases, though an API is available so that scripts can augment the user experience or use forms for purposes other than submitting data to a server.

+++ This section covers both forms and form controls. While form controls are generally used to build forms, they can also be useful for building user interfaces outside of a form. +++

Writing a form consists of several steps, which can be performed in any order: writing the user interface, implementing the server-side processing, and configuring the user interface to communicate with the server.

Happy to discuss and iterate on the exact wording, making it less verbose, working it into the existing prose, etc. But I do think we lost a semantically meaningful and important sentence from the HTML 4.01 era, that is is no longer found in the specs and is not otherwise covered by the new structure, and I disagree that it's just a matter of needing examples.

[domenic]

I don't think it's appropriate to talk about contexts outside of forms in the form section. That section is about forms, not about not-forms.

[chancancode]

I think you are now getting at the core of the issue.

There is the "Forms" section, and then there is the <form> element section. I'll try to be consistent and differentiate them as such.

Assuming we agree that there are use cases for using controls outside of forms, it is unfortunate that control elements are grouped under the the "Forms" section. The specific issue I have is that this structure implies controls should only be used as part of a form.

In an ideal world, there will be a "Forms" section where it talks about forms in general, in which it would suggest using the "Controls" to build it ("see next section"), and then there will be a separate "Controls" section, which mentions they are primarily used for "Forms" but also used to build user interfaces. But it is what it is, and it's probably not worth an elaborate restructure just to fix this issue.

So then, given the existing structure, where else would you point this out?

[domenic]

As I said, in the individual controls sections. Where it is already pointed out, through the spec's canonical mechanism for doing so: the validity constraints, and examples.

[annevk]

It does seem somewhat reasonable to me to have a separate "Controls" section, especially as we currently group progress and meter under "Forms" which does not make a whole lot of sense.

(Given how fieldset is defined maybe it should be under "Grouping content".)

It would be quite a bit of work though for what's essentially a clarification.