I don’t sub him on YouTube - but I’m not lying when I say everyone I know IRL who does sub his channel has worked as a barista at some point in their lives (…and purchase actual chemical-lab supplies for their coffee brews).
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.
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?".
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
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.
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.
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.
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.
The place where I live is very good at pretending to do the right thing while doing absolutely nothing.
For example a touristic social account managed by some government entity posted some extra complicated wheelchair lift (that will inevitably break in 1 month at most) to show how disabled people are well integrated.
Meanwhile of course the real situation is that people on wheelchair can go almost nowhere at all. Newer public transport has even worse accessibility than before, elevators are mostly broken at all times and regular ramps are missing, doors regularly have super strong springs and a button to open them (which breaks all the time) when they should just have a much weaker spring instead.
Designers I've worked with are like the tourist social media account. Showing the one single place they made accessible and explicitly saying in meetings "we are good people, we care for disabled people"… and then hating me for pointing out the million other things that are not accessible.
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.
Designers that come from a background of human machine interaction care and will say that. Designers who come from a background of art don't understand what is being talked about and so don't say anything - they tend to only ensure it works on their one devices which they have selected to be the best and ignore everything else.
The second group does make things that look nicer, but the first ensures it can be used. You really want both, but then you need to be careful about who wins when they disagree.
It is a patronising sentiment, but adjacent tonal cues suggest GGGP is offering it ironically, thus in ridicule of performative compliance.
On flipside, note that many regulations - in any human domain - are oriented to raise the level of the worst performing, not to support the efforts of the best or to optimise the middle.
Yes very patronising, a terrible attitude really. Which is why I criticise it.
Also I'm disabled myself, although not in a way that requires any adaptation to use a computer. But I of course notice these things a bit more than average; and I get to hear my elderly father's complaints about software that he can't use because of inaccessible design.
Of course a designer should be qualified and notice these things even more… but all they do is move buttons around and disable copy paste so that even fully abled people have a hard time using our software between versions.
I believe that was the commenter's point - that the designers described patronizingly virtue signal about their accessibility priorities, while their other decisions are troublesome.
Which everyone is only doing because it's an industry fad likely stemming from copycatting one or two instances where it was done for legitimate reasons.
People want to style things to match their page, exactly because consistency is part of usability. Especially given the limitations of browser form validations, you will absolutely need your own validations in addition to any browser validations you use. But your own validations will look different from the browser-provided ones, at least on some browsers. Which will confuse users, hence decreasing usability.
And this also assumes that the browser validations are in any way usable to begin with. I would argue that they are not, and would require some sane styling to become usable in the first place.
I think consistency within an application is far more important than consistency across applications. And even if it were true that users hated the lack of consistency, it would fall on deaf ears: the web page developers can only influence their own page. They can't make Google or Mozilla or Apple come up with an actually usable error model, or any kind of good UI in general, so the only chance they have is to create a good UI for their own page, and hide the horrible defaults that each browser is reinventing.
But at some point usability is more important than branding.
I have never worked for any company or organisation that believed this. Most clients will send you their branding guidelines before sending their feature requests. If they get to choose between adding a new feature, improving usability or making sure everything follows the branding, they will choose the branding every time.
I think you're exaggerating here. I recognise the "branding is more important than usability" approach, but the OP specifically said "at some point". Have you ever worked for a company that forced a design decision knowing it would prevent anyone from using the product? I suspect not; there will always be some point.
The issue here is, at what point does usability take precedence. Does input validation fall under "branding" or "function"? IMO, an error modal is nothing to do with company branding, etc. — it's not even part of your document, it's the browser's responsibility. The browser can decide to do something completely different from showing a modal as far as its concerned, so you shouldn't make any assumptions. Your responsibility ends at declaring what valid data is.
It 1000% falls under branding. If you don't make errors consistent across browsers / platforms your support staff will politely but firmly burn your house down. There's no such thing as your responsibility ending and throwing your hands up when you're a company who has to do end-to-end support of your product.
Having as little native anything means you go from
n sets of documentation to 1.
I think the disconnect here is in the interpretation of “more important.” Usability is more important than branding from the point of view of the victims of this kind of over-designed software, the end users. Because they are already being inflicted with a lot of branding, please at least give them conventional error messages.
Sure, but that's not how it works out in practice. It sure looks like everyone just rolls their own. Fun game: can you find any major website that uses the default validation?
This isn't an issue if everyone's an accessibly expert, otherwise we're sacrificing usability.
I love that as well, I hate bloated sites just as the next one here.
But for any more complex form with dynamic content, JS is still inevitable. I guess for HN the input form at the bottom is enough. But Algolia uses a custom input component already.
On reflection my earlier comment was a little off the mark - all 3 of those sites use JavaScript, but minimally.
Zero JavaScript is rarely practical when there's meant to be interactivity of any kind. The issue isn't the language, but the appalling bloat that is now the norm on the web. And, course, bad design in its various forms.
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.
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.
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.
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.
> Pretty much all WiFi is password-protected nowadays
I was at Disneyland last week and stayed at one of their hotels - and all the guest Wi-Fi networks were passwordless and therefore insecure. Ditto the free WiFi at the airports at both ends; oh, and the in-flight Wi-Fi too. While walking around the park my iPhone listed a bunch of passwordless mobile hotspots too.
Are you thinking of captive-portals with logins/passwords? (E.g. Mariott/Hilton “Enter your room-number and last-name” portals) - I assume you’re aware that’s only used to authenticate after the WiFi connection is already established?
———
(I really hope that I’m wrong on this; but I’m not aware of any modern wifi standards that address this…. Of course, corp/edu networks can just use RADIUS or a client-certificate (which works on wired networks too).
Also, it’s surprising we still haven’t figured out getting TLS to work with home-user-grade routers’ control-panels…
I have a Lightning FLIR camera and it works identically well when used with Apple’s Lightning-to-USB-C adapter, it even works with my 2018 iPad Pro which kicked-off the iOS+USB-C process all those years ago.
My iPhone today is rather aged (and uses Lightning) so I’m switching to an iPhone 16 later this year, and I’m confident all of my Lightning accessories will continue to work do long as the apps are available on iTunes.
Related question: now that desktop iTunes is useless for iPhone app management - how the heck do I save and load the iOS I’ve purchased after they’ve been pulled from the store?
> There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.
That’s still very much the case today, BUT you absolutely need to do your legwork beforehand (e.g. include a copypastable program that reproduces the problem and as thorough an analysis as you can do) otherwise your thread will go poorly… (and plenty of regulars in the dotnet repos aren’t exactly the forgiving type). Compare that to what you get with a Support contract: you can be a non-technical person in Sales or the C-Suite or whatever and they’ll hold-your-hand to guide you through the troubleshooting/diagnosis/repro process - and if the issue is an actual bug in MS’ code then at least you get your ticket’s fee/credits refunded.
———-
Unrelated-but-related: An LLM+multimodal “AI” would be fantastic for walking nontechnical users through the issue-reporting process. I’d wager the number-one problem in tech-support today is dealing with “It doesn’t work”-type tickets which necessitates having to interrogate the user/customer/victim to get the details out - but if an AI agent (with screen-reading abilities) handles that (without a single audible sigh or facepalm) then that’s a win for everyone.
reply