Give authors the ability to style form validation messages

[bramus]

In this tweet, the author asks for this functionality.

Css really needs to be able to style this browsers popups with an error messages in inputs.

Seems like a reasonable request. I'm thinking of a pseudo-element ::validation-message.

[emilio]

Part of the issue (at least on Firefox's side) is that these popups live in a different process from the page (so we hit the same issues that limit styling of <select> options).

That said, there may be an argument to be made about these messages escaping the page's viewport not being so critical, and I know we've discussed moving them to the page's process at least once. Maybe these days they could just be user agent top layer magic or so... cc @smaug----.

[smaug----]

With <select> is was trivial to find examples where a small iframe is used to show just the select element. I would expect the same here. So if a cross origin iframe has a simple form and you need to show validation message, where should that message live?

[simevidas]

Just being able to set font-size: inherit or font-size: 1rem would go a long way. Currently, it’s impossible to increase the text size of error messages (AFAIK).

[fantasai]

Some related CSSWG discussion: https://lists.w3.org/Archives/Public/www-style/2023Sep/0020.html

[svgeesus]

Which current CSS spec, if any, does this fit under? I wasn't sure, else I would have labelled it.

[lukewarlow]

A quick note down of a potential solution.

Define a new pseudo element ::error (name tbd) which represents the validation error popup that shows. This can be implemented using anchor positioning and popover (much like ::picker(select)). The text will default to what the browsers currently show but can be controlled via the content property. Using various state pseudo classes should be enough* to determine which text you want to display if you did want to override it statically, though you obviously could determine it in whatever way you wanted. E.g. setting a data-message attribute and using attr(data-message) in your CSS.

::error {
   appearance: base; /*To enable a standardised error box?*/
   content: "Some custom text";
   display: none; /*Can be used to remove the standard box entirely, useful if you want rich content*/
}

Maybe also a new ::error::icon to control the icon that shows?

*Turns out there's not actually many pseudo classes related to input state see #1525 for possibly a step in that direction.

Using popover and anchor positioning (the arrow would even be doable with some of the anchor positioning enhancements planned), solves the security issue regarding escaping frames (much like it did for base select).

---

One thing that comes up is the desire to show these errors inline in the page. Like select listbox Vs combobox, where we might want author control of the behaviour. Perhaps a different appearance value? Perhaps a new property to control this?

We could also perhaps just have it so it's always in the Dom tree, and you can set display:block on it to make it visible (like you can a popover). Then you could make it so it's position: static and style it like normal?

Only issue then is how to make it so it only shows after validation runs and the browser decides it should render these. But perhaps that can be handled internally by the browser by default. But authors could make these render when :user-invalid?

Though the browser would move these into the top-layer when trying to open them, so that's probably not a good solution.

[emilio]

I would refrain from using content. Form validation message content can already be customized via .setCustomValidity. The rest seems like in the right direction?

[frehner]

One thing that comes up is the desire to show these errors inline in the page.

I think this would be very useful - but at the same time, being able to choose where in the DOM it appears would also likely be asked for; some design systems put errors before the field, some after, some inline.

[josepharhar]

Which current CSS spec, if any, does this fit under? I wasn't sure, else I would have labelled it.

Perhaps css-forms?

Chromium currently implements validation bubbles as a popup document, which is the same thing we use for select popups and color picker popups. I am currently working on reimplementing them as in-document popovers for performance reasons.

[josepharhar]

I like Luke's idea and agree with Emilio's comment.

I think that using appearance:base to opt into a popover picker instead of a "native" browser one could address concerns about existing validation bubbles crossing boundaries like coming out of an iframe.

I didn't end up shipping my change to make all validation bubbles popovers due to lack of tether support (not sure what the current state of that is), and because I couldn't find a spot in the document to append a popover element for form-associated custom elements (for others like <input>, I put it in their user-agent shadowroot).