8 ms·

If you want to create a button from scratch, you must first create the universe

248 points by treve 3mo ago

artisinal 3mo ago
I love how this clearly satirical piece unfortunately is how a lot of websites operate.
- all2 3mo ago
  It's also very educational. Having used mostly frameworks or raw html5 with HTMX I stood not know most of the things that page talked about.
mireq2 3mo ago
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.
- daniela-scott 3mo ago
  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.
- repeekad 3mo ago
  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
  - chuckadams 3mo ago
    Because Google is known for holding back in order to not get too far ahead of other browsers?
  - thyristan 3mo ago
    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 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?
    - SvenL 3mo ago
      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.
      - krapp 3mo ago
        An HTML document is also an interactive application - that's what hyperlinks and forms are. The script tag has been a part of HTML since the late 90s, the original intent was that it supported multiple scripting languages. The distinction between "app" and "document" is a modern ideological quirk, few sites are strictly one or the other.
    - sheept 3mo ago
      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.
  - troupo 3mo ago
    Not Google. Microsoft, of all companies started this project: https://open-ui.org/ 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.
- chuckadams 3mo ago
  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.
  - ezekiel68 3mo ago
    I imagine the commenter was referring to the article title wrt satire.
    - chuckadams 3mo ago
      Fair enough, I'd call it "homage" perhaps.
  - panny 3mo ago
    >The main problem is there isn't a standard "combobox" at all to speak of But there is. You'll be so happy to learn about datalist today, https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_datalist https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_d...
    - 6510 3mo ago
      It use to work but chrome on android shows the datalist items as a horizontal scrollable row above the keyboard (useless) and ignores input (even more useless) on windows it shows the datalist as a scrollable popup (confusing?) and ignores input (useless) while firefox on android completely ignores datalist and on windows you have to click the input twice to have the initial list show up. It took forever but safari mobile got it right. Extra fun to be had if you attempt to dynamically update the list. Conclusion: utter garbage, stay away from it. I just typed this by hand (lol) in 3-4 minutes: https://jsfiddle.net/tjc4mpxe/ https://jsfiddle.net/tjc4mpxe/ This is what we are waiting for? This is what is taking so long for browsers to support?
- youngtaff 3mo ago
  <input> with <datalist> can provide a combobox Missing part is dynamically updating the datalist in an efficient way
  - roundabout-host 3mo ago
    [dead]
- deleted 3mo ago
  [deleted]
- jeroenhd 3mo ago
  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.
  - mireq2 2mo ago
    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?
- zaphar 3mo ago
  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.
jzer0cool 3mo ago
So a button big bang. Born the Light (Minimalist) and Dark patterns
brookritz 3mo ago
<input type="button"> ?
- zombot 3mo ago
  Not enough AI.
poisonborz 3mo ago
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.
- sureglymop 3mo ago
  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.
- nxc18 3mo ago
  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”.
  - deleted 3mo ago
    [deleted]
- Zanfa 3mo ago
  It hasn't even been a few weeks since I had AI use a button + onClick handler for navigation instead of a simple anchor tag...
- psychoslave 3mo ago
  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.
dlcarrier 3mo ago
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-users-navigate-flat-ui-designs-22-per-cent-slower/590397 https://www.theregister.com/offbeat/2017/09/05/its-official-...) and nearly a decade letter we still prefer looks over usability.
- noduerme 3mo ago
  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.
  - master-lincoln 3mo ago
    > except for one: It was closed source. And it was a security nightmare...
noduerme 3mo ago
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 can't really disagree with that.
- nxc18 3mo ago
  > 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. 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.
  - noduerme 3mo ago
    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.
    - techpression 3mo ago
leecommamichael 3mo ago
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.
- ozim 3mo ago
  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”.
  - Sankozi 3mo ago
    Agreed, that point in the article is lacking any source. Big part of complexity of the implementation was introducing form attributes and behavior.
  - roundabout-host 3mo ago
    [dead]
sunnybeetroot 3mo ago
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.
- gorbypark 3mo ago
  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.
- DanielHB 3mo ago
  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.
