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.
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
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.
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.
No. I need something like <option value="123"><img src="...">Mars</option> - separated internal representation and value and dynamically updated. If i can fit whole list to client memory why should i choose datalist over select?
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.
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.
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.
> 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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
You probably need to change the thought experiment to get at what you're really trying to get at. If all man-made things disappeared tomorrow, you're talking pipes, wires, streets, houses, antibiotics, the immediate effect is very close to 8 billion people die within a few weeks. The hundred thousandor so survivors may know what they already knew, but now they need to find a way to find each other, write it all down, without pens or paper, make more people, and teach those new people so the knowledge isn't lost within a generation or two, all while also building enough infrastructure to at least keep the tiny communities still around from also starving.
All of the post-apocalypse LARP scenarios other responses are describing tend to assume at least books and some small number of durable structures survive. If nothing at all makes it, the first thing that happens is most everyone not living on a ground floor dies instantly from falling. Everyone living where it freezes dies in a few hours from exposure. Most people living anywhere experiencing a heat wave die from heat exhaustion in the next day or two. Most everyone else everywhere else dies from starvation or disease in the next few weeks. Even if you're living on a farm, you've got no fences or tools, so you better hope it's a farm with lots of edible plants and it's near harvest season. If you live in a city, you have no hope at all. Even existing food stores will spoil quickly with no containers or refrigeration. The people who do the best will be Hadza and uncontacted tribes and what not that lose their spears and tents, but all they have to do to get back to their prior situation is make more spears and tents, which thankfully doesn't require a global transportation network or modern manufacturing techniques. They're not the ones who know how to build iPhones, though. I'm not sure anyone knows how to build an iPhone, really. The knowledge is probably largely digital. The chief engineer at Apple knows where to look and who to ask, but no single person has all of the knowledge in their own head.
> You probably need to change the thought experiment to get at what you're really trying to get at.
I am not really trying to get to anything except to have fun thinking about how society would organise itself. And since this is not an exam, everyone's free to think through different versions and enjoy the question as they like.
As for me, normally it comes up in a discussion and we develop and make assumptions as we go, but I've prefer to change as little as possible e.g. buildings/infrastructure do disappear but people "land" gently. And then most of what you said would be true: people in inappropriate climates, far away from a source of water or food die. I don't think it makes the thought experiment any less interesting to think about. In fact, the reason I like it is because progress may become so slow that some generations later we'd start believing or question in mythical iPhones and technologies.
46 comments
[ 4.0 ms ] story [ 65.0 ms ] threadI 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.
Missing part is dynamically updating the datalist in an efficient way
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.
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.
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.
"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
In a same vain, why create functions or classes, when AI can rewrite the code in place and keep track of rules.
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.
Even Hollywood movies show better UIs than modern crap.
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.
class SaganButton extends HTMLButtonElement { … }
Anyone know the reasoning they’re blocking this?
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 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.
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.
https://youtu.be/xE9W9Ghe4Jk?is=wmaIJ6LXNW-mZ49Q
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?
All of the post-apocalypse LARP scenarios other responses are describing tend to assume at least books and some small number of durable structures survive. If nothing at all makes it, the first thing that happens is most everyone not living on a ground floor dies instantly from falling. Everyone living where it freezes dies in a few hours from exposure. Most people living anywhere experiencing a heat wave die from heat exhaustion in the next day or two. Most everyone else everywhere else dies from starvation or disease in the next few weeks. Even if you're living on a farm, you've got no fences or tools, so you better hope it's a farm with lots of edible plants and it's near harvest season. If you live in a city, you have no hope at all. Even existing food stores will spoil quickly with no containers or refrigeration. The people who do the best will be Hadza and uncontacted tribes and what not that lose their spears and tents, but all they have to do to get back to their prior situation is make more spears and tents, which thankfully doesn't require a global transportation network or modern manufacturing techniques. They're not the ones who know how to build iPhones, though. I'm not sure anyone knows how to build an iPhone, really. The knowledge is probably largely digital. The chief engineer at Apple knows where to look and who to ask, but no single person has all of the knowledge in their own head.
I am not really trying to get to anything except to have fun thinking about how society would organise itself. And since this is not an exam, everyone's free to think through different versions and enjoy the question as they like.
As for me, normally it comes up in a discussion and we develop and make assumptions as we go, but I've prefer to change as little as possible e.g. buildings/infrastructure do disappear but people "land" gently. And then most of what you said would be true: people in inappropriate climates, far away from a source of water or food die. I don't think it makes the thought experiment any less interesting to think about. In fact, the reason I like it is because progress may become so slow that some generations later we'd start believing or question in mythical iPhones and technologies.