- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 10 Jul 2025 15:36:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Give authors the ability to style form validation messages`. <details><summary>The full IRC log of that discussion</summary> <keithamus> astearns: first item on agenda about styling form validation<br> <keithamus> jarhar: there's been some renewed interest in this feature lately<br> <keithamus> .. talked about at CSSDay, una could speak more on that<br> <una> q+<br> <keithamus> .. form validation bubbles aren't styleable at all right now. You can't change how the browser renders them<br> <keithamus> .. we have different ideas on how to make them more styleable, with a pseudo element<br> <keithamus> .. or the author could provide their own popover, and an idref association could allow you to provide your own validation bubble<br> <keithamus> .. so some potential API shapes<br> <masonf> q+<br> <lwarlow> q+<br> <keithamus> .. so interested in other implementers thoughts<br> <astearns> ack una<br> <smaug> q+<br> <keithamus> una: some context; developer research has told us this for many years. Many different conversations I could point to. I've been going back and forth on whether or not this is a good idea though.<br> <keithamus> una: this inability to style these - these messages that respond to a user input - the current browser UI gives an authority because it comes from a browser. Is this something we should give to developers to style?<br> <keithamus> .. there are other APIs that allow for developers to author these.<br> <keithamus> .. the problem is we end up with two bubbles - so maybe we want to think about how to disable the user agents bubbles<br> <astearns> ack masonf<br> <keithamus> .. but there's some stuff to discuss behind this, before we discuss a solution - how it might look like to solve this. Let's take a step back before we discuss what the shape of this might look like<br> <keithamus> masonf: one vote for me to be customisable. It's already in the developers hands as to whether or not form validation kicks in.<br> <keithamus> .. developers don't use this often anyway, and I presume it's because they don't match the site and they're inconsistent.<br> <keithamus> .. I don't know what the priority is though, but I think it's up ther.e<br> <keithamus> .. but to ask - jarhar you mentioned the "bring your own popover". How would one deliver the error message into the popover?<br> <keithamus> jarhar: we already have setValidationMessage where you can provide your own message, that's on the developer to localise. My rough idea with the popover is that it's an alternative to that, and so it's still on the author to localise it<br> <keithamus> masonf: localisation is a pain, so if we're trying to provide nice localised messages maybe that's a win<br> <astearns> ack lwarlow<br> <keithamus> smaug: possible privacy issues around the localised message... might be something<br> <keithamus> lwarlow: the nice thing with the error messages, they're not blocking us shipping in page controls. They're essentially a :picker style element.<br> <una> people do use these, because for example, if you just include a "required" attribute, you'll get an error message if the form entry is blank. This is a common pattern<br> <keithamus> lwarlow: but I do think it's important.<br> <keithamus> lwarlow: does the current browser approach actually match what authors want? Currently it shows a single error message and you have to change the field, then you might get a different one. Often I want a list of error messages.<br> <keithamus> lwarlow: if there was some way to get a list of those. CSS lacks pseudo classses for a bunch of states for example.<br> <una> q+<br> <keithamus> lwarlow: having the ability to style the browsers default popup is nice though. Leave most of it up to the browser - such as when it shows and such. If you do your own you can think about that, but styling the built-in could be a big win<br> <keithamus> lwarlow: Rolling your own might require more CSS for each validation state.<br> <smaug> q-<br> <keithamus> lwarlow: but it's something worth tackling. These aren't used very often so we should research how websites currently do this (without using this API).<br> <keithamus> lwarlow: for example when the input is blurred? User-valid vs user-invalid?<br> <keithamus> lwarlow: some more contextualised information<br> <keithamus> q+<br> <astearns> ack una<br> <keithamus> una: people _do use these_. required on a form - when you hit submit you'll see it. It's a common use case, especially when copy/pasting example forms.<br> <keithamus> una: its interesting that when you have access to the error message... that might be something useful to store<br> <keithamus> .. there's a security issue - we don't want the developer to change the error message... or maybe we do?<br> <keithamus> .. if it's a generalised required field it would be handy to have the error immutable message to display<br> <lwarlow> q+<br> <keithamus> .. we could customise the popover - it's an interesting idea - but when there is some kind of form error message it applies accurately. We don't want an error message for "this field is empty" to become "you must write your social security number here".<br> <keithamus> .. maybe if there's a way to preserve the list of error messages from the user agent.<br> <lwarlow> We already have setCustomValidity for that right?<br> <astearns> ack keithamus<br> <masonf> keithamus: I don't necessarily buy the security argument. There's not a lot to inform the user that this is coming from the browser.<br> <masonf> keithamus: that's a contentious reasoning at best. We (in this room) understand what's browser UI and what isn't. Users don't.<br> <masonf> keithamus: There's a large spectrum between most users understanding of these things. E.g. the line of death isn't well understood.<br> <masonf> keithamus: The main takeaway is "why not both?"<br> <masonf> keithamus: to use the baked-in UI, give them small customization. For power developers, give them the popover. The less work we can make it, the better.<br> <masonf> keithamus: Middle-ground between no customizability, and full custom. Maybe appearance:base on the pseudo would be enough for many.<br> <masonf> keithamus: One last thing: we should be very careful talking about how messages are displayed, and timing of user interaction. There are a11y criteria - e.g. displaying all error messages at the same time isn't always great.<br> <masonf> keithamus: we should explore existing design space. Perhaps in OpenUI we can work on this more.<br> <astearns> ack lwarlow<br> <keithamus> lwarlow: three things; it would be interesting if you replaced the markup, does it have to be a popover? Some people might prefer it to be in the page.<br> <keithamus> q+<br> <keithamus> lwarlow: I think this is an area where a lot of people want different things. Some want to leave it to the browser, some replace the styling, and some want to replace the text entirely.<br> <keithamus> .. it might be technically correct but not actually correct as people would use it<br> <keithamus> .. you can override using setCustomValidity but you lose localisation<br> <keithamus> .. the localisation the browser provides is a big part of why people continue to use these.<br> <keithamus> .. I've heard people say they want access to these strings.<br> <keithamus> .. I'm curious - smaug you're concerns about the strings?<br> <jarhar> according to the mdn article, validationMessage is already localized: https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/validationMessage<br> <keithamus> smaug: you're exposing a lot of information about the language<br> <keithamus> lwarlow: don't we already expose this in a header?<br> <keithamus> smaug: you might have a very minor locale you're using<br> <keithamus> lwarlow: but don't browsers send a header?<br> <keithamus> keithamus: but the browsers can lie<br> <keithamus> lwarlow: fair. You can allow the browsers to lie for the locale string then?<br> <keithamus> masonf: correct me if I am wrong but if you expose the string itself you could probably probe for locale<br> <keithamus> lwarlow: yeah essentially match the string to what the browser is saying<br> <keithamus> smaug: whatever we do here, if we expose something it's not exposed currently. So we need to run it past privacy folks.<br> <keithamus> lwarlow: that's something that needs considering, but the styling can still work - and if you want something more then you're taking localisation into your own hands<br> <keithamus> lwarlow: the browser UI using anchoring positioning, we need the ability to tether if we want to replicate the browser UI<br> <keithamus> lwarlow: currently you don't have that information available to you.<br> <astearns> ack keithamus<br> <keithamus> .. people want that anyway so browser folks go build it!<br> <masonf> keithamus: The locale - we can potentially get rid of privacy issues by using one language, or normalizing to common locale or something.<br> <una> q+<br> <masonf> keithamus: there are things that the browser presents that are - e.g. there's the pattern attribute. The browser will come up with a message that says "must match the pattern" but the developer knows more and can provide a better error message.<br> <lwarlow> q+<br> <masonf> keithamus: coming back to the spectrum - there are some that need a well curated set of messages.<br> <astearns> ack una<br> <keithamus> una: so what if you have a form field that has different types of errors? What if it requires numbers and you put letters in<br> <keithamus> una: how does a developer specify what those errors are?<br> <keithamus> lwarlow: more css pseudo classes for the validation would be good. A lot isn't exposed, or not exposed in a granular enough way.<br> <keithamus> lwarlow: it's also part of the UX issue, it's an ordering issue, first it'll tell you it's required, then it'll tell you the pattern is wrong. but with multiple pseudo classes you could apply multiple error messages together.<br> <keithamus> una: you're envisioning a set of states, required error, pattern match error, and you'd "and" them together?<br> <keithamus> lwarlow: you'd build lists, hide each item based on the pseudo state.<br> <keithamus> lwarlow: I left a comment on one of the css issues.<br> <keithamus> keithamus: https://developer.mozilla.org/en-US/docs/Web/API/ValidityState this API exists in JS, wholesale in CSS could be good<br> <keithamus> lwarlow: overriding content css property on the pseudo elements. If you had that then you could go and fix the error messages.<br> <keithamus> lwarlow: I could replace specific error messages when I need to<br> <keithamus> lwarlow: and if I am localising then I would be localising all my string anyway<br> <astearns> ack lwarlow<br> <keithamus> astearns: I like the idea of having openui do a survey on error messages<br> <smaug> FWIW, I think https://searchfox.org/mozilla-central/rev/1eb4f27ece7cb96ac94b635ad0dc95c00d1443db/dom/locales/en-US/chrome/dom/dom.properties#37-68 is the list of localized error messages.<br> <keithamus> q+<br> <fantasai> I think content belongs in the HTML, not the CSS.<br> <lwarlow> https://github.com/w3c/csswg-drafts/issues/1525 - this is the CSSWG issue I mentioned about exposing pseudo class(es)<br> <keithamus> astearns: what design systems to do override these things<br> <keithamus> astearns: then having a granular list of what we might want to do here.<br> <bkardell> fantasai: I think I agree, but how would you put it in?<br> <smaug> (and I see up to 99 different locales for those error messages for Firefox )<br> <keithamus> astearns: multiple things: changing the error message, concatenating, changing wholesale the error message display. Each of these might have privacy and security issues, when we figure out what we might want to do we can involve those folks.<br> <astearns> ack keithamus<br> <astearns> s/privacy and security/privacy and security and accessibility/<br> <masonf> keithamus: a lot of the form validation stuff is fundamentally broken - several open issues. Rolling custom validity messages - not able to listen to events for validity states. So even people who are trying to use this API end up having to roll their own anyway.<br> <lwarlow> Here's an example of a missing custom element hook https://github.com/whatwg/html/issues/9878<br> <masonf> keithamus: we can do some simple things to get 80% of the way there. Let's do the easy stuff first, and then talk about the advanced things.<br> <fantasai> <error type=pattern inputclass=something>Error Message Here</error> ... <input patternerror=something> ... <input patternerror=something> ...<br> <bkardell> smaug: that is what I was thinking about too<br> <fantasai> bkardell: ^<br> <keithamus> Some issues for the basics; https://github.com/whatwg/html/issues/10694, https://github.com/whatwg/html/issues/4280, https://github.com/whatwg/html/issues/9878<br> <bkardell> fantasai: see what Smaug said though<br> <lwarlow> +1 to taking this back to OpenUI<br> <keithamus> masonf: the privacy question seems key to several of the solutions, so maybe we should get that going<br> <keithamus> astearns: getting an accessibility story behind these would be good. What should we be concerned about here?<br> <keithamus> astearns: anything more on this today?<br> <bkardell> +1<br> <keithamus> astearns: anyone volunteering to take this back to openUI?<br> <keithamus> keithamus: i will<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7172#issuecomment-3057967159 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 July 2025 15:36:22 UTC