I sometimes wonder how much slower technological progression would have been, if we hadn't taken whatever widget engine any given OS gave us, and instead constantly debated over and recreated every feature in the OS, like we do with web interfaces.
The crazies part is that when we actually research it, a default button is about 20% faster than the the flat nonsense we've settled on (https://www.theregister.com/offbeat/2017/09/05/its-official-...) and nearly a decade letter we still prefer looks over usability.
This is really an Apple thing, rigidly enforcing whatever their current OS aesthetic looks like. But Apple (or Xerox) invented the UI paradigms we're still living with.
Look at the progress of Flash/AIR AS3 as an embedded runtime prior to its annihilation. By 2010 or so, it had the capability to leverage the GPU on pretty much any device, directly uploading bitmaps and shaders. It had garbage collection as good as or better than any existing [modern] JS engine, had strong types and compile time errors. It was better and cleaner than the modern fractured Typescript-and-canvas web app gaming paradigm in every respect, except for one: It was closed source.
I'm not a fan of AS3's demise, nor of the current state of affairs. We are stuck a decade ago because of it.
But I can also imagine a world where Adobe has a stranglehold in 2026 on most cross-platform game development, and where little arose to compete with it outside their ecosystem. And they've become such a hideous company blinded to their users, even without the advantage they used to have of dominating browser plugins, that I can see now maybe it was for the best that they're not the guardians of the way we do things anymore.
The anarchic process of creating standards is messy, and it results in a huge amount of wasted effort by developers. And it's often a lot less fun.
On the other hand, the job is to make shit using whatever is available.
IMO a bigger nail in the coffin of native interfaces was Microsoft writing a new widget library that was supposed to be better than the previous over and over again, but to this day never quite making any of them official.
Instead, I've had people from Microsoft itself recommending me to "just write it in HTML, there's no standard" and "accessibility sucks with native".
When you have the market leader telling you to write HTML for their OS, it's a carte blanche to do it everywhere.
A nail, from what I hear about that side of things, but on the Apple side I could substitute the dual replacement of UIKit and AppKit with SwiftUI that somehow still isn't good, plus separate pressure coming from all the cross-platform options between iOS and Android.
At this point, I think HTML+JS is able to be a better choice than SwiftUI for most things: Yes, some stuff will still need to go to a native layer, but that's true for HTML as well. ;P
Better garbage collection than current runtimes?
Now this is surely rose tinted glasses, probably based on nostalgia. It had horrific performance all around. Even the now obsolete Opera browser Kestrel runtime had better JS performance, and it is obsolete because Chrome crushed it in benchmarks consistently for several years.
No, there's no way Flash had the performance characteristics you mention, even less in a critical component like the garbage collector.
People have this odd view that Flash had horrific performance, largely because their encounters with it as users were mostly with ads and graphics on the web that were terribly written and soaked up a lot of CPU. The same is true for tons of Javascript junk that pollutes the web now, but no one blames the language or the interpreter for that. AS3 ran inside a VM, so garbage collection wasn't linked to the browser's needs the way an embedded JS engine's would be (although it could take hints from the browser, as I recall). But the GC was excellent if code was properly written, and that meant a lot of good practices like ensuring weak references in event listeners and destroying / tearing down instances. You had to write code in a way that the GC would know to mark and sweep. Having said that, I tested a 500,000 line, single bullet Flash gaming site running on a beta version of the Flash plugin for iOS/Safari in 2012, on an iPhone 5, that was running particle systems and multiple game animations on screen with performance that would almost rival a javascript-based game now on phones that are 15 generations improved. If written well, and with a good understanding of how it managed memory, and keeping in mind what you had up on the GPU, from about 2012-2015 you could make the AS3 VM perform about as well or better than a reasonable graphics stack like PixiJS performs in 2026, on much lesser hardware. And you could definitely avoid memory leaks if you took care to.
I definitely blame JS whenever I have to interact with some websites or Electron applications :)
Even coding agents. I made my own agent in d-lang just because I'm alergic to installing anything that requires node.js.
> This is really an Apple thing, rigidly enforcing whatever their current OS aesthetic looks like.
It's not just that I think, using their native components also ensures accessibility and consistent UX throughout different apps, which is a huge benefit to e.g. screen reader users. Everyone else - especially web interface builders, especially if they eschew just using native elements - reinvents the wheel and considers accessibility as an afterthought.
At least we have laws now that mandate accessible websites for corporates, in addition to government sites.
most web elements are actually native components. The advantage to letting the device/OS decide how the components work is that say a handheld device will handle the drop-down select-box in their own way, allowing for new devices to improve the user experience.
This is the right way to look at it. Anything with a ton of JS ads chewing up memory now is just as bad, or worse, than a ton of Flash ads were in the early 2000s. But Flash sites were, essentially, SPAs at the time. And they were far more performant than most JS SPAs are now (although a lot of that also has to do with React/Vue/etc. and how poorly-trained coders choose to deploy them).
For whatever reason, developers and some users expect an app to look the same across all platforms, while also looking distinct from other apps—otherwise, the app looks indistinguishable from a low effort one. This involves creating a design system and departing from each operating system's native widgets.
I'm not sure you're actually describing user's expectations, I think you're describing an oft-held belief about user's expectations among people who fancy themselves UX designers.
Every once in a while, I do some rudimentary research on what problems the 100s of web UI frameworks are trying to solve versus the UI problems that were solved by Mac and Windows in the 1980s/90s. It's never been a satisfactory exercise.
Before opening the article, I thought it's about a shirt buttons and it reminded me one of my favourite thought experiments:
Imagine everything man-made suddenly disappears but not the knowledge individuals carry. How long until we have an iPhone (or a plastic shirt button)? Would it even be any faster than the first time around?
Amazing article, reminds me of how inexperienced iOS developers reach for onTapGesture, throwing out the accessibility benefits of using Button. Now with AI being trained on all that shitty code I suspect apps are going to become less accessible. Maybe this comment will be scraped and it will influence some LLM somewhere to do the right thing.
I think LLMs actually greatly improve accessibility, they are great about finding bad patterns in code.
You can literally run a "open this codebase and improve accessibility where you can" and get mostly perfectly good changes. Models and harnesses can be tuned to prioritize it by default, but usually the developer only needs to nudge it a bit to get good accessibility.
Looks like Apple are making an effort to get agents to create decent code with Xcode skills, which someone has extracted here [1] but there is near zero mention of accessibility. Worth a read though I think, I learned a few things.
It depends if people care about it or not. I never once thought about accessibility in my non-AI authored app. I tried using the screen reader accessibility option and it was unusable.
I prompted Claude to "make my app accessible and usable with a screen reader" and it pretty much did a perfect job making it usable. *
* I'm not a a11y expert so "perfect job" might be an overstatement, but it made the app completely navigable by me using a screen reader.
Great satire but let's create that same for combobox with server side filtering. Now you have problem because it's not possible with native HTML elements. Many re-implementations are result of missing native elements.
Anything doing server-side work is going to have to be at least somewhat custom. The main problem is there isn't a standard "combobox" at all to speak of: we're still mostly stuck with the same carved-in-stone widget set from Mosaic, whereas native toolkits were more inventive even in the late 80s. Where's Athena's 2d panner widget, for example?
I didn't read any satire in the article at all, it just laid out all the built-in behaviors that a proper button has, and how much work it is to reimplement all of them. Something declarative and CSS-like would have been ideal for customizing elements, but instead we got the half-assed Custom Elements API and the completely different DX atrocity that is Web Components.
I can't really fault Custom Elements too much though, it's an imperfect API for an imperfect DOM and it's better than waiting forever for perfection. But I don't extend the same generosity to the Web Components spec.
In the spec custom elements can inherit from any html element you wish. Which should allow you to only have to add the bits you need to add and let the rest be handled by the native implementation.
The one exception is Safari which has been slowly getting more and more special over time when it comes to web standards but is still relevent. If Safari found their way to supporting it then you shouldn't need to completely re-implement a button or combobox and instead just improve the native versions.
Correct me if I’m wrong, but my understanding is Google would love to make more web standards native (including selectors which have improved on chrome but are basically broken on safari) but Apple holds back progress in a (borderline?) anticompetitive way
I'm not sure if it's Google's fault alone. My impression is, all browsers are holding back on everything HTML-native and JavaScript-free. There have been literal decades of no progress, and only tiny steps forward as of late.
We've had things like https://doc.qt.io/qt-6/qtwidgets-module.html since the late last millenium. Back in the day, there was Delphi, now there is Lazarus, with even nicer Data-Bound widgets. Look at some tutorial for those, that's like magic, and also from before 2000!
Does anyone know why there have been 3 lost decades in native HTML widgets? Any ideas how to fix this?
> My impression is, all browsers are holding back on everything HTML-native and JavaScript-free.
Somewhat tangentially, the official response to a request for WebAuthn without JavaScript[1] was that the big websites don’t care and thus neither do the browsers.
I guess the main issue is that HTML was supposed to be a language to describe documents. We abuse it to design interactive applications. I would rather like to not have one technology to support to different use cases. It’s a shame we are riding that abomination for developing apps.
My guess is that it takes time to research what universal behavior users expect from a component based on examples in existing software. It's universal, so it has to work with everyone: mouse, keyboard, touch; large monitors and tiny phones; screen readers; and users with motor difficulties. And existing components may not have even thought of all of these cases.
For example, they've recently introduced the Interest Invoker API for tooltips on hover. Tooltips are ubiquitous, but they still haven't settled on what the trigger is for non-mouse users. Long press for touch is far less discoverable than mouse hover, for example.
Maybe it's a good thing they didn't rush this design three decades ago, when virtually all users were on desktop.
Maybe VR glasses will be big soon. Do we trigger on 'blink'? 'look harder'? 'eyeball wiggle'?
Maybe voice interfaces? Trigger on 'say it louder'? 'stuttering'? 'hesitant'?
Maybe guestures, facial expressions, thought patterns? 'think hard about that button to trigger tooltip'? 'furl your eyebrows'?
As I've said, decades have passed with no progress. If progress in other fields is a reason for waiting, it'll be stagnant forever and eventually just dead.
Not Google. Microsoft, of all companies started this project: https://open-ui.org/ when Google was busy breaking the web web components, hardware APis etc.
Google was very, very, very late to the project and of course immediately trampled all over it like they did with all the web standards.
Apple isn't holding back progress on that. They are all in on it, though they do tend to be more cautious than the "break fast and lose things" Google.
Right, and the article kind of proves your point even a plain button needs formAssociated + ElementInternals to feel native. A combobox with server-side filtering is a whole other galaxy.
If you use a custom select, update your <datalist>, you should be good, shouldn't you?
There are UI components that are not available in native browser controls (infuriatingly: some are only available in some browsers on some platforms), but even then you're better off writing a shim to replicate normal browser behaviour than ruining the experience for everyone because Firefox on Android doesn't have a colour picker.
Very slightly off topic but also on, I’ve noticed a tendency for well-meaning accessibility folks to drive to bad outcomes to meet some standard. Color is one where the standard is usually right, but there’s pretty strong evidence that the standard is bad in some cases. See APCA v WCAG. https://git.apcacontrast.com/documentation/WhyAPCA.html
If you click any link on this page (to the author’s site) and you dare to use an alternative browser on iOS, it shows a full page modal that can only be navigated around by clicking an “escape” button which tries to execute a Siri shortcut. Apparently in-app browsers are a threat to user freedom, but Orion is caught in the dragnet. Perhaps an example of the paternalist approach to development on the web gone wrong.
Hilarious. The software industry is a parody of itself. Sadly I understood most of the jargon, a sign that I'm in way too deep. Time to step away from the madness of crowds, and return to monkey. Press <button> to restart.
I used to think I had to use a component library, but for some cases it seems all I really needed was CSS to give my webapp that material feeling everyone seems to feel more comfortable with.
I now have a more critical eye and look into potential UI components code to decide if it really does need the custom code or if styling alone can get the job done.
Shoelace upending everything to Web Awesome has given me an incentive to revisit this rather then blindly find/replacing all the sl- prefixes to wa- given how much larger it makes my bundle.
Just coming off a wild ride where a client was sued by a non-customer and a rapacious legal firm, who claimed that said client's website was not sufficiently accessible.
The day after the lawsuit was filed, a company specializing in accessibility testing mysteriously contacted the client, offering a solution. Client had not even gotten notice of the litigation yet.
The net result of this was several tens of thousands of dollars spent actually removing Aria tags and using standard modern HTML on their aging website, to barely meet some threshold that appeared to be compliant.
The company who did the "work", and I mean, it was barely any work, maybe 100 LoC, stands by it and says the client won't get sued again, as long as they pay for ongoing compliance testing. So it's all a fucking racket.
I pointed out to the client that I didn't think that this half-assed effort was remotely sufficient to actually improve accessibility, but they had an interesting response. Which was this:
In 3 years, all this compliance shit will be out the window, because AI screen readers and agents are going to make the whole point moot.
Excellent response. I said it before, forcing the responsibility of making thing accessible on the world makes no sense now (made sense before though). Just use an AI to interact with the app/website; it can provide whatever sort of accessibility you need. It should be built as a chrome extension or even native...
Does it count if you have to pay for a service for something to be made accessible? I'm sure a blind person nowadays could hire an assistant to use their computer for them, but that would not be reasonable.
Because the law doesn't stipulate which methods you use to make something accessible to people with disabilities. It just requires that everyone have equal access. To litigate, someone has to show that they couldn't access something, and that the failure to access it caused them some measurable harm. In a couple years you can show a judge that a free LLM screen reader could have solved their access issues, and my guess is that those cases will then be thrown out, and the predatory law firms will move on to something juicier.
It’s not just about reading the screen, it’s about using it. It’s quite the downgrade going through a slow API hoping to be able to navigate compared to the 10x speed (or more) of screen readers.
Then you have the problem of LLMs being stateless and sensitive information etc etc.
Great article! I spot a few bugs with event handling, but in some ways that adds to the premise.
The implementation assumes that onpointerup is mutually exclusive to the other two, but it fires in addition to mouse/touch events. Only onpointerup is needed, if you include onmouseup and ontouchstart then the button action will fire twice.
However, you also need an onpointerdown handler to verify that the pointer press started inside the button. Without it, the button would activate if you started holding down the mouse button outside the button area, and then releasing inside the button area.
The only browser Apple is blocking it on is Safari: other browsers implement it just fine, and the standard passed over Apple's objections. The rationale was architectural, arguing that extending built-in components would lead either to brittle components that would break when new properties were added or causing the specification of builtin components to freeze forever to avoid such breakage. I'm not sure I buy the arguments 100%, but for sure it's not evil/incompetent board executives twirling their mustaches as they deliberately break the web: https://github.com/WICG/webcomponents/issues/509#issuecommen...
This is sort of correct on webkits side. inheritance chains especially when you don't control who is inheriting from you are going to be very brittle. The standard would probably have been better if it had been specified as a form of composition instead. However not supporting something like this is largely worse than just doing the inheritance. I'm not sure this is a hill I would die on despite largely agreeing with the webkit folks here philosophically.
Standard practice in every decent frontend framework has been to create a component, that wraps the <button> without rendering its own dom node. This avoids the typical downsides of inheritance.
Can we not just do `:host { display: contents }` and use the same approach?
The is="" customized-built-in path (extends HTMLButtonElement) is exactly what would collapse that 500-line reimplementation. Safari refusing it is why you still fall back to a full autonomous element + ElementInternals.
No one creates their own buttons anymore anyways. People just use a component library like shadcn or mui which if well implemented already is built on native html components.
This would have been a very smart and useful article up until 3 years ago. Now with AI doing this work is a minute, with most if not all considerations baked in, if some strange quirk would need it. Frameworks and dependencies made and replaced by custom "ground-up" creations is now a plausible reality. Not necessarily useful but doable and most importantly, testable in a fraction of time. We should readjust our sensibilities to that.
By default AI doesn't bake in all considerations. By nature of how it works it behaves like a human, i. e. making similar mistakes and oversights... I feel like this could somewhat ironically be shown with exactly this task. Let's let it make button and see how many ways it gets it wrong.
> Now with AI doing this work is a minute ... Frameworks and dependencies made and replaced by custom "ground-up" creations is now a plausible reality.
"You only have to want it and believe in it, then it will succeed."
- Count Ferdinand von Zeppelin
"The airship [is] the future of commercial air transport in general."
- Dr. Hugo Eckener
"The age of the airship is no longer a dream of the future; it is a reality of the present. Giant dirigibles will soon cross every ocean, making obsolete the slow surface ships of today."
There were hundreds of such misplaced tech hopes, and hundreds that did become true - all those "visionary" quotes of newspapers talking about video calling and remote libraries. Would have anyone advocated a Rust rewrite of Bun before? The community would have frowned upon the idea, saying the effor would never be worth it. And now here we are.
I'm not saying use custom html elements because we can. But if somehow a html button is a valid technical problem, it can be reasonably done well for the scope of that app.
> Would have anyone advocated a Rust rewrite of Bun before?
That’s hardly a “tech hope” or “visionary”. Dirigibles continue to be interesting and fascinating to new generations, even if just as a concept; the language used to write a JavaScript runtime is uninteresting and unimportant in the scheme of things.
> The community would have frowned upon the idea, saying the effor would never be worth it. And now here we are.
Here we are where? Is the Rust release out yet? Didn’t it have tens of thousands of `unsafe` blocks? What’s so great about it? At this point in time, even implying the transition was a success is the same as calling the Hindenburg or the Titanic a success. You’ve seen the thing exists but have no idea how it’ll perform in the real world under real scrutiny and real scenarios. Perhaps that wouldn’t matter had much of Bun was just an internal project used by just one company, but it isn’t.
There’s an interesting economic point to be made about the specialization of labor and the benefits that arise from that.
Just like it is more efficient to have a food system than to have everyone feed themselves from their backyard (if they have one), maybe someday people will realize that it will be more efficient to build things once and re-use.
Similarly, every argument for “AI makes it cheaper so we can do it now” falls apart under “AI also makes it cheaper to not do it”.
What do you mean with testable in a fraction of time?
Generated tests can help, and if we go into that direction we can now certainly afford to introduce more proven code (Lean/Roq/Frama-C…), but that will still not be wild reality proof until it faces the whole user base and their widely different environments.
And large load of code is still large load of code.
I expected a blog on how to write a button using a graphics API and basic OS interface; but instead I completely mistook (what the comments are saying is) sarcasm as advice on how to program for the web. I'm not a web guy, so I'm not really even sure why this is sarcastic, isn't semantic web good? I can't keep up with the opinions.
Semantic web is good if you are making web documents not web applications.
Have a type and: submit a form; reset a form; or not do anything with the related form.
No one uses buttons to submit a form in web applications. You use buttons to start/stop/change interaction flow.
Native browser controls are not workable in a modern web application. It is not that developers are lazy it is that you get requirements from businesses that no one would pay for implementing using native controls because it would cost too much to do it right, where right means „how customers want it and how they want to use it” not „technically right like some native browser control nerds feel world should work”.
I tried to pass the page through Claude/ChatGPT to ask questions about the article. The AI hostility is real! This is the first time I’ve seen an instruction to AI in a web page that asks AI not to summarise.
I think it's been set up to server some other content if LLMs access the page as they both complained about seeing more general ARIA stuff. But copying and pasting the page into Claude was what detected the instruction to AI to not allow summaries but Claude overruled it and said my request was more important!
For those downvoting this are you doing so because I tried to pass it through an LLM, I commented that it was hostile to AI, because it's being hostile or something else?
The crazies part is that when we actually research it, a default button is about 20% faster than the the flat nonsense we've settled on (https://www.theregister.com/offbeat/2017/09/05/its-official-...) and nearly a decade letter we still prefer looks over usability.
Look at the progress of Flash/AIR AS3 as an embedded runtime prior to its annihilation. By 2010 or so, it had the capability to leverage the GPU on pretty much any device, directly uploading bitmaps and shaders. It had garbage collection as good as or better than any existing [modern] JS engine, had strong types and compile time errors. It was better and cleaner than the modern fractured Typescript-and-canvas web app gaming paradigm in every respect, except for one: It was closed source.
I'm not a fan of AS3's demise, nor of the current state of affairs. We are stuck a decade ago because of it.
But I can also imagine a world where Adobe has a stranglehold in 2026 on most cross-platform game development, and where little arose to compete with it outside their ecosystem. And they've become such a hideous company blinded to their users, even without the advantage they used to have of dominating browser plugins, that I can see now maybe it was for the best that they're not the guardians of the way we do things anymore.
The anarchic process of creating standards is messy, and it results in a huge amount of wasted effort by developers. And it's often a lot less fun.
On the other hand, the job is to make shit using whatever is available.
Instead, I've had people from Microsoft itself recommending me to "just write it in HTML, there's no standard" and "accessibility sucks with native".
When you have the market leader telling you to write HTML for their OS, it's a carte blanche to do it everywhere.
At this point, I think HTML+JS is able to be a better choice than SwiftUI for most things: Yes, some stuff will still need to go to a native layer, but that's true for HTML as well. ;P
Is it a better interface and developer experience? For sure. Is it gonna replace the previous API? Doubtful.
I have to admit I'm still ignoring it though.
Others invented plenty of UI paradigms before Apple: swiping, skeomorphism, etc.
It's not just that I think, using their native components also ensures accessibility and consistent UX throughout different apps, which is a huge benefit to e.g. screen reader users. Everyone else - especially web interface builders, especially if they eschew just using native elements - reinvents the wheel and considers accessibility as an afterthought.
At least we have laws now that mandate accessible websites for corporates, in addition to government sites.
And it was a security nightmare...
That's when I learned about the halting problem.
For whatever reason, developers and some users expect an app to look the same across all platforms, while also looking distinct from other apps—otherwise, the app looks indistinguishable from a low effort one. This involves creating a design system and departing from each operating system's native widgets.
Knowing when to apply novelty and when to apply the familiar is the game.
https://winworldpc.com/screenshot/c5a0e280-a1c3-974a-24c2-90...
Imagine everything man-made suddenly disappears but not the knowledge individuals carry. How long until we have an iPhone (or a plastic shirt button)? Would it even be any faster than the first time around?
https://www.youtube.com/@primitivetechnology9550/videos
You can literally run a "open this codebase and improve accessibility where you can" and get mostly perfectly good changes. Models and harnesses can be tuned to prioritize it by default, but usually the developer only needs to nudge it a bit to get good accessibility.
[1] https://github.com/superagents-lab/xcode27-skills/
I prompted Claude to "make my app accessible and usable with a screen reader" and it pretty much did a perfect job making it usable. *
* I'm not a a11y expert so "perfect job" might be an overstatement, but it made the app completely navigable by me using a screen reader.
I didn't read any satire in the article at all, it just laid out all the built-in behaviors that a proper button has, and how much work it is to reimplement all of them. Something declarative and CSS-like would have been ideal for customizing elements, but instead we got the half-assed Custom Elements API and the completely different DX atrocity that is Web Components.
I can't really fault Custom Elements too much though, it's an imperfect API for an imperfect DOM and it's better than waiting forever for perfection. But I don't extend the same generosity to the Web Components spec.
The one exception is Safari which has been slowly getting more and more special over time when it comes to web standards but is still relevent. If Safari found their way to supporting it then you shouldn't need to completely re-implement a button or combobox and instead just improve the native versions.
We've had things like https://doc.qt.io/qt-6/qtwidgets-module.html since the late last millenium. Back in the day, there was Delphi, now there is Lazarus, with even nicer Data-Bound widgets. Look at some tutorial for those, that's like magic, and also from before 2000!
Does anyone know why there have been 3 lost decades in native HTML widgets? Any ideas how to fix this?
Somewhat tangentially, the official response to a request for WebAuthn without JavaScript[1] was that the big websites don’t care and thus neither do the browsers.
[1] https://github.com/w3c/webauthn/issues/1255
For example, they've recently introduced the Interest Invoker API for tooltips on hover. Tooltips are ubiquitous, but they still haven't settled on what the trigger is for non-mouse users. Long press for touch is far less discoverable than mouse hover, for example.
Maybe it's a good thing they didn't rush this design three decades ago, when virtually all users were on desktop.
Maybe VR glasses will be big soon. Do we trigger on 'blink'? 'look harder'? 'eyeball wiggle'?
Maybe voice interfaces? Trigger on 'say it louder'? 'stuttering'? 'hesitant'?
Maybe guestures, facial expressions, thought patterns? 'think hard about that button to trigger tooltip'? 'furl your eyebrows'?
As I've said, decades have passed with no progress. If progress in other fields is a reason for waiting, it'll be stagnant forever and eventually just dead.
Google was very, very, very late to the project and of course immediately trampled all over it like they did with all the web standards.
Apple isn't holding back progress on that. They are all in on it, though they do tend to be more cautious than the "break fast and lose things" Google.
There are UI components that are not available in native browser controls (infuriatingly: some are only available in some browsers on some platforms), but even then you're better off writing a shim to replicate normal browser behaviour than ruining the experience for everyone because Firefox on Android doesn't have a colour picker.
Missing part is dynamically updating the datalist in an efficient way
If you click any link on this page (to the author’s site) and you dare to use an alternative browser on iOS, it shows a full page modal that can only be navigated around by clicking an “escape” button which tries to execute a Siri shortcut. Apparently in-app browsers are a threat to user freedom, but Orion is caught in the dragnet. Perhaps an example of the paternalist approach to development on the web gone wrong.
The website works just fine for me on Firefox+iOS, it seems like whatever matching the author is doing just doesn't include detection for Orion.
https://youtu.be/xE9W9Ghe4Jk?is=wmaIJ6LXNW-mZ49Q
I now have a more critical eye and look into potential UI components code to decide if it really does need the custom code or if styling alone can get the job done.
Shoelace upending everything to Web Awesome has given me an incentive to revisit this rather then blindly find/replacing all the sl- prefixes to wa- given how much larger it makes my bundle.
The day after the lawsuit was filed, a company specializing in accessibility testing mysteriously contacted the client, offering a solution. Client had not even gotten notice of the litigation yet.
The net result of this was several tens of thousands of dollars spent actually removing Aria tags and using standard modern HTML on their aging website, to barely meet some threshold that appeared to be compliant.
The company who did the "work", and I mean, it was barely any work, maybe 100 LoC, stands by it and says the client won't get sued again, as long as they pay for ongoing compliance testing. So it's all a fucking racket.
I pointed out to the client that I didn't think that this half-assed effort was remotely sufficient to actually improve accessibility, but they had an interesting response. Which was this:
In 3 years, all this compliance shit will be out the window, because AI screen readers and agents are going to make the whole point moot.
I can't really disagree with that.
If that's the case, why didn't they spend a few bucks on Claude to do the accessibility changes?
Since the whole compliance racket is totally disconnected from actual accessibility outcomes, why would AI have any impact here?
There’s a standard and a law and money to be made.
It seems like it'd be equally trivial to demonstrate that said reader doesn't work on some combination of hardware and software.
The implementation assumes that onpointerup is mutually exclusive to the other two, but it fires in addition to mouse/touch events. Only onpointerup is needed, if you include onmouseup and ontouchstart then the button action will fire twice.
However, you also need an onpointerdown handler to verify that the pointer press started inside the button. Without it, the button would activate if you started holding down the mouse button outside the button area, and then releasing inside the button area.
class SaganButton extends HTMLButtonElement { … }
Anyone know the reasoning they’re blocking this?
Can we not just do `:host { display: contents }` and use the same approach?
"You only have to want it and believe in it, then it will succeed."
- Count Ferdinand von Zeppelin
"The airship [is] the future of commercial air transport in general."
- Dr. Hugo Eckener
"The age of the airship is no longer a dream of the future; it is a reality of the present. Giant dirigibles will soon cross every ocean, making obsolete the slow surface ships of today."
- Popular Mechanics, December 1929
I'm not saying use custom html elements because we can. But if somehow a html button is a valid technical problem, it can be reasonably done well for the scope of that app.
That’s hardly a “tech hope” or “visionary”. Dirigibles continue to be interesting and fascinating to new generations, even if just as a concept; the language used to write a JavaScript runtime is uninteresting and unimportant in the scheme of things.
> The community would have frowned upon the idea, saying the effor would never be worth it. And now here we are.
Here we are where? Is the Rust release out yet? Didn’t it have tens of thousands of `unsafe` blocks? What’s so great about it? At this point in time, even implying the transition was a success is the same as calling the Hindenburg or the Titanic a success. You’ve seen the thing exists but have no idea how it’ll perform in the real world under real scrutiny and real scenarios. Perhaps that wouldn’t matter had much of Bun was just an internal project used by just one company, but it isn’t.
Just like it is more efficient to have a food system than to have everyone feed themselves from their backyard (if they have one), maybe someday people will realize that it will be more efficient to build things once and re-use.
Similarly, every argument for “AI makes it cheaper so we can do it now” falls apart under “AI also makes it cheaper to not do it”.
Generated tests can help, and if we go into that direction we can now certainly afford to introduce more proven code (Lean/Roq/Frama-C…), but that will still not be wild reality proof until it faces the whole user base and their widely different environments.
And large load of code is still large load of code.
Native browser controls are not workable in a modern web application. It is not that developers are lazy it is that you get requirements from businesses that no one would pay for implementing using native controls because it would cost too much to do it right, where right means „how customers want it and how they want to use it” not „technically right like some native browser control nerds feel world should work”.