5 ms·

Last time I checked, web-browsers today still do not allow you to style the appearance of built-in HTML validation messages [1]; this wouldn't be so bad if Chro

Last time I checked, web-browsers today still do not allow you to style the appearance of built-in HTML validation messages [1]; this wouldn't be so bad if Chrome (and Firefox) still conformed to their OS platform UI guidelines (i.e. so it looks system-generated, like how `title=""` tooltips used to be), instead Chrome uses this ugly yellow/orange icon color with black-text on a white background on a bubble with a fixed corner border radius - it clashes horribly with my current project's aesthetics. [1] https://stackoverflow.com/questions/5328883/how-do-i-style-the-html-form-validation-error-messages-with-css https://stackoverflow.com/questions/5328883/how-do-i-style-t... Annoyingly, Chrome used to allow styling of validation-messages using vendor-prefixed pseudoelement selectors, but they removed that functionality and never brought it back; I'll chuck this on the same pile as other arbitrary annoyances like "can we have a native HTML combo-box please" and "why is <select multiple> still a horribly unusable ctrl+click box instead of a checkbox-list?".

354896547981565 2y ago
True. But you can hide the default message and replace it with your own. You'll still benefit from the form validation.
- deleted 2y ago
  [deleted]
- jacobr 2y ago
  You can even benefit from the default messages if you want that, grabbing `input.validationMessage` and rendering it as you wish.
- gregoriol 2y ago
  There is no real benefit because the validation rules allowed there are often too limited for real use-cases anyway.
  - epolanski 2y ago
    What do you mean there's no real benefit? You give the same error messages based on whatever custom validation and control the output.
    - fkyoureadthedoc 2y ago
      I've found it more annoying to mess with the browser validation API and using setCustomValidity/reportValidity etc. than to just use other validation libs. Ideally I'd use whatever library I want and they would call setCustomValidity for me though. Using the related pseudo classes :valid, :invalid, :required, :optional is nice, but until last year you still had to do custom logic there because :user-valid/:user-invalid weren't implemented outside of Firefox. That created additional work and was annoying.
  - endemic 2y ago
    Do you have any examples?
  - mock-possum 2y ago
    Really? In my experience they easily cover the majority of cases - strings versus numbers, min and max length, upper and lower bounds to values, specifying what decimal level you’ll accept, you can even straight up provide a regex in the ‘pattern’ attribute.
unclebucknasty 2y ago
For that matter, styling a select (single) isn't quite the walk in the park it should be.
deleted 2y ago
[deleted]
cxr 2y ago
[flagged]
- DaiPlusPlus 2y ago
  I agree with you 100%; I hate it when websites think they’re being trendy by using undraggably-thin scrollbars or try to subvert the UA’s password-manager (banks…) or naively think they can block users right-clicking or copying images. To clarify my position: I agree that UAs should be free to show validation messages as-appropriate for the user (I.e. those popover hints) but it is because Google decided to stylise them with a very specific aesthetic/design - as opposed to trying to fit-in to the host system - it clashes more. Now, I’m not suggesting that the UA popovers be fully CSS-able, but I would like to see some kind of coarse-grain control “hint” properties - just like we have with (non-WebKit-prefixed) scrollbars, <button>, most <input> types, and more besides. The issue here is that the validation popovers are almost uniquely exempt from styling compared to all other HTML platform features (the only other exception being `title=“”` tooltips, AFAIK). By-comparison, this is kinda like the (still) half-broken support for dark-mode: if a page is dark-themed you (probably) don’t want nuclear-flash-white UA-provided popovers stinging your eyes because there’s no validation-popover background color hint. Similarly, supposing my website makes tasteful use of serif typefaces - but the input validation popovers will be in Chrome’s own Material-design sans-serif font, while OS/platform widgets will be in some third other font by-default but can generally still be set via CSS. If you’re on HN then you’re likely bothered by inappropriate mixing of serif and sans-serif typefaces, so I hope you can sympathise.
  - cxr 2y ago
    You're talking about millions of dollars of engineering resources to implement what not only doesn't matter, but is probably actually harmful in comparison to the status quo (however ugly that is). And that's just on the implementation side. Now consider the tens of thousands of downstream developers who are going to suck up more resources from their clients because browser developers offered them a new bauble and some knobs to tweak. All going towards something that shouldn't even exist.