- stogot 3mo ago
  My LLMs seem to grasp for React when I just ask for a simple webpage to display something simple. Its infuriating
- willtemperley 3mo ago
  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. [1] https://github.com/superagents-lab/xcode27-skills/ https://github.com/superagents-lab/xcode27-skills/
karhuton 3mo ago
My understanding is Apple / Webkit is blocking custom element extension on native HTML elements, which would cut down this 500 line monster to: class SaganButton extends HTMLButtonElement { … } Anyone know the reasoning they’re blocking this?
- chuckadams 3mo ago
  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#issuecomment-230700060 https://github.com/WICG/webcomponents/issues/509#issuecommen...
  - SebastianKra 3mo ago
    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?
  - zaphar 3mo ago
    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.
    - chuckadams 3mo ago
      That's my take on it too. The DOM itself is full of issues from its naive inheritance-happy OO design, and could use a refresh into something with better separation between data and presentation, but it's what we have right now in the real world. There's always going to be footguns, we can't put safeties on all of them. I have to wonder if it's something in the design of WebKit that makes inheritance particularly difficult to implement. As for potential property collisions, I think the common wisdom is to just ensure the property name contains a dash, since the html5 spec goes out of its way to avoid using them. Doesn't solve brittle inheritance hierarchies in general, but it does at least stay out of the way of built-in behavior.
nxc18 3mo ago
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 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.
- roundabout-host 3mo ago
  [dead]
- jeroenhd 3mo ago
  > and you dare to use an alternative browser on iOS 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.
- poly2it 3mo ago
  I can't take a design opinion seriously when it is hosted on a site as hideous as that.
  - jatora 3mo ago
    agreed. horrible.
shuffledrummer 3mo ago
Great article, very interesting
Unified-Mentor 3mo ago
[flagged]
pverheggen 3mo ago
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.
otikik 3mo ago
If you wish to make a button from scratch
umarratra 3mo ago
[flagged]
deleted 3mo ago
[deleted]
joshuaS98 3mo ago
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.
vugar82 3mo ago
[flagged]
cube00 3mo ago
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.
aaronrobinson 3mo ago
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.
- Shorel 3mo ago
  Good. This is the resistance.
- deleted 3mo ago
  [deleted]
- graemep 3mo ago
  Did that actually work.
  - aaronrobinson 3mo ago
    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!
- aaronrobinson 3mo ago
  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?
- tagyro 3mo ago
  And why is that a problem? Their website, their content, their choice.
  - aaronrobinson 3mo ago
    I didn’t suggest it was a problem?
StarPA 3mo ago
[flagged]
luciana1u 3mo ago
[flagged]
alexisread 3mo ago
Thought this was a reference to this parody https://youtu.be/xE9W9Ghe4Jk?is=wmaIJ6LXNW-mZ49Q https://youtu.be/xE9W9Ghe4Jk?is=wmaIJ6LXNW-mZ49Q
- lioeters 3mo ago
  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.
hs586 3mo ago
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?
- mhb 3mo ago
  John Plant has been working to get to the Iron Age for eleven years, but he's doing it for the lulz. https://www.youtube.com/@primitivetechnology9550/videos https://www.youtube.com/@primitivetechnology9550/videos
- goodmythical 3mo ago
  I've always wanted to write a "How to make a peanut butter and jelly" cookbook that starts with "okay, first you're going to need to find a stalk of wheat that's ready to seed, but don't worry about germinating it because we'll do that in the next chapter.
- Night_Thastus 3mo ago
  It's hard to say if we ever would. We used up a lot of the very easy to access sources of many resources - minerals, oil, etc. Without having access to the advanced techniques, I think it's unlikely we'd even reach the industrial revolution again.
