My very similar pet peeve is about websites that use `onclick` handlers and similar to implement navigation. Just use a damn anchor tag, which gets you correct link behavior for free:
* works with middle click for new tab
* integrates with accessibility devices
* works with right click + open in new window or similar options
* etc. etc. etc.
If it's notionally navigation, don't use javascript soup: use a link.
Zak 2 hours ago [-]
I've seen an increase in people doing this sort of thing over the past few years. I imagine it has something to do with frameworks and ignorance or apathy, but the old fashioned way almost always provides the best UX.
To anyone reading who has tried to get fancy with a substitute for the <a> tag, I wish you mild discomfort and inconvenience.
philistine 1 hours ago [-]
Could it be that the devs who write that code are not allowed to touch the CSS so they implement the visual functionality they want in their framework instead of telling the design team their intent?
Zak 1 hours ago [-]
There could be any number of weird constraints that would lead a developer who knows better to do such a thing in a specific situation, but someone designed (or failed to intentionally design) the system in question.
That person should sit alone in a room with no distractions and think about what they did.
epidemian 30 minutes ago [-]
oh, 100% yes! The job project i joined somewhat recently is a moderately-complex React web app, and none of the navigation elements are actual links. Everything is done by onClick handling, even thought many things are, conceptually, just links. I have no idea why this kind of thing is so widespread on the web front-end world.
weaksauce 2 hours ago [-]
when i was doing .net programming way back in the day asp.net handled each navigation with a javascript event and it broke all that stuff. this was right before ruby on rails existed so maybe it’s better now.
tln 1 hours ago [-]
Yes! If it's clickable, it should either be a button or a link.
culi 46 minutes ago [-]
there are plenty of other vanilla html elements that are clickable. <details>, <input type=[button|checkbox|radio|file|etc]>, <label>, <select>, etc
pverheggen 3 hours ago [-]
A good addition to this article is that most buttons should have type="button" on them. By default, buttons are type="submit", which if contained inside a form will submit that form.
I'm sure there are some devs who reach for a div because they're unaware of the proper way to disable submit behavior.
galaxyLogic 2 hours ago [-]
> they're unaware of the proper way to disable submit behavior.
That is an issue in favor of DIV, you don't accidentally set type="submit" because you don't know about that. There are many things many people don't know.
Using a DIV means you start from empty plate and explicitly add the features you want to add, which makes it easy to later remove or change those features when you want to.
Of course if your knowledge of HTML standards is great and Button exactly fits your current use-case you probably will use it, but designs and requirements change all the time.
Using DIV makes your design more transparent, you see there are certain features you have set to it by adding the attributes.
Using a Button means you (and other people reading your code) probably want to consult documentation to understand what it exactly does. With a DIV + attributes that is explicitly "spelled out".
Just some pros and cons.
MrJohz 2 hours ago [-]
You always want all the accessibility features. If your button is a button, then you want the whole lot: the correct role, tabability, keyboards shortcuts, everything. There is no situation where you only want some of those features.
So if you use a div, you _always_ need to add _all_ of the features. Whereas if you use a button, you usually need to remember to add the correct "type" attribute (although if you're building a form, you might not even need that).
You also mention transparency. A button makes your design transparent: it is a standard element, and web developers should know what it does. A div is not transparent - firstly, if I'm a developer reading that code, I need to look at context clues to understand what the authors' intent was (a tabbable element with a keydown handler and a click handler could be all sorts of elements, not just a button, so now I need to inspect event handlers and see what they do), and secondly, many people do not implement this stuff correctly, so what you're usually looking at is something that looks like it might have been intended as a button, but is missing a bunch of features. Was that intentional or did the author just forget some stuff?
This isn't really a "pros and cons" type of thing. Just use a button. It's doing all the work that you'd have to do manually, but automatically. Just use it.
thyristan 2 hours ago [-]
DIV isn't a button with features disabled. DIV is something else entirely, and you have to emulate most of the features in Javascript, badly. As the original article explains...
marcosdumay 2 hours ago [-]
Every input should have a type. It's a good thing to put in a linter and run before you consider your code complete.
Yes, the default is bad, but you should be overriding every one of those anyway.
Sohcahtoa82 2 hours ago [-]
> Using a DIV means you start from empty plate
When comparing to a Button, that's a bug, not a feature.
jmull 2 hours ago [-]
How is it harder to learn “want normal button” => <button type=“button”…> than “want normal button” => <div role=“button” tabindex=“0”…>, plus the javascript for keyboard access (plus css for at least the cursor), etc.?
culi 41 minutes ago [-]
Agreed. It's not hard and it's definitely not unreasonable to expect front-end developers to know the very basics of semantic HTML and accessibility standards. It's literally their jobs
cferdinandi 2 hours ago [-]
No. Objectively no.
It is INFINITELY easier to add type="button" than all of the other shit I mentioned in my article.
znort_ 2 hours ago [-]
> Of course if your knowledge of HTML standards is great and Button exactly fits your current use-case you probably will use it
i would have imagined that coding html should be done by people with basic understanding of it, at the bare minumum to know what a button is. but maybe that's just me being old and not going on with the vibes ... maybe i'm just going to facepalm a bit and get some fresh air.
sam_lowry_ 1 hours ago [-]
Indeed this long rant by OP misses the critical info.
A button of default type will do weird things, IIRC it will skip the JS handler onCick, for instance.
efilife 23 minutes ago [-]
I don't think it skips the handler behavior on default but can't check now
Shog9 15 minutes ago [-]
It does not. What it does do is submit the form, so if you trigger some fast change to the page or async behavior from the click event, you may never see it because the submission happens and the page reloads (or a different page loads if form action is set to a different URL). If you're relying on event bubbling, the click handler may run after the form is submitted, which is even less likely to do what you intend.
If you aren't expecting this (and don't know how to discover it e.g. by examining browser dev tools, server logs, etc.) then you'll assume the button is broken and... probably try something else.
Even if you do discover it, you may try something that won't quite have the same reliability - at one point it was common to see folks putting preventDefault() or return false in their click handlers to squelch the (correct) behavior, rather than changing the type of button.
mixmastamyk 2 hours ago [-]
Believe that default is for <input type="submit">, not <button>.
cferdinandi 1 hours ago [-]
It's the default for buttons inside forms, but it's SO trivial to add type="button" than any argument that div's are a better choice because of this should be dismissed as unserious trolling out-of-hand.
Maybe you’re thinking of <input type=“button”>, which doesn’t submit?
rado 3 hours ago [-]
Right. I learned it the hard way lol
donatj 2 hours ago [-]
I would love to see this expanded into "Just use the HTML element that was built for that explicit purpose". I feel like your average SPA developer doesn't understand what even a quarter of the HTML elements are meant for and just reinvent the wheel every time.
christophilus 39 minutes ago [-]
I wish the elements were just stylable, then. For example, the date picker sucks. I’d love to use it and eschew a JS based one, but my clients complain that it’s ugly.
culi 40 minutes ago [-]
Yes it's called "just use the platform" and it's become a common refrain in the front-end world at least since HTML5 came out around 2014. Unfortunately it hasn't caught on in all parts of web dev but it's definitely seen as the "correct" way to do things
HocusLocus 1 hours ago [-]
A whole generation of people who click all over to find places that do something. People have this problem where they feel 'proudly vested' in learning things that just weren't designed well.
10 years ago someone decided that dragging links is so much more important than selecting text, selecting text is scarcely possible. I'm going to have to fork a browser to give link-dragging the demotion it deserves. It was probably those DIV guys.
ajmurmann 7 minutes ago [-]
Almost as bad as copying a phone number on iOS instead of calling it (no idea if this is better on Android). The eagerness of iOS to call phone numbers which almost never is the thing I want to happen, is a source of much anxiety.
ForLoveOfCats 25 minutes ago [-]
I might be a weirdo but I drag links all the time as it's how I open links as background tabs even though there is a right-click context menu entry for it
Unless the site is _really_ messing with events, holding alt on PC (Windows/Linux/ect) or Option on macOS lets you select text in links without triggering the link to navigate.
culi 37 minutes ago [-]
This is a great point that I don't see brought up enough. I don't know if I've ever purposely wanted to drag a link but I struggle to highlight/select some in a link every other day
tarwich 3 hours ago [-]
100%
Use elements as close to their original intention as possible
steve_adams_86 1 hours ago [-]
This is a good example of cases where LLMs can tend to write 'bad' code, because these patterns (i.e. reinventing wheels in the browser) are quite common in the wild, and LLMs tend to choose them over just using native features (such as buttons). I find myself telling Claude to revisit implementations and simplify them in these kinds of ways.
Another good example is bizarre error handling conventions when working in TypeScript. Claude will come up with tons of weird ways of doing this, using different approaches all over the place, but rarely consider simple patterns like 'return an expected value or an error'.
turtletontine 58 minutes ago [-]
These are great examples of how LLMs are great at writing code, but pretty bad at software engineering
spkm 11 minutes ago [-]
Just don't use animated gifs inbetween text.
Brendinooo 2 hours ago [-]
Related, because I don't always get to talk about buttons:
In my day job's shared library, we made a Clickable component that basically exists to abstract away the decision to use a button or an anchor tag, and resets the styles so both elements act the same way (both by default and when we apply styles to each).
We'd have a lot of confusion on the design side about button-as-design vs button-as-function and now we don't have to deal with that at all anymore.
And since the styling's been reset in a predictable way, it takes away one of the bigger reasons why people go to divs in the first place.
Sharlin 2 hours ago [-]
How does style reset make the elements work the same way? Links have vastly more features built into browsers than buttons
giancarlostoro 4 hours ago [-]
Weird, I always use buttons when I can, unless what I need is not actually a button, but something that performs and on-click sort of like a button, like a hyperlink that navigates you through the web app.
ervine 3 hours ago [-]
I guess if it doesn't update the url, it's a button.
If it changes the url, it should be a link. At least that's how I've always done it.
cassepipe 3 hours ago [-]
Is is not okay to wrap a link inside a button ? I guess not
Which elements are allowed to wrap which is unclear to me
Shog9 6 minutes ago [-]
FWIW, you can generally figure out what's allowed fairly quickly by checking the content model for a given element[1]. Some browsers might be more or less restrictive, but for normal usage this'll be more than enough to avoid unexpected behavior.
What is the use case? It’s hard for me to think of a reason you’d want to wrap a link in a button.
If you want to navigate, use an anchor.
If you want to trigger JS logic, use a button with onclick handler.
If you want to navigate while doing some side effect like an API call, use an anchor with onclick handler (and don’t prevent default).
cferdinandi 1 hours ago [-]
Literally absolutely never ever do this.
Zak 2 hours ago [-]
> like a hyperlink that navigates you through the web app
You mean an <a> tag?
SmartHypercube 2 hours ago [-]
I got bitten by this: user agent stylesheet contains "button {align-items: flex-start}" (at least in Chrome). The default behavior is "stretch". Spent an hour debugging why my flexboxs' sizes are wrong. I still want to use correct HTML elements as much as possible, but I do think using <div>s everywhere makes my small side projects so much easier, since I don't have to remember all the non-default behaviors.
crisnoble 1 hours ago [-]
`appearance: none` goes a long way to resetting button styles. I usually make a .unbuttonify class to use or extend for things I want to behave like buttons (free focus, accessibility, and interactivity) but look like, say, a hamburger menu toggle.
culi 32 minutes ago [-]
are css resets not in vogue any more? I still use them for all my side projects. As well as a normalize.css[0] that smooths over any additional browser inconsistencies. The original Meyer reset is definitely overkill, but there are a couple newer more minimal ones out there[2][3]
I probably should have included "if you're building for the frontend you should probably know CSS". Good follow-up piece. Thanks for mentioning it!
flemhans 3 hours ago [-]
Why is the <div> option proposed by anyone in the first place?
wrs 3 hours ago [-]
Based on what I see in the world, I suspect one reason is that a <div> makes it easier to apply some bizarro appearance to the button, so it not only doesn’t act like a button, it doesn’t even look like a button.
mcny 1 hours ago [-]
This comes from either business or the UX people who want stuff to look pixel perfect to their stupid wireframe.
Why does a website that sells to a pretty much captive audience who cares more about functionality than looks obsess so much about every single button looking pixel perfect to some arbitrary wireframe, I will never know.
Joker_vD 3 hours ago [-]
Well, have you been on, I don't know, TV Tropes? They have those long lists, that are separated into "folders" on a single page. You can click on those "folders" to expand/collapse them, and it's implemented as a <div> with "onclick" property and <ul> inside it (well, used to IIRC; nowadays this <ul> is a child of a sibling <div>).
1-more 2 hours ago [-]
what's annoying about that example is that all of those <div>s could be buttons with no other changes. The only content inside the button <div> is the title and folder icon, not the list of examples associated with that title. That's just fine for a button!
The other thing I'd do is add `aria-controls=folder0` to the button that toggles visibility of the list with `id=folder0`
no_wizard 32 minutes ago [-]
I'll do you one better and argue they could `<details>` elements. This is a perfect use case for that.
cferdinandi 1 hours ago [-]
The most common reason I've seen is whining about having to override default button styles.
no_wizard 36 minutes ago [-]
I too have encountered this reasoning.
Then I write some basic CSS and show them they have nothing to fear.
Yet, I still remain irritated beyond belief that its such a common thing. In 2025. Hell, in 2017!
I don't know what to do about it, other than constantly remind people about things, but it gets tiring.
Though, its a great interview question. Its a quick way to understand if someone knows the fundamentals or not.
Kinda like how people got ".bind" wrong on functions for years.
bugsliker 4 hours ago [-]
- tabindex=0 doesn’t affect ordering, does it?
- why do you need to listen for events at the document level?
not that i disagree with the article, but some arguments didn’t seem right.
thyristan 3 hours ago [-]
> - tabindex=0 doesn’t affect ordering, does it?
Of course it does. tabindex=0 doesn't sort naturally into the automatic tabindex order, it sorts AFTER everything. So you are jumping through all the other tabindex elements, then you are jumping back to all tabindex=0.
bugsliker 2 hours ago [-]
I'm saying tabindex=0 is naturally sorted wrt other naturally focusable elements. That matches the behavior of the <button> you're trying to emulate. I don't know what tabindex>0 has to do with this.
(again, I do not condone building your own <button>, just pointing this out)
pverheggen 3 hours ago [-]
That's the same behavior as a <button> without tabindex, like the author is proposing.
It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.
thyristan 3 hours ago [-]
> That's the same behavior as a <button> without tabindex, like the author is proposing.
Yes, but often you have elements with taborder > 0.
> It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.
Only if document order is sane. Usually with modern websites it isn't, document order is a broken notion if you can position elements at will and e.g. put navigation at the bottom of a document but move it to the top by CSS. Which is actually a recommendation that some people make for acessibility...
What you usually want to do is assign a sensible taborder > 0 to the one form element that the user is probably currently using. Otherwise, he will pointlessly tab through search, menus, cookie bars and a ton of other pointless stuff first.
MrJohz 1 hours ago [-]
You almost certainly don't want to assign tab order manually. Theoretically, if your html is out-of-order for some reason, then you can fix it with taborder, but there are so many issues with out-of-order html that it's much better to avoid that in the first place. Even on modern websites, it is almost always easier to lay your html out in the correct order rather than messing around with the order via CSS. (I read an article recently by a web accessibility expert that discussed the issue of flexbox's order parameter and how the working group designing it failed to accessibility into account when adding it to the spec: https://alice.boxhall.au/articles/a-threat-model-for-accessi...)
You mention using it to skip a nav header or something similar, but (1) you have autofocus for that if you need it (and you don't usually need it), and (2) the pattern where you provide a "jump to content" button is typically a better approach, because it allows the user to decide what they want to do when they arrive on your site, rather than you deciding for them. If the "jump to content" button behind visible when focused and is the first element on the screen, then it works perfectly for screen readers and other keyboard users, and you don't need to handle taborder manually.
There are always exceptions to these sorts of rules, and some times tabindex might be necessary, but I've not yet come across a case where the problem couldn't be solved better in a different way.
pverheggen 2 hours ago [-]
> Yes, but often you have elements with taborder > 0.
You can just as easily apply the same tabindex to a div though.
> Only if document order is sane. Usually with modern websites it isn't...
Well that's the real problem, all your non-interactive content (like text) is going to be out of order too. You're just adding to the confusion if buttons and other inputs are in a different order from the content they're associated with.
> Otherwise, he will pointlessly tab through search, menus, cookie bars and a ton of other pointless stuff first.
The proper way of dealing with this is a "Skip to Main Content" element:
No, it isn't the proper way. That only works if you can see the skip link and know to press enter. Otherwise you will tab straight into the navigation. So possibly useful for screen readers, but completely useless for most keyboard users. Yet another stupid webdev workaround for a selfimposed problem.
What you should do is autofocus the first form element (if there is a form), give it tabindex=1 and number the other form elements in a sensible ascending tabindex order. Otherwise, proper semantic markup is sufficient, even for screen readers.
pverheggen 1 hours ago [-]
Usually you would have it appear when it's focused, like this for example:
Your solution of focusing the first form element is pretty idiosyncratic. It's better to follow WAI patterns, because patterns have predictable behavior. Otherwise, keyboard users will have to learn how to interact with your website from scratch, instead of just following the same pattern they're used to from other sites.
thyristan 1 hours ago [-]
Any website implementing a form for data entry is expected by any sane user to autofocus the first form element.
pverheggen 24 minutes ago [-]
Sorry, missed the part about "form for data entry". If that's the main point of the given page, then sure, focus on the first input is fine.
Your original comment was to use tabindex to skip search, menu bars, breadcrumbs, etc. and for that there are better options.
That is correct. From your link: "tabindex="0" means that the element should be focusable in sequential keyboard navigation, after any positive tabindex values. The focus navigation order of these elements is defined by their order in the document source.
"
Ma8ee 3 hours ago [-]
Your link actually supports the comment you replied to.
cferdinandi 3 hours ago [-]
Hey, it's me, the original author!
The issue isn't with tabindex=0 specifically, but fucking with tabindex in general. People go down that path, and start putting that shit on everything, like it's Frank's Red Hot.
And in my experience, the same folks who use div's instead of button's are the ones who don't know better and start throwing tabindex around.
"why do you need to listen for events at the document level?"
Not events generally, keydown events specifically, which do not fire on child elements of the document.
kyle-rb 6 minutes ago [-]
Hi, good premise overall, but there are just a lot of little things that are off.
- It only counts as "fucking with tabindex" if you give it a value that's not 0 or -1. You should give that specific disclaimer, because there are uses for tabindex=0 other than reimplementing <button>.
- Divs can definitely receive keydown events. If I go to an arbitrary web page, pick a div and run `div.tabIndex = 0;` + `div.addEventListener('keydown', console.log);`, I see those events coming through when I have the div keyboard-focused.
- "Run your code, somehow..." I think just calling `notRealBtn.click()` is the best option.
- Stupid but semi-interesting nitpick: 'keydown' is good for enter, but you should be listening to 'keyup' for the space bar. That's how real <button>s work anyway.
- The 'keyup' listener should call event.preventDefault() to prevent the default behavior of the space bar scrolling the page.
pverheggen 3 hours ago [-]
Not sure about that, MDN's example shows keydown being attached to an element.
> Not events generally, keydown events specifically, which do not fire on child elements of the document.
Are you sure? I have a 17 year old HTML tool written using plain, vanilla JavaScript where keydown on a child element seems to have been working as expected.
I think that’s because it’s an input and not a div, so it can get focus. Im not sure whether tabindex is enough to make a div do that too, article suggests no
1 hours ago [-]
stack_framer 2 hours ago [-]
I wonder if the "React Ry–thought-leader-guy" crowd (I love this not-so-subtle reference to Ryan Florence) preferred div over button because of the built-in styles that browsers used to apply to button elements.
1-more 2 hours ago [-]
This I've never gotten. It takes very little CSS to unstyle them!!
exogen 2 hours ago [-]
In today's world, yes. But as with a LOT of complaints about "web developers!!!!" the answer is usually "because of the way the web WAS."
Before IE became Edge (and maybe even in the earliest versions of Edge), there were certain styles and descendants that simply did not work on a <button> element, like Flexbox and Grid positioning. So, if your button had content like an icon, and you were trying to align it a certain way with the label, you simply couldn't use some features of CSS like you could with a <div>. It was a pain in the ass.
In the same vein, do you remember the period where some browsers wouldn't allow you to make a button look like a link using CSS, because they thought it might deceive people and thus be a security issue? I do.
And similarly when people complain about the complexities of webpack and bundlers in general, do you remember including the jQuery <script> tag on the page and then almost always needing to call `jQuery.noConflict()`? And how in those days, most people got even THAT wrong, because atomic <script async onload> behavior didn't work correctly in all browsers yet, so other code could actually run in between a <script> and its onload callback, meaning the jQuery.noConflict call was ineffective and something else could steal it? I remember. webpack fixed that by automatically scoping everything.
Nowadays, a lot of those workarounds are unnecessary (depends what browsers you're supporting). But it's not like there was never a reason for them.
cferdinandi 1 hours ago [-]
That was a big part of "thought leader guy"'s argument in favor of divs, but not the only one.
shreddit 59 minutes ago [-]
> You shouldn’t, though! Seriously, just don’t fuck with focus order.
And here i am, wishing some would do just this. Especially creators of log in forms which make the “reveal password” button the next focus point instead of the “submit” button
culi 28 minutes ago [-]
is pressing tab twice instead of a single time really that big of an issue? Messing with focus order is definitely a bad idea, but they could also use less semantic html to skip the reveal password "button". For people who can only use keyboards, this would make it impossible to access that feature however
jarek83 2 hours ago [-]
The type of developers that would go with <div> in such cases are also those that know very, extremely little about semantic HTML and its purpose.
Then if one is challenged about using React or other heavy-JS framework when you don't really have to, the discussion will be met with utter even surprise that someone out there is actually not using React.
The web is darn simple, but we are the place where it is made extremely over engineered and expensive for both companies (salaries and 2-3x more staff needed than necessary because of the bloat) and users of their products (in terms of payloads).
And yet JS-heavy frameworks seems to have the best job market.
Everything seems to be upside down.
xnx 2 hours ago [-]
Page makes no mention of <input type="button">. Are there any situations where that should be used?
adam_beck 2 hours ago [-]
From MDN:
> Note: While <input> elements of type button are still perfectly valid HTML, the newer <button> element is now the favored way to create buttons. Given that a <button>'s label text is inserted between the opening and closing tags, you can include HTML in the label, even images.
jarek83 2 hours ago [-]
It's a thing from the times when <button> did not exist. Other use cases were for supporting IE.
Today just use button.
cferdinandi 1 hours ago [-]
I would literally never use <input type="submit|button"> for anything when the <button> element is an option, personally.
randyrand 3 hours ago [-]
> This element does not announce itself as an interactive element to screen reader users
Are you sure? Screen readers should be able to detect a div with a onclick as interactable, no? And if they can’t, that seems like an exceedingly simple fix. I’d be shocked if they can’t already detect onclick.
rictic 3 hours ago [-]
A click handler can be doing a lot of things that aren't much like a button, like letting you close a modal if you click outside of it, capturing mouse events for a game, or passively recording events for analytics. All that a click handler tells you is that there's some code that sometimes cares about some clicks somewhere inside that element.
knute 2 hours ago [-]
Also a click handler on a div isn't going to do much for someone who isn't using a mouse, which would include a lot of screen reader users.
randyrand 1 hours ago [-]
All of those seem like examples of things you’d want your screen reader to tell you about.
1-more 2 hours ago [-]
I can confirm. I got decent with VoiceOver as the "guy on the team who gives a shit about this" (unofficial title) and yeah, it stinks. Also, you don't necessarily move through the page linearly with a screen reader; the rotor lets you jump between links, or jump to forms, or jump to navs. The more semantic your markup, the better it will be populated.
cferdinandi 1 hours ago [-]
It's worth noting that VoiceOver is well-known for being a lot more lax than most other screen readers. Other options tend to be a lot more strict around standards and what they'll announce.
Sohcahtoa82 1 hours ago [-]
tbh, I've started to grow a disdain for front-end developers. It seems their favorite pastime is re-inventing the wheel, and every single time, they destroy something while gaining absolutely nothing.
Stop implementing date pickers when <input type="date"> exists.
Stop implementing smooth scrolling. Browsers already do it on their own, and your implementation will not work. Really, just don't mess with scrolling in general. Don't make scrolling have "momentum". Don't change scroll speed. One site I've been to goes out of its way to change how much a scroll wheel click scrolls the page. For fuck's sake, can someone explain to me why that would be a feature!? Why go out of your way to override a specific user preference!?
All this bullshit changes expected behaviors, reduces accessibility, reduces the performance of your web page (and therefore increases CPU and battery usage)...for no reason whatsoever.
al_borland 56 minutes ago [-]
> Stop implementing date pickers when <input type="date"> exists.
This still has issues in some browsers. With sites already having other methods from before this existed, there isn’t a good reason to move to it, when they’ll need the custom version for browsers that lack full support.
For the love of god why can't people just use standard elements for their intended purpose.
Here's a tip for weirdo front-end devs that do this: You are not smarter than the people that created the spec.
culi 26 minutes ago [-]
it's not about being smarter. It's about being lazy. They don't wanna reset the default button css in order to perfectly match the figma they're being contracted to draw up. They simply don't care and the people contracting them don't have the knowledge to check if shortcuts were taken
827a 3 hours ago [-]
> This element does not announce itself as an interactive element to screen reader users.
Is this actually true nowadays? Given that advice like this is often parrotted by people who don't actually use screen-reading software, I sometimes wonder if this is a situation where we've just been saying this and repeating this advice; meanwhile, screen readers have obviously become sophisticated enough to recognize that a div with an onclick handler on it is probably, you know, clickable and interactive.
pverheggen 3 hours ago [-]
There are well-defined standards for how the role of every element is determined, and according to those standards, adding an onclick handler does not change the role.
Screen readers also don't access the DOM directly, there's an extra abstraction layer. Browsers expose accessibility data to the appropriate OS API, and screen readers use the data exposed by the OS. There's too much variation as-is between different screen readers to be piling browser-specific behavior on top.
SoftTalker 3 hours ago [-]
Screen reading software seems like it would have a very small market and I would expect it lags rather than keeps up with the ever changing ways people invent to build web pages.
mnhnthrow34 3 hours ago [-]
Have you tested this? Often click handlers are on some non-interactive ancestor element, it is not a good heuristic for something being interactive itself or what name it should have. Sometimes the listener is on the body element and we just parse out the triggering element and do something.
827a 39 minutes ago [-]
No I haven't tested it, that's what I'm asking.
This piece of advice, to me, just feels like a piece of advice constantly repeated by a bunch of people, none of whom actually use the software for which the piece of advice is meant to benefit. That scares me; like we've all lost touch with the ground truth on this one; I'd love to re-sync with it, that's what I'm trying to do, I just don't have the first clue how to do it.
isleyaardvark 3 hours ago [-]
Screen readers have and continue to lag in implementing standards designed specifically for accessibility, so I would say they are obviously not sophisticated enough.
> 1. This element does not announce itself as an interactive element to screen reader users.
It has the "onclick" property set though. The other two points are pretty valid, however. It's a shame we don't have a proper "onsubmit" property or something like that. "Oninteract"?
Rendered at 21:13:06 GMT+0000 (Coordinated Universal Time) with Vercel.
* works with middle click for new tab
* integrates with accessibility devices
* works with right click + open in new window or similar options
* etc. etc. etc.
If it's notionally navigation, don't use javascript soup: use a link.
To anyone reading who has tried to get fancy with a substitute for the <a> tag, I wish you mild discomfort and inconvenience.
That person should sit alone in a room with no distractions and think about what they did.
I'm sure there are some devs who reach for a div because they're unaware of the proper way to disable submit behavior.
That is an issue in favor of DIV, you don't accidentally set type="submit" because you don't know about that. There are many things many people don't know.
Using a DIV means you start from empty plate and explicitly add the features you want to add, which makes it easy to later remove or change those features when you want to.
Of course if your knowledge of HTML standards is great and Button exactly fits your current use-case you probably will use it, but designs and requirements change all the time.
Using DIV makes your design more transparent, you see there are certain features you have set to it by adding the attributes.
Using a Button means you (and other people reading your code) probably want to consult documentation to understand what it exactly does. With a DIV + attributes that is explicitly "spelled out".
Just some pros and cons.
So if you use a div, you _always_ need to add _all_ of the features. Whereas if you use a button, you usually need to remember to add the correct "type" attribute (although if you're building a form, you might not even need that).
You also mention transparency. A button makes your design transparent: it is a standard element, and web developers should know what it does. A div is not transparent - firstly, if I'm a developer reading that code, I need to look at context clues to understand what the authors' intent was (a tabbable element with a keydown handler and a click handler could be all sorts of elements, not just a button, so now I need to inspect event handlers and see what they do), and secondly, many people do not implement this stuff correctly, so what you're usually looking at is something that looks like it might have been intended as a button, but is missing a bunch of features. Was that intentional or did the author just forget some stuff?
This isn't really a "pros and cons" type of thing. Just use a button. It's doing all the work that you'd have to do manually, but automatically. Just use it.
Yes, the default is bad, but you should be overriding every one of those anyway.
When comparing to a Button, that's a bug, not a feature.
It is INFINITELY easier to add type="button" than all of the other shit I mentioned in my article.
i would have imagined that coding html should be done by people with basic understanding of it, at the bare minumum to know what a button is. but maybe that's just me being old and not going on with the vibes ... maybe i'm just going to facepalm a bit and get some fresh air.
A button of default type will do weird things, IIRC it will skip the JS handler onCick, for instance.
If you aren't expecting this (and don't know how to discover it e.g. by examining browser dev tools, server logs, etc.) then you'll assume the button is broken and... probably try something else.
Even if you do discover it, you may try something that won't quite have the same reliability - at one point it was common to see folks putting preventDefault() or return false in their click handlers to squelch the (correct) behavior, rather than changing the type of button.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Maybe you’re thinking of <input type=“button”>, which doesn’t submit?
10 years ago someone decided that dragging links is so much more important than selecting text, selecting text is scarcely possible. I'm going to have to fork a browser to give link-dragging the demotion it deserves. It was probably those DIV guys.
Unless the site is _really_ messing with events, holding alt on PC (Windows/Linux/ect) or Option on macOS lets you select text in links without triggering the link to navigate.
Use elements as close to their original intention as possible
Another good example is bizarre error handling conventions when working in TypeScript. Claude will come up with tons of weird ways of doing this, using different approaches all over the place, but rarely consider simple patterns like 'return an expected value or an error'.
In my day job's shared library, we made a Clickable component that basically exists to abstract away the decision to use a button or an anchor tag, and resets the styles so both elements act the same way (both by default and when we apply styles to each).
We'd have a lot of confusion on the design side about button-as-design vs button-as-function and now we don't have to deal with that at all anymore.
And since the styling's been reset in a predictable way, it takes away one of the bigger reasons why people go to divs in the first place.
If it changes the url, it should be a link. At least that's how I've always done it.
Which elements are allowed to wrap which is unclear to me
[1]: https://html.spec.whatwg.org/#the-button-element:concept-ele...
You mean an <a> tag?
[0] https://necolas.github.io/normalize.css/
[1] https://meyerweb.com/eric/tools/css/reset/
[2] https://www.joshwcomeau.com/css/custom-css-reset/
[3] https://piccalil.li/blog/a-more-modern-css-reset/
Why does a website that sells to a pretty much captive audience who cares more about functionality than looks obsess so much about every single button looking pixel perfect to some arbitrary wireframe, I will never know.
The other thing I'd do is add `aria-controls=folder0` to the button that toggles visibility of the list with `id=folder0`
Then I write some basic CSS and show them they have nothing to fear.
Yet, I still remain irritated beyond belief that its such a common thing. In 2025. Hell, in 2017!
I don't know what to do about it, other than constantly remind people about things, but it gets tiring.
Though, its a great interview question. Its a quick way to understand if someone knows the fundamentals or not.
Kinda like how people got ".bind" wrong on functions for years.
- why do you need to listen for events at the document level?
not that i disagree with the article, but some arguments didn’t seem right.
Of course it does. tabindex=0 doesn't sort naturally into the automatic tabindex order, it sorts AFTER everything. So you are jumping through all the other tabindex elements, then you are jumping back to all tabindex=0.
See this fiddle https://jsfiddle.net/483uqjnp/
(again, I do not condone building your own <button>, just pointing this out)
It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.
Yes, but often you have elements with taborder > 0.
> It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.
Only if document order is sane. Usually with modern websites it isn't, document order is a broken notion if you can position elements at will and e.g. put navigation at the bottom of a document but move it to the top by CSS. Which is actually a recommendation that some people make for acessibility...
What you usually want to do is assign a sensible taborder > 0 to the one form element that the user is probably currently using. Otherwise, he will pointlessly tab through search, menus, cookie bars and a ton of other pointless stuff first.
You mention using it to skip a nav header or something similar, but (1) you have autofocus for that if you need it (and you don't usually need it), and (2) the pattern where you provide a "jump to content" button is typically a better approach, because it allows the user to decide what they want to do when they arrive on your site, rather than you deciding for them. If the "jump to content" button behind visible when focused and is the first element on the screen, then it works perfectly for screen readers and other keyboard users, and you don't need to handle taborder manually.
There are always exceptions to these sorts of rules, and some times tabindex might be necessary, but I've not yet come across a case where the problem couldn't be solved better in a different way.
You can just as easily apply the same tabindex to a div though.
> Only if document order is sane. Usually with modern websites it isn't...
Well that's the real problem, all your non-interactive content (like text) is going to be out of order too. You're just adding to the confusion if buttons and other inputs are in a different order from the content they're associated with.
> Otherwise, he will pointlessly tab through search, menus, cookie bars and a ton of other pointless stuff first.
The proper way of dealing with this is a "Skip to Main Content" element:
https://webaim.org/techniques/skipnav/
No, it isn't the proper way. That only works if you can see the skip link and know to press enter. Otherwise you will tab straight into the navigation. So possibly useful for screen readers, but completely useless for most keyboard users. Yet another stupid webdev workaround for a selfimposed problem.
What you should do is autofocus the first form element (if there is a form), give it tabindex=1 and number the other form elements in a sensible ascending tabindex order. Otherwise, proper semantic markup is sufficient, even for screen readers.
https://www.nytimes.com/
And yes, this is an acceptable solution according to the W3C:
https://www.w3.org/WAI/WCAG21/Techniques/general/G1
Your solution of focusing the first form element is pretty idiosyncratic. It's better to follow WAI patterns, because patterns have predictable behavior. Otherwise, keyboard users will have to learn how to interact with your website from scratch, instead of just following the same pattern they're used to from other sites.
Your original comment was to use tabindex to skip search, menu bars, breadcrumbs, etc. and for that there are better options.
The issue isn't with tabindex=0 specifically, but fucking with tabindex in general. People go down that path, and start putting that shit on everything, like it's Frank's Red Hot.
And in my experience, the same folks who use div's instead of button's are the ones who don't know better and start throwing tabindex around.
"why do you need to listen for events at the document level?"
Not events generally, keydown events specifically, which do not fire on child elements of the document.
- It only counts as "fucking with tabindex" if you give it a value that's not 0 or -1. You should give that specific disclaimer, because there are uses for tabindex=0 other than reimplementing <button>.
- Divs can definitely receive keydown events. If I go to an arbitrary web page, pick a div and run `div.tabIndex = 0;` + `div.addEventListener('keydown', console.log);`, I see those events coming through when I have the div keyboard-focused.
- "Run your code, somehow..." I think just calling `notRealBtn.click()` is the best option.
- Stupid but semi-interesting nitpick: 'keydown' is good for enter, but you should be listening to 'keyup' for the space bar. That's how real <button>s work anyway.
- The 'keyup' listener should call event.preventDefault() to prevent the default behavior of the space bar scrolling the page.
https://developer.mozilla.org/en-US/docs/Web/API/Element/key...
Are you sure? I have a 17 year old HTML tool written using plain, vanilla JavaScript where keydown on a child element seems to have been working as expected.
https://susam.net/quickqwerty.html
https://github.com/susam/quickqwerty/blob/1.2.0/quickqwerty....
Nice article, by the way!
Before IE became Edge (and maybe even in the earliest versions of Edge), there were certain styles and descendants that simply did not work on a <button> element, like Flexbox and Grid positioning. So, if your button had content like an icon, and you were trying to align it a certain way with the label, you simply couldn't use some features of CSS like you could with a <div>. It was a pain in the ass.
In the same vein, do you remember the period where some browsers wouldn't allow you to make a button look like a link using CSS, because they thought it might deceive people and thus be a security issue? I do.
And similarly when people complain about the complexities of webpack and bundlers in general, do you remember including the jQuery <script> tag on the page and then almost always needing to call `jQuery.noConflict()`? And how in those days, most people got even THAT wrong, because atomic <script async onload> behavior didn't work correctly in all browsers yet, so other code could actually run in between a <script> and its onload callback, meaning the jQuery.noConflict call was ineffective and something else could steal it? I remember. webpack fixed that by automatically scoping everything.
Nowadays, a lot of those workarounds are unnecessary (depends what browsers you're supporting). But it's not like there was never a reason for them.
And here i am, wishing some would do just this. Especially creators of log in forms which make the “reveal password” button the next focus point instead of the “submit” button
The web is darn simple, but we are the place where it is made extremely over engineered and expensive for both companies (salaries and 2-3x more staff needed than necessary because of the bloat) and users of their products (in terms of payloads).
And yet JS-heavy frameworks seems to have the best job market.
Everything seems to be upside down.
> Note: While <input> elements of type button are still perfectly valid HTML, the newer <button> element is now the favored way to create buttons. Given that a <button>'s label text is inserted between the opening and closing tags, you can include HTML in the label, even images.
Are you sure? Screen readers should be able to detect a div with a onclick as interactable, no? And if they can’t, that seems like an exceedingly simple fix. I’d be shocked if they can’t already detect onclick.
Stop implementing date pickers when <input type="date"> exists.
Stop implementing smooth scrolling. Browsers already do it on their own, and your implementation will not work. Really, just don't mess with scrolling in general. Don't make scrolling have "momentum". Don't change scroll speed. One site I've been to goes out of its way to change how much a scroll wheel click scrolls the page. For fuck's sake, can someone explain to me why that would be a feature!? Why go out of your way to override a specific user preference!?
All this bullshit changes expected behaviors, reduces accessibility, reduces the performance of your web page (and therefore increases CPU and battery usage)...for no reason whatsoever.
This still has issues in some browsers. With sites already having other methods from before this existed, there isn’t a good reason to move to it, when they’ll need the custom version for browsers that lack full support.
This is the issue with a lot of newer features.
Here's a tip for weirdo front-end devs that do this: You are not smarter than the people that created the spec.
Is this actually true nowadays? Given that advice like this is often parrotted by people who don't actually use screen-reading software, I sometimes wonder if this is a situation where we've just been saying this and repeating this advice; meanwhile, screen readers have obviously become sophisticated enough to recognize that a div with an onclick handler on it is probably, you know, clickable and interactive.
Screen readers also don't access the DOM directly, there's an extra abstraction layer. Browsers expose accessibility data to the appropriate OS API, and screen readers use the data exposed by the OS. There's too much variation as-is between different screen readers to be piling browser-specific behavior on top.
This piece of advice, to me, just feels like a piece of advice constantly repeated by a bunch of people, none of whom actually use the software for which the piece of advice is meant to benefit. That scares me; like we've all lost touch with the ground truth on this one; I'd love to re-sync with it, that's what I'm trying to do, I just don't have the first clue how to do it.
(One example: https://heydonworks.com/article/aria-controls-is-poop)
It has the "onclick" property set though. The other two points are pretty valid, however. It's a shame we don't have a proper "onsubmit" property or something like that. "Oninteract"?