Errors for form related controls

[gregwhitworth]

I've been meaning to file this issue as we do need a resolution to this prior to <selectlist> shipping. HTML has a few capabilities to enable client-side validation upon form submission; such as the required attribute. UAs have full control over the anatomy and rendering since like most UI this is not standardized anywhere. For example here are a few renderings when submitted a form that is required.

A solution to this will warrant its own explainer, so that is not the goal of this issue; the purpose of this issue is to answer the following question:

Is the error related to client-side validation a part of the anatomy of the control that owns the given attribute.

To provide a concrete example, let's use <selectlist> with a straw proposal for an <error> element:

<selectlist required>
   ... rest of anatomy here ...
   <requirederror>This field is required</requirederror>
   <patternerror>The field does not match the given pattern</patternerror><!-- this won't fire in this scenario since a pattern wasn't set -->
</selectlist>

I'm personally leaning towards doing a binding solution akin to the popover API and as I noted a research document will need to be created to influence the solution but that provides the following:

1. It doesn't block <selectlist> due to potential backwards compat issues
2. It allows scenarios where it isn't a part of the anatomy but is positioned relative to the offending field (another need for anchor-position)
3. Universal "stamping" of solutions rather than needing to replicate it for every HTML element

[css-meeting-bot]

The Open UI Community Group just discussed Errors for form related controls, and agreed to the following:

• RESOLVED: this is a good problem to solve, but it's independent of the <selectlist>. We should solve this generally.

The full IRC log of that discussion

<Luke> q-
<jarhar> gregw: selectlist is closer so i need to raise it to make sure we dont lose it. errors are usually associated, required or pattern
<jarhar> gregw: its related to invokertarget thing, a solution could fall out of that
<jarhar> gregw: if im looking at how a lot of design systems do that, its already right within the element
<jarhar> gregw: i dont think thats how were going to do selectlist
<jarhar> gregw: most of the browsers do it in the shadowdom? someone can correct me. it may vary by control
<jarhar> gregw: to look at salesforce. success is you get a toolbar across the top, but if theres errors its inline with the input
<masonf> q+
<jarhar> gregw: i just want to raise the scenario that people are going to want to style these things that get rendered, and we dont have control over that, and to devs thats part of that anatomy
<jarhar> gregw: i want to make these 3 look like my design system
<jarhar> gregw: i dont have a solution, but one thing i would want to avoid is just have it auto stamp out everywhere, so i dont have to by default change that specifc elements failure text i can, but in most scenarios i wouldnt want to
<Luke> q+
<jarhar> gregw: its an interesting problem space before we cement selectlist, it would be cool to go back and say we know for sure we dont want it in the anatomy. if we do, then we need to figure it out now
<jarhar> masonf: we dont want it in the anatomy
<jarhar> masonf: implementation wise, in all browsers they are not in the renderer, its in the browser, separate OS window, not stylable to the control
<gregwhitworth> q+
<jarhar> masonf: not that this is ideal, there is a request in whatwg to be able to style those validation bubbles
<gregwhitworth> ack masonf
<jarhar> masonf: i would like to separate that out so that we solve that independently and separately from selectlist
<jarhar> masonf: i dont think that the solution for that requires you to incorporate it into the anatomy
<jarhar> masonf: we are proposing a way to style that without saying its really part of the element
<jarhar> masonf: i dont think we should block on this and i dont think we should include it in the anatomy
<gregwhitworth> ack Luke
<jarhar> lukew: just from an ideas point of view, likewise with the tooltip, these to me seem like popovers. obviously right now they are native ui, but they seem like a thing that just an error popover, but it would be separate from the selectlist
<jarhar> lukew: you could invoke one popover from each input
<jarhar> lukew: likewise with tooltips, it would be a popover of interest rather one that invokes
<jarhar> gregw: what was in my brain was having a definition in the dom and its declarative
<jarhar> gregw: its part of the anatomy, but now its not part of the anatomy. i appreciate the tooltip one, pseudo elements are good but they are limited
<jarhar> gregw: just a square thats flat, i want to replace the content at that point, not just change colors and border
<jarhar> gregw: certain tonality that i use for them, and the localization
<jarhar> gregw: im intrigued that the invoker paradigm, because its accomplishing the same goal
<jarhar> gregw: on submit, invoker wont work, and ironically this is when that all takes place
<jarhar> gregw: we just need to do the magic behind the scenes, if this type of pattern invoker whatever element, some magical thing, the browser knows to go find that, if theres a global one or an idref
<jarhar> gregw: i got what i wanted out of this, which is dont block selectlist, it should be generalized and not part of the anatomy
<jarhar> masonf: are you ok with a resolution of that?
<jarhar> gregw: yes, give me a solution but not in the selectlist anatomy
<masonf> Proposed resolution: this is a good problem to solve, but it's independent of the <selectlist>
<masonf> q?
<Luke> +1
<masonf> ack greg
<bkardell_> +1
<jarhar> bkardell: it was more than selectlist, as a rule, but thats fine
<masonf> RESOLVED: this is a good problem to solve, but it's independent of the <selectlist>. We should solve this generally.

[gregwhitworth]

I've started a draft explainer and research in this Google doc for this since it's going to be a pretty complex problem.

[scottaohara]

some quick thoughts to consider - some of which border/veer into 'solutions' but that's more just due to me wanting to get the ideas out, rather than trying to imply 'do it this way':

• it'd be great if authors were given the option to render errors as either inline or as a popover. The popover bit more to keep parity with current presentation / potential fallback rendering (more on that later), but rendering as a "tooltip" popover is one of the problems with them now, as they're not persistent/can cover up information/only one shows at a time.
• the error messages would ideally be automatically associated with the form field in error. Again, another reason why the current browser implementation is lacking, if someone wants to re-read the error with their screen reader, they typically can't. They'd have to submit the form again to have the error reappear/reannounce.
• ideally there'd be a 'free' (fallback) error message that could render for when authors don't specify one (maybe that is even just a fixed-up version of what browsers have implemented now?) and there could be a more declarative feature for authors to create the error messages they need with their own content strings, arbitrary (to a point) content, etc. A <error for=IDREF_of_input>...</error> would be nice. Allowing JS or <template> content, etc., to be injected into those elements as needed.
• instead of devising a new element/feature, consider extending the output element. It is already supposed to be mapped as a live region (status role) in browsers, it can already be associated with a form control via the for attribute.

[lukewarlow]

https://x.com/RogersKonnor/status/1753788382059118952?s=20

This raises an interesting idea? What if we provided an mechanism to get the language strings for a given error message? That way the UI could be completely up to userland?

[jpzwarte]

Perhaps also related to this issue: https://github.com/whatwg/html/issues/9878

There is no currently no way for a Form Associated Custom Element to know it is supposed to report its validity. It only receives an invalid event when its validity is not valid.