deleted 2y ago
[deleted]
ximm 2y ago
I never really understood why people want to style stuff like this. I like how you can express yourself by using colors and layout and stuff like that. But at some point usability is more important than branding.
- guappa 2y ago
  > usability is more important than branding. Said no designer ever. At work our design team came up with buttons that are 10x10 pixels on my screen. They are used to change pages (like on mobile, but this is a desktop program), the scroll events are ignored by design, so you either click the tiny buttons (which are slightly darker gray than the dark background) or you simulate a finger swipe via drag and drop with the mouse. Yes they designed a touch GUI for a desktop application.
  - micromacrofoot 2y ago
    plenty of designers say this, often company leadership is the one pushing them to style everything because everyone else does
    - guappa 2y ago
      Well the ones I've worked with couldn't care less. Of course they love to show off how good they are to the poor disabled people, but that doesn't mean anything until some government reminds us that we are in breach of contract unless we make our GUI accessible.
      - micromacrofoot 2y ago
        this seems like a very mean spirited take on accessibility?
        askew 2y ago
        I took from it that [the designers] are all mouth and no trousers – which is fairly common. But "the poor disabled people" seems patronising.
everdimension 2y ago
I think the problem here is not as much with the absence of custom styling, because you can quite easily read the native "validity" state of the input and render it however you want. The problem is that it's quite tricky to correctly subscribe to the changes of this validity state. There are indeed some validity events being dispatched, but unfortunately not always. Updating form state programmatically (such as calling "form.reset()" or setting input value via "input.value = '...'") doesn't trigger these events. I think this is a separate good topic for investigations and for suggestions to the web platform
- chii 2y ago
  I think form validation should remain an app implemented part of a web form, rather than natively built into the browser. The majority of the work in form validation is not in the validation of the data, but in the UX and interaction, display and update of state. There's no generic way to handle it, as it's very dependent on the app itself. Keeping the browser smaller and cleaner, with less logic seems to be a better idea.
  - DaiPlusPlus 2y ago
    > Keeping the browser smaller and cleaner, with less logic seems to be a better idea That idea died sometime around 15 years ago. Chromium can probably be best-described as a kind-of user-mode OS at this point.
  - braiamp 2y ago
    Checking if a string is a email (or at least looks like one), if it's a number, etc. is such a cheap processing, that setting up and tearing down a connection to the server to process it is a waste of resources. Client side validation has its uses, it's more responsive. The problem is that we want all these custom behaviors when it's actually some rudimentary data input validation.

354896547981565 2y ago

True. But you can hide the default message and replace it with your own. You'll still benefit from the form validation.

deleted 2y ago
[deleted]
jacobr 2y ago
You can even benefit from the default messages if you want that, grabbing `input.validationMessage` and rendering it as you wish.
gregoriol 2y ago
There is no real benefit because the validation rules allowed there are often too limited for real use-cases anyway.
- epolanski 2y ago
  What do you mean there's no real benefit? You give the same error messages based on whatever custom validation and control the output.
  - fkyoureadthedoc 2y ago
    I've found it more annoying to mess with the browser validation API and using setCustomValidity/reportValidity etc. than to just use other validation libs. Ideally I'd use whatever library I want and they would call setCustomValidity for me though. Using the related pseudo classes :valid, :invalid, :required, :optional is nice, but until last year you still had to do custom logic there because :user-valid/:user-invalid weren't implemented outside of Firefox. That created additional work and was annoying.
- endemic 2y ago
  Do you have any examples?
- mock-possum 2y ago
  Really? In my experience they easily cover the majority of cases - strings versus numbers, min and max length, upper and lower bounds to values, specifying what decimal level you’ll accept, you can even straight up provide a regex in the ‘pattern’ attribute.

unclebucknasty 2y ago

For that matter, styling a select (single) isn't quite the walk in the park it should be.

deleted 2y ago

[deleted]

cxr 2y ago

[flagged]

