#253: HTML General Review: HTML Forms

Visit on Github.

Opened Apr 17, 2018

Hello TAGļ¼

This issue is part of the TAG's larger effort to review the HTML spec in its entirety--please see the original issue https://github.com/w3ctag/design-reviews/issues/174 for a summary of all the break-out issues.

The "Sections" are all the sections of the WHATWG HTML spec that should be reviewed as part of this issue. Where the spec section has associated Web Platform Tests, the specific WPT path is noted. While the primary focus of the review is the specification text, it can be helpful to review the related tests to help clarify algorithms or see interoperability conformance issues (or find issues with the tests).

The "Features" are just a sample of what you will encounter as part of this spec section, it's not meant to be exhaustive.

Here are some example suggestions for what to look for during the review, but don't limit to only these suggestions!

  • Look for any APIs that could be 'modernized' according to current design practices.
  • Look for things that could require permissions that aren't modelled in the permissions API at the moment.
  • Look for areas of the platform that contain UA 'magic' (aren't possible for JavaScript programs to emulate due to missing primitives in the platform). These are candidates for future Extensible Web archeology.
  • Look for areas of the spec that describe "wishful thinking" (e.g., that describe a feature that is implemented by no one). Such features should at least have implementor commitments, or they might be candidates for removal from the spec.
  • Look for cryptic and hard-to-follow algorithms that could be improved with extra explanatory text or improved prose. E.g., sometimes adding a "developer note" (green box) can add the needed clarity to understand the intent/purpose or outcome of a complex concept.
  • Look for concepts that are meant to be used together, but where this is not spelled out or explained clearly
Sections WPT path Features
4.10.3 html/semantics/forms/the-form-element <form>
4.10.15 html/semantics/forms/the-fieldset-element <fieldset>
4.10.17 html/semantics/forms/form-control-infrastructure process model
4.10.18 html/semantics/forms/attributes-common-to-form-controls autocomplete, maxlength, etc.
4.10.18.5 (see also 4.15) html/semantics/disabled-elements enable/disable
4.10.20 html/semantics/forms/constraints constraint validation
4.10.21 html/semantics/forms/form-submission-0 form submission
4.10.22 html/semantics/forms/resetting-a-form form reset

Please provide feedback as (please select one):

  • open issues in our Github repo for each point of feedback
  • open a single issue in our Github repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]

Discussions

Comment by @travisleithead Oct 29, 2018 (See Github)

Discussed briefly at Paris 2018 F2F.

  • Input type = email, has validation that is very over-constrained (does not allow anything other than [a-zA-Z0-9]). . * UNICODE in emails may have problems with MTAs (and interop)
  • Forms are welded shut, don't do extensibility.
Comment by @annevk Oct 29, 2018 (See Github)

See https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489#c37 why type=email is restrictive. Adding an attribute to make it less restrictive is still desired, but nobody has really come up with an appropriate definition. https://github.com/whatwg/html/issues/4089 is somewhat related.

(Extensibility is also slowly being tackled as part of web components.)

Comment by @cynthia Oct 29, 2018 (See Github)

The notes came in during a meeting, so to give a bit more context:

For the RHS (domain or IP) it is probably safe to make the restrictions lighter. I've been against doing the same for LHS (mailbox, also known as IDs) as interoperability across MTAs aren't great, and don't want to look like we are advocating that there wide adoption for unicode aware mailboxes. Nothing prevents web developers from actually using input type=text for this, and I think considering the extensibility limitations or customization against type-bound forms we'd like to raise the question of the usefulness of current forms, up to a point that it might be worth looking into deprecating certain aspects of it and replacing it with extensible primitives.

This is obviously a project that will take quite a bit of time, but a gist of the two line summary above.

Comment by @annevk Oct 29, 2018 (See Github)

So for RHS browsers are supposed to apply ToASCII so I think that's fine already (modulo IPv6).

Comment by @cynthia Oct 29, 2018 (See Github)

Yes, I believe in w3c/html that restriction has been lifted, but not LHS. I think that might actually even match the actual behavior of some implementations, but I'll have to check after the long business trip marathon.

Comment by @annevk Oct 29, 2018 (See Github)

What I'm describing has been the status quo in whatwg/html since the feature got added.

Comment by @hober Dec 10, 2019 (See Github)

Given that we will be getting annual horizontal review requests covering HTML, I propose that we forward-dupe this to w3ctag/design-reviews#449 & close.