- OkayPhysicist 3mo ago
  Almost certainly. I can go out into the woods behind my house and get into the iron age in a few days (most of that time would be waiting for clay to dry and charcoal pits to cool). That cuts out ~300k years of anatomically modern human history. Whether or not it would be possible to bootstrap the industrial revolution without easily accessible coal and petroleum is a bigger question. We might lose electricity for a while. There's not a lot of utility for electricity in pre-industrial society. Like, given enough copper, I could make a wind turbine, but I can't casually make a useful lightbulb. Maybe a ceiling fan, but it would almost certainly be easier to run that off of mechanical power directly via a series of gears and belts. Electrochemistry would be a neat party trick, but I don't think my shoddily built wind turbine would generate enough juice to process aluminum. Firearms would probably continue to exist. I could make a musket, and its utility for hunting and defense would make it immediately worth it. Black powder's not terribly difficult to manufacture from base ingredients. Are we including domesticated crops as "man-made"? Because that would complicate matters. A lot of knowledge could be lost in the time it takes to rebreed the kinds of grains that allow for stable settlement. We wouldn't need to re-invent writing, since that's just knowledge, and that would give a pretty big leg up in not losing a bunch of knowledge every time someone dies. On the whole, if we keep selectively bred crops, I'd say we'd be bumped back to about the Middle Ages at the most. If we're losing the crops, then it would come down to whether we could preserve our more advanced knowledge long enough for agriculture to redevelop.
cpncrunch 3mo ago
I find this cute and amusing, having had to write buttons in assembly language in the 80s, drawing the buttons into video memory using blits.
- sumtechguy 3mo ago
  I did something similar in win16/32 at one point. Think we wanted something special with graphics on the button. We basically had to recreate all of the actions of focus/unfocus/etc. Everything a normal button could do. Now that I have done more stuff I a know for a fact I made my life way harder than it should have been and could have subclassed. But it was a full button recreation. Styling messaging and all. You have to watch for things like what if someone clicks outside of your button but lets go inside the button. What does that mean? All sorts of weird side effects. What if your button has focus and someone starts typing? What if someone clicks outside of your button but holds the button down as they slide across your button? What does that look like? Would I ever do it again. Probably not. Seriously use the built in ones.
chromadon 3mo ago
Nothing will ever come close to WinForms.
socalgal2 3mo ago
Interestingly the code on the page doesn't work. onmouseup and onpointerup are the wrong event for a button because the button should only send an "clicked" event if the user pressed DOWN on the button, then released while still on the button. The example code though will send an event even if the user started off the button. I think that emphasizes the point though. You need more code to do it correctly.

248 points by treve 3mo ago

artisinal 3mo ago

I love how this clearly satirical piece unfortunately is how a lot of websites operate.

all2 3mo ago
It's also very educational. Having used mostly frameworks or raw html5 with HTMX I stood not know most of the things that page talked about.

mireq2 3mo ago

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.

daniela-scott 3mo ago
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.
repeekad 3mo ago
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
- chuckadams 3mo ago
  Because Google is known for holding back in order to not get too far ahead of other browsers?
- thyristan 3mo ago
  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 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?
  - SvenL 3mo ago
    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.
    - krapp 3mo ago
      An HTML document is also an interactive application - that's what hyperlinks and forms are. The script tag has been a part of HTML since the late 90s, the original intent was that it supported multiple scripting languages. The distinction between "app" and "document" is a modern ideological quirk, few sites are strictly one or the other.
  - sheept 3mo ago
    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.
- troupo 3mo ago
  Not Google. Microsoft, of all companies started this project: https://open-ui.org/ 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.
chuckadams 3mo ago
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.
- ezekiel68 3mo ago
  I imagine the commenter was referring to the article title wrt satire.
  - chuckadams 3mo ago
    Fair enough, I'd call it "homage" perhaps.
- panny 3mo ago
  >The main problem is there isn't a standard "combobox" at all to speak of But there is. You'll be so happy to learn about datalist today, https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_datalist https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_d...
  - 6510 3mo ago
    It use to work but chrome on android shows the datalist items as a horizontal scrollable row above the keyboard (useless) and ignores input (even more useless) on windows it shows the datalist as a scrollable popup (confusing?) and ignores input (useless) while firefox on android completely ignores datalist and on windows you have to click the input twice to have the initial list show up. It took forever but safari mobile got it right. Extra fun to be had if you attempt to dynamically update the list. Conclusion: utter garbage, stay away from it. I just typed this by hand (lol) in 3-4 minutes: https://jsfiddle.net/tjc4mpxe/ https://jsfiddle.net/tjc4mpxe/ This is what we are waiting for? This is what is taking so long for browsers to support?
