9 ms·

Just use a button

• bugsliker 11mo 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 11mo 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.
    • brandonhorst 11mo ago
      This is incorrect. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/tabindex https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
      • thyristan 11mo ago
        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 11mo ago
        Your link actually supports the comment you replied to.
    • pverheggen 11mo 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 11mo 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.
        • pverheggen 11mo 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: https://webaim.org/techniques/skipnav/ https://webaim.org/techniques/skipnav/
          • thyristan 11mo ago
            > The proper way of dealing with this is a "Skip to Main Content" element: > > https://webaim.org/techniques/skipnav/ 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.
    • bugsliker 11mo 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. See this fiddle https://jsfiddle.net/483uqjnp/ https://jsfiddle.net/483uqjnp/ (again, I do not condone building your own <button>, just pointing this out)
    • minitech 11mo ago
      tabindex=0 does sort naturally into the automatic tabindex order. > So you are jumping through all the other tabindex elements This part is correct (for elements with an explicit positive tabindex), which is why specifying an explicit positive tabindex is considered a code smell. If you don’t specify a tabindex on an element that’s focusable by default, it behaves like tabindex=0. Try it: data:text/html,<button>foo</button><i tabindex=0>bar</i><button>baz</button>
  • cferdinandi 11mo 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.
    • pverheggen 11mo ago
      Not sure about that, MDN's example shows keydown being attached to an element. https://developer.mozilla.org/en-US/docs/Web/API/Element/keydown_event#addeventlistener_keydown_example https://developer.mozilla.org/en-US/docs/Web/API/Element/key...
    • susam 11mo ago
      > 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. https://susam.net/quickqwerty.html https://susam.net/quickqwerty.html https://github.com/susam/quickqwerty/blob/1.2.0/quickqwerty.html#L299 https://github.com/susam/quickqwerty/blob/1.2.0/quickqwerty.... Nice article, by the way!
      • skrebbel 11mo ago
        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
    • kyle-rb 11mo 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.
• giancarlostoro 11mo 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 11mo 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 11mo 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
      • stevula 11mo ago
        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 11mo ago
        Literally absolutely never ever do this.
      • Shog9 11mo 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. [1]: https://html.spec.whatwg.org/#the-button-element:concept-element-content-model https://html.spec.whatwg.org/#the-button-element:concept-ele...
      • phatskat 11mo ago
• tarwich 11mo ago
  100% Use elements as close to their original intention as possible