DaiPlusPlus 2y ago
I agree with you 100%; I hate it when websites think they’re being trendy by using undraggably-thin scrollbars or try to subvert the UA’s password-manager (banks…) or naively think they can block users right-clicking or copying images. To clarify my position: I agree that UAs should be free to show validation messages as-appropriate for the user (I.e. those popover hints) but it is because Google decided to stylise them with a very specific aesthetic/design - as opposed to trying to fit-in to the host system - it clashes more. Now, I’m not suggesting that the UA popovers be fully CSS-able, but I would like to see some kind of coarse-grain control “hint” properties - just like we have with (non-WebKit-prefixed) scrollbars, <button>, most <input> types, and more besides. The issue here is that the validation popovers are almost uniquely exempt from styling compared to all other HTML platform features (the only other exception being `title=“”` tooltips, AFAIK). By-comparison, this is kinda like the (still) half-broken support for dark-mode: if a page is dark-themed you (probably) don’t want nuclear-flash-white UA-provided popovers stinging your eyes because there’s no validation-popover background color hint. Similarly, supposing my website makes tasteful use of serif typefaces - but the input validation popovers will be in Chrome’s own Material-design sans-serif font, while OS/platform widgets will be in some third other font by-default but can generally still be set via CSS. If you’re on HN then you’re likely bothered by inappropriate mixing of serif and sans-serif typefaces, so I hope you can sympathise.
- cxr 2y ago
  You're talking about millions of dollars of engineering resources to implement what not only doesn't matter, but is probably actually harmful in comparison to the status quo (however ugly that is). And that's just on the implementation side. Now consider the tens of thousands of downstream developers who are going to suck up more resources from their clients because browser developers offered them a new bauble and some knobs to tweak. All going towards something that shouldn't even exist.

deleted 2y ago

[deleted]

ximm 2y ago

I never really understood why people want to style stuff like this. I like how you can express yourself by using colors and layout and stuff like that. But at some point usability is more important than branding.

guappa 2y ago
> usability is more important than branding. Said no designer ever. At work our design team came up with buttons that are 10x10 pixels on my screen. They are used to change pages (like on mobile, but this is a desktop program), the scroll events are ignored by design, so you either click the tiny buttons (which are slightly darker gray than the dark background) or you simulate a finger swipe via drag and drop with the mouse. Yes they designed a touch GUI for a desktop application.
- micromacrofoot 2y ago
  plenty of designers say this, often company leadership is the one pushing them to style everything because everyone else does
  - guappa 2y ago
    Well the ones I've worked with couldn't care less. Of course they love to show off how good they are to the poor disabled people, but that doesn't mean anything until some government reminds us that we are in breach of contract unless we make our GUI accessible.
    - micromacrofoot 2y ago
      this seems like a very mean spirited take on accessibility?
      - askew 2y ago
        I took from it that [the designers] are all mouth and no trousers – which is fairly common. But "the poor disabled people" seems patronising.

everdimension 2y ago

I think the problem here is not as much with the absence of custom styling, because you can quite easily read the native "validity" state of the input and render it however you want. The problem is that it's quite tricky to correctly subscribe to the changes of this validity state. There are indeed some validity events being dispatched, but unfortunately not always. Updating form state programmatically (such as calling "form.reset()" or setting input value via "input.value = '...'") doesn't trigger these events. I think this is a separate good topic for investigations and for suggestions to the web platform

chii 2y ago
I think form validation should remain an app implemented part of a web form, rather than natively built into the browser. The majority of the work in form validation is not in the validation of the data, but in the UX and interaction, display and update of state. There's no generic way to handle it, as it's very dependent on the app itself. Keeping the browser smaller and cleaner, with less logic seems to be a better idea.
- DaiPlusPlus 2y ago
  > Keeping the browser smaller and cleaner, with less logic seems to be a better idea That idea died sometime around 15 years ago. Chromium can probably be best-described as a kind-of user-mode OS at this point.
- braiamp 2y ago
  Checking if a string is a email (or at least looks like one), if it's a number, etc. is such a cheap processing, that setting up and tearing down a connection to the server to process it is a waste of resources. Client side validation has its uses, it's more responsive. The problem is that we want all these custom behaviors when it's actually some rudimentary data input validation.