youngtaff 3mo ago
<input> with <datalist> can provide a combobox Missing part is dynamically updating the datalist in an efficient way
- roundabout-host 3mo ago
  [dead]
deleted 3mo ago
[deleted]
jeroenhd 3mo ago
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.
- mireq2 2mo ago
  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?
zaphar 3mo ago
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.

jzer0cool 3mo ago

So a button big bang. Born the Light (Minimalist) and Dark patterns

brookritz 3mo ago

<input type="button"> ?

zombot 3mo ago
Not enough AI.

poisonborz 3mo ago

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.

sureglymop 3mo ago
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.
nxc18 3mo ago
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”.
- deleted 3mo ago
  [deleted]
Zanfa 3mo ago
It hasn't even been a few weeks since I had AI use a button + onClick handler for navigation instead of a simple anchor tag...
psychoslave 3mo ago
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.

dlcarrier 3mo ago

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-users-navigate-flat-ui-designs-22-per-cent-slower/590397 https://www.theregister.com/offbeat/2017/09/05/its-official-...) and nearly a decade letter we still prefer looks over usability.

noduerme 3mo ago
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.
- master-lincoln 3mo ago
  > except for one: It was closed source. And it was a security nightmare...

noduerme 3mo ago

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 can't really disagree with that.

nxc18 3mo ago
> 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. 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.
- noduerme 3mo ago
  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.
  - techpression 3mo ago

leecommamichael 3mo ago

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.

ozim 3mo ago
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”.
- Sankozi 3mo ago
  Agreed, that point in the article is lacking any source. Big part of complexity of the implementation was introducing form attributes and behavior.
- roundabout-host 3mo ago
  [dead]

sunnybeetroot 3mo ago

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.

gorbypark 3mo ago
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.
DanielHB 3mo ago
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.
stogot 3mo ago
My LLMs seem to grasp for React when I just ask for a simple webpage to display something simple. Its infuriating
willtemperley 3mo ago
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. [1] https://github.com/superagents-lab/xcode27-skills/ https://github.com/superagents-lab/xcode27-skills/

karhuton 3mo ago

My understanding is Apple / Webkit is blocking custom element extension on native HTML elements, which would cut down this 500 line monster to: class SaganButton extends HTMLButtonElement { … } Anyone know the reasoning they’re blocking this?

chuckadams 3mo ago
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#issuecomment-230700060 https://github.com/WICG/webcomponents/issues/509#issuecommen...
- SebastianKra 3mo ago
  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?
- zaphar 3mo ago
  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.
  - chuckadams 3mo ago
    That's my take on it too. The DOM itself is full of issues from its naive inheritance-happy OO design, and could use a refresh into something with better separation between data and presentation, but it's what we have right now in the real world. There's always going to be footguns, we can't put safeties on all of them. I have to wonder if it's something in the design of WebKit that makes inheritance particularly difficult to implement. As for potential property collisions, I think the common wisdom is to just ensure the property name contains a dash, since the html5 spec goes out of its way to avoid using them. Doesn't solve brittle inheritance hierarchies in general, but it does at least stay out of the way of built-in behavior.

nxc18 3mo ago

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 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.

roundabout-host 3mo ago
[dead]
jeroenhd 3mo ago
> and you dare to use an alternative browser on iOS 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.
poly2it 3mo ago
I can't take a design opinion seriously when it is hosted on a site as hideous as that.
- jatora 3mo ago
  agreed. horrible.

shuffledrummer 3mo ago

Great article, very interesting

Unified-Mentor 3mo ago

[flagged]

pverheggen 3mo ago

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.

otikik 3mo ago

If you wish to make a button from scratch

umarratra 3mo ago

[flagged]

deleted 3mo ago

[deleted]

joshuaS98 3mo ago

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.

vugar82 3mo ago

[flagged]

cube00 3mo ago

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.

aaronrobinson 3mo ago

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.