• flemhans 11mo ago
  Why is the <div> option proposed by anyone in the first place?
  • wrs 11mo 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 11mo 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.
      • yakshaving_jgt 11mo ago
        Things looking intentionally designed in great detail is also a function, despite programmer protests.
  • Joker_vD 11mo 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 11mo 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`
• 827a 11mo 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.
  • mnhnthrow34 11mo 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 11mo 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.
      • phatskat 11mo ago
        You can start with turning on eg switch controls on your OS, or the built in OS screen reader. Also, a lot of professional accessibility devices by makers like Dynavox are expensive, so your best bet is seeing what documentation you can dig up. This like WCAG guide accessibility standards, and coding to be in line with those is probably your best bet at achieving the goals of your website being accessible by assistive technology. Everyone can guess what screen readers can do, everyone can also get a _basic_ idea of how they’ll actually work, but more often than not the people who will have the most experience are those with the least ability to affect change. Using elements for their intended purposes and coding to accessible standards is probably the most impactful way any of us as engineers can help ensure a smooth experience for the target audience.
• Joker_vD 11mo ago
  > 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"?
• pverheggen 11mo 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.
  • mixmastamyk 11mo ago
    Believe that default is for <input type="submit">, not <button>.
    • pverheggen 11mo ago
      Nope, it's the default: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#type https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Maybe you’re thinking of <input type=“button”>, which doesn’t submit?
    • cferdinandi 11mo 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.
    • tomkarho 11mo ago
      I seem to recall that once upon a time the default type for a button was in fact "button" but at some point (somewhere in the region of html 5 / es6) it was switched into "submit".
      • pwdisswordfishy 11mo ago
        The nice thing about actually versioning standards (instead of doing that lazy "living standard" shit) is that you can actually look such things up. https://www.w3.org/TR/html4/interact/forms.html#adef-type-BUTTON https://www.w3.org/TR/html4/interact/forms.html#adef-type-BU...
  • 11mo ago
• lyricaljoke 11mo ago
  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.
  • Akronymus 11mo ago
    Also, get rid of JS based scrolling. I scroll a lot with pressing the middle mouse button. Too many sites break that.
    • Findecanor 11mo ago
      Sites that bind the arrow keys so I can't use them to scroll with.
  • Zak 11mo 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 11mo 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 11mo 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.
• croisillon 11mo ago
  <3 the top-border
• randyrand 11mo 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 11mo 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 11mo 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 11mo ago
      All of those seem like examples of things you’d want your screen reader to tell you about.
      • zahlman 11mo ago
        Sure. What is the screen reader's plan for determining the purpose of the attached JavaScript?
        • randyrand 11mo ago
          Same as a button. Read the text in the element. If no text, skip it or say "clickable". I'm not arguing a div is better. I'm just saying screen readers could announce a div with an onclick if they wanted to.
  • 1-more 11mo ago
• stack_framer 11mo 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 11mo ago
    This I've never gotten. It takes very little CSS to unstyle them!!
    • exogen 11mo 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.
      • 1-more 11mo ago
        A cool thing about a lot of the agency work I did early in my career is our audience was not actually the stated audience, it was the staff at the company that hired us. And one of the companies was on IE7. So yeah, I've nine-sliced a gif or two and done a few clearfixes in my time, haha. Never ran into a lot of these, but these weren't apps so much as brochures that happened to be online. Luckily enough we could control the environment pretty well to avoid actually needing noConflict() on jQuery. But that was in 2011–'13 and things have gotten a bit easier since then and it's up to us to stay abreast of what's possible on the platform.
• donatj 11mo 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.
  • culi 11mo 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
    • serial_dev 11mo ago
      I heard it almost a decade ago in Polymer and Web components circles https://www.polymer-project.org/blog/2016-05-26-IO-2016-Recap https://www.polymer-project.org/blog/2016-05-26-IO-2016-Reca... It’s strange to look back and see that most spa projects still just bundle it all up into a gigantic js file…
  • christophilus 11mo 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.
    • kgwxd 11mo ago
      When IE died I thought for sure the path was clear for highly styleable form elements and tables with all the features that countless third-party libraries have re-implemented for every new UI framework that comes out. Now I don't think we're going to get there before I die.
  • jay_kyburz 11mo ago
    I vaguely remember, back in 2010, when I wrote my app, you couldn't style a button consistently across all browsers. They were grey boxes in firebox, or used other OS standard styling. We had to invent our own buttons if we wanted it to look the same everywhere. I could be wrong though.
• SmartHypercube 11mo 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.
  • cferdinandi 11mo ago
    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!
  • crisnoble 11mo 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 11mo 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] [0] https://necolas.github.io/normalize.css/ https://necolas.github.io/normalize.css/ [1] https://meyerweb.com/eric/tools/css/reset/ https://meyerweb.com/eric/tools/css/reset/ [2] https://www.joshwcomeau.com/css/custom-css-reset/ https://www.joshwcomeau.com/css/custom-css-reset/ [3] https://piccalil.li/blog/a-more-modern-css-reset/ https://piccalil.li/blog/a-more-modern-css-reset/
      • isleyaardvark 11mo ago
        Less so now that the `all: unset` property is getting better support. https://developer.mozilla.org/en-US/docs/Web/CSS/unset https://developer.mozilla.org/en-US/docs/Web/CSS/unset
• xnx 11mo ago
  Page makes no mention of <input type="button">. Are there any situations where that should be used?
  • adam_beck 11mo 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 11mo 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 11mo ago
    I would literally never use <input type="submit|button"> for anything when the <button> element is an option, personally.
• Brendinooo 11mo 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 11mo ago
    How does style reset make the elements work the same way? Links have vastly more features built into browsers than buttons
    • Brendinooo 11mo ago
      Makes them work the same way visually.
• jarek83 11mo 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.
• steve_adams_86 11mo 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 11mo ago
    These are great examples of how LLMs are great at writing code, but pretty bad at software engineering
    • serial_dev 11mo ago
      Search engines were also only good at looking up things, not software engineering. I find it a blessing that a human is still valuable in this process we call software engineering. And meanwhile you can use search engines just like LLMs to learn and discover much faster than without them.
      • boothby 11mo ago
        Only nowadays LLMs are embedded in search engines so if you're looking for something that doesn't exist the top of the page is liable to hallucinate its existence.
    • Anamon 11mo ago
      I'm not sure I agree. This is coding for me, the engineering happened long before you knew you'd have to put a button-like thing there. To me, it's a great example how LLMs are just as shit at coding as everything else. It's just that the majority of people using them to code don't look at how terrible it is as long as it runs.
  • zahlman 11mo ago
• deleted 11mo ago
  [deleted]
• Sohcahtoa82 11mo 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 11mo 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. This is the issue with a lot of newer features.
    • Sohcahtoa82 11mo ago
      > This still has issues in some browsers. Your knowledge is out of date. <input type="date"> been implemented in nearly every browser since 2018, with the exception of Safari which was slow and didn't put it in until 2021, and Opera Mini which still doesn't have it at all, but who the hell uses Opera Mini? https://caniuse.com/input-datetime https://caniuse.com/input-datetime
      • al_borland 11mo ago
        Safari and Firefox still show partial support. The features that are lacking may or may not be relevant for a particular use case. I also can’t count on all my users to have the latest version of the browser, and don’t enjoy people messaging me telling my stuff doesn’t work.
• HocusLocus 11mo 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.
  • culi 11mo 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
  • ForLoveOfCats 11mo 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.
    • Telaneo 11mo ago
      [Middle mouse button] or [left mouse button + ctrl] also does this.
    • ivanche 11mo ago
      Holy fsck! 30 years on the web and today I learn about this Alt/Option trick. Thank you!
      • buzzy_hacker 11mo ago
        Same here, that literally just changed my life
    • MangoToupe 11mo ago
      How about on mobile? This is a constant headache.
• shreddit 11mo 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 11mo 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
    • kgwxd 11mo ago
      Having to think about it, at all, is the annoying part. Thinking == Anxiety.
    • zahlman 11mo ago
      >is pressing tab twice instead of a single time really that big of an issue? When you expect to press once, and end up doing the wrong thing because of that incorrect assumption, absolutely yes.
• throwaway106382 11mo ago
  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 11mo 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
    • throwaway106382 11mo ago
      Yeah I don't want to work with lazy people either. Shame.
• IT4MD 11mo ago
  [dead]
• spkm 11mo ago
  Just don't use animated gifs inbetween text.
• fullstackchris 11mo ago
  div onclick is an abomination that should be eliminated
• notatoad 11mo ago
  did everybody else get to the end of this article, and right-click inspect newsletter sign-up button to confirm that it was actually a <button>?
• andybak 11mo ago
  Weird side eye at htmx there?
  • mexicocitinluez 11mo ago
    And React. Using divs for buttons has absolutely nothing to do with whether you're using HTMX, React, or just plain Javascript. Maybe they're a younger developer and weren't around pre-React, but the idea that using a div instead of a button for a clickable element is somehow new or only pertinent if you're using a framework makes me think the author is confused about these things work.
• jeremy8883 11mo ago
  Yes, use the button element for buttons, and a for links. But this is not a new problem or one "among the react crowd". Anecdotally I'd say it was more prevalent 10 or 15 years ago.
  • mexicocitinluez 11mo ago
    > But this is not a new problem or one "among the react crowd". I'm really struggling to understand how the author connected using frameworks with using divs for clickable elements. And yes, this problem predated React and HTMX. One of my biggest pet peeves is throwing shade at a certain tech or group of people who use that tech and the proceeding to demonstrate that they don't know anything about said tech.
• Flow 11mo ago
  I started a SvelteKit project last year. The compiler and preprocessors are very picky about accessibility issues like these. It was annoying in the beginning, but I tried to follow the rules it set out. It feels very professional, and I’m thankful for the guidance. What’s annoying now is when my coworkers thinks I’m making things unnecessarily complicated by trying to follow these rules and guidelines. A <div> with an onclick is so easy compared to a <button> with extra styling and sometimes calling preventDefault().
  • Anamon 11mo ago
    I have that experience when working with eslint-angular. Quite a few things I realised I hadn't been doing properly before.
• mexicocitinluez 11mo ago
  What an absurd intro. > One of the weirdest “debates” I seem to perpetually have with framework-enthusiastic developers is whether or not a <div> is “just as good” as a <button>. How does one's desire to use a framework have any impact on their ability to recognize the usefulness of a button? Did I miss something? Is there some portion of any of the major framework documenation that suggests it's better to use divs instead of buttons? > Among the React crowd, and also among people who seem to enjoy HTMX, I see a lot this… Lol This has been a problem since way before React hit the scene. And people not using frameworks aren't magically immune to using divs instead of buttons.
• ayroblu 11mo ago
  I have two annoyances with button, one is you probably want to restyle it, so it’s not no effort vs a div. Another is the warning that you can’t nest buttons. For better or worse, this is common
• hdjrudni 11mo ago
  Using a div instead of a button is just dumb. However, I was tweaking my app today, after having read this article, and realized I'm using some anchor-links as buttons just because I wanted them to be styled exactly like a link. Then I tried adding role="button" and of course I couldn't tab over to my link-button. So I added tabindex="0", just like the article tells you not to do, and that allowed me to tab over to it but I still couldn't activate it with spacebar. So I finally caved and Googled "how do I make a button look just like a link" which brought me to this article: https://piccalil.li/blog/link-button/ https://piccalil.li/blog/link-button/ And now it behaves properly. Yay a11y.