Shorel 3mo ago
Good. This is the resistance.
deleted 3mo ago
[deleted]
graemep 3mo ago
Did that actually work.
- aaronrobinson 3mo ago
  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!
aaronrobinson 3mo ago
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?
tagyro 3mo ago
And why is that a problem? Their website, their content, their choice.
- aaronrobinson 3mo ago
  I didn’t suggest it was a problem?

StarPA 3mo ago

[flagged]

luciana1u 3mo ago

[flagged]

alexisread 3mo ago

Thought this was a reference to this parody https://youtu.be/xE9W9Ghe4Jk?is=wmaIJ6LXNW-mZ49Q https://youtu.be/xE9W9Ghe4Jk?is=wmaIJ6LXNW-mZ49Q

lioeters 3mo ago
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.

hs586 3mo ago

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?

mhb 3mo ago
John Plant has been working to get to the Iron Age for eleven years, but he's doing it for the lulz. https://www.youtube.com/@primitivetechnology9550/videos https://www.youtube.com/@primitivetechnology9550/videos
goodmythical 3mo ago
I've always wanted to write a "How to make a peanut butter and jelly" cookbook that starts with "okay, first you're going to need to find a stalk of wheat that's ready to seed, but don't worry about germinating it because we'll do that in the next chapter.
Night_Thastus 3mo ago
It's hard to say if we ever would. We used up a lot of the very easy to access sources of many resources - minerals, oil, etc. Without having access to the advanced techniques, I think it's unlikely we'd even reach the industrial revolution again.
OkayPhysicist 3mo ago
Almost certainly. I can go out into the woods behind my house and get into the iron age in a few days (most of that time would be waiting for clay to dry and charcoal pits to cool). That cuts out ~300k years of anatomically modern human history. Whether or not it would be possible to bootstrap the industrial revolution without easily accessible coal and petroleum is a bigger question. We might lose electricity for a while. There's not a lot of utility for electricity in pre-industrial society. Like, given enough copper, I could make a wind turbine, but I can't casually make a useful lightbulb. Maybe a ceiling fan, but it would almost certainly be easier to run that off of mechanical power directly via a series of gears and belts. Electrochemistry would be a neat party trick, but I don't think my shoddily built wind turbine would generate enough juice to process aluminum. Firearms would probably continue to exist. I could make a musket, and its utility for hunting and defense would make it immediately worth it. Black powder's not terribly difficult to manufacture from base ingredients. Are we including domesticated crops as "man-made"? Because that would complicate matters. A lot of knowledge could be lost in the time it takes to rebreed the kinds of grains that allow for stable settlement. We wouldn't need to re-invent writing, since that's just knowledge, and that would give a pretty big leg up in not losing a bunch of knowledge every time someone dies. On the whole, if we keep selectively bred crops, I'd say we'd be bumped back to about the Middle Ages at the most. If we're losing the crops, then it would come down to whether we could preserve our more advanced knowledge long enough for agriculture to redevelop.

cpncrunch 3mo ago

I find this cute and amusing, having had to write buttons in assembly language in the 80s, drawing the buttons into video memory using blits.

sumtechguy 3mo ago
I did something similar in win16/32 at one point. Think we wanted something special with graphics on the button. We basically had to recreate all of the actions of focus/unfocus/etc. Everything a normal button could do. Now that I have done more stuff I a know for a fact I made my life way harder than it should have been and could have subclassed. But it was a full button recreation. Styling messaging and all. You have to watch for things like what if someone clicks outside of your button but lets go inside the button. What does that mean? All sorts of weird side effects. What if your button has focus and someone starts typing? What if someone clicks outside of your button but holds the button down as they slide across your button? What does that look like? Would I ever do it again. Probably not. Seriously use the built in ones.

chromadon 3mo ago

Nothing will ever come close to WinForms.

socalgal2 3mo ago

Interestingly the code on the page doesn't work. onmouseup and onpointerup are the wrong event for a button because the button should only send an "clicked" event if the user pressed DOWN on the button, then released while still on the button. The example code though will send an event even if the user started off the button. I think that emphasizes the point though. You need more code to do it correctly.