5 ms·

I'm guilty of this more often than I should be. I think the reason I sometimes reach for divs over buttons or other semantic elements is because I've been burne

by bavell 6y ago

I'm guilty of this more often than I should be. I think the reason I sometimes reach for divs over buttons or other semantic elements is because I've been burned by default browser behavior treating them special when I just want a dumb box with a dumb click handler - no default styling that I need to override, no need to call .preventDefault(), no need to worry about the matrix of OS+browser+device that each treats a button slightly differently, etc etc... Some of this fear may be unfounded or now obsolete but years ago it wasn't fun fixing bugs clients ran into due to silly issues caused by these kinds of things.

mwcampbell 6y ago
Thanks for sharing your perspective on this. Does anyone know if the web platform now provides a foolproof way to clear all default styling on a button or other standard control?
- crisnoble 6y ago
  `appearance: none;` gets you a long way
  - plussed_reader 6y ago
    But muh ableist design preferences....
    - mwcampbell 6y ago
      Please avoid this kind of unconstructive snark. I'm prone to it myself when discussing this subject, but I try to avoid it when discussing accessibility with a broad audience like HN. I want to meet mainstream developers where they are, figure out what prevents them from making their applications accessible, and do something about it, not just guilt-trip them.
      - crisnoble 6y ago
        I actually use <button> with appearance:none specifically for accessibility. You get all of the benefits of a button's accessibility, focus, click events, normal tabbing, etc, and can use them for things like toggling an accordion of content or showing/hiding a mobile menu. Better than a div because you don't need aria-role, and better than a link because it is not taking you anywhere. As pointed out up thread, developers and designers often skip using <button> because it is hard to style just right. Using appearance:none resets the style but not the accessibility behavior.
- no_wizard 6y ago
  Yes. This is a good article from CSS Tricks on the subject matter, which describes it all better than I could. https://css-tricks.com/custom-styling-form-inputs-with-modern-css-features/ https://css-tricks.com/custom-styling-form-inputs-with-moder...
ddevault 6y ago
You should fix this attitude, becuase it's making your applications worse. The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse. If the browser can do something for you, you ought to let it do that for you. If you insist on writing your own controls, its behavior will differ from how the browser's own UI works in subtle ways, repeated indefinitely for each combination of OS and browser and user input paradigm. People who rely on muscle memory to use these features, people who perhaps cannot percieve whatever UI hints you come up with to teach your custom control, or people whose needs you have forgotten about, will all struggle to use your UI. And for what? It looks prettier? No thanks.
- corytheboyd 6y ago
  I didn’t downvote because I can agree to a certain extent. Are you suggesting a completely unstyled web or something? Maybe if you fleshed out that idea you would be met with less criticism. There is a good lesson here though, native browser controls should ALWAYS be your first consideration when building UI for the web. Try everything under the sun to stick as close to these as possible before you give up. You will thank yourself for having less code in which something can break. Your users will thank you for already knowing how to use the controls. An example that drives me crazy is when dropdowns that could have been a select/option group of controls are not. Because most of the time the subtle but insanely helpful keyboard controls are completely missing. Being able to type with the menu selected to jump to items is insanely helpful when the creator insists on jamming too many options into it. Think about that, it’s not exactly trivial to implement, and by the time you have the dozens of lines of JavaScript to implement it correctly... pretty hard not to ask yourself “what the hell am I doing...”
  - fiddlerwoaroof 6y ago
    Dropdowns are frustrating because the select/option is only really good for simple cases and browsers block restyling: as soon as you get a requirement like “Dropdown with multiselect”, you have to rewrite the whole thing: and, for visual consistency, this usually means rewriting all the dropdowns.
Vinnl 6y ago
Interesting - I would have expected the reverse to be true, i.e. if you often reach for divs first, you'd often be burned by e.g. enter-to-submit not working, or the wrong keyboard showing up on mobile, etc.
- chrismorgan 6y ago
  The trouble is that it’s users that are burned by this, and only a subset of them, so the developer doesn’t notice unless it affects their particular usage patterns. But if you have things like “I put my button inside a form, and now when I click on it the page reloads” (because it’s now a submit button, so you need to either change it to type=button or add event.preventDefault() to your click handler or form submit handler, according to taste), that’ll affect everyone, and thus you’ll notice it immediately, and thus it’s you as a developer being burned by it, and so you notice it.
  - Vinnl 6y ago
    I see; pretty much the same reason a common problem is that only the happy path works properly - that's the thing for which it's inherent to the development process that it gets tested.

by bavell 6y ago

mwcampbell 6y ago

Thanks for sharing your perspective on this. Does anyone know if the web platform now provides a foolproof way to clear all default styling on a button or other standard control?

crisnoble 6y ago
`appearance: none;` gets you a long way
- plussed_reader 6y ago
  But muh ableist design preferences....
  - mwcampbell 6y ago
    Please avoid this kind of unconstructive snark. I'm prone to it myself when discussing this subject, but I try to avoid it when discussing accessibility with a broad audience like HN. I want to meet mainstream developers where they are, figure out what prevents them from making their applications accessible, and do something about it, not just guilt-trip them.
    - crisnoble 6y ago
      I actually use <button> with appearance:none specifically for accessibility. You get all of the benefits of a button's accessibility, focus, click events, normal tabbing, etc, and can use them for things like toggling an accordion of content or showing/hiding a mobile menu. Better than a div because you don't need aria-role, and better than a link because it is not taking you anywhere. As pointed out up thread, developers and designers often skip using <button> because it is hard to style just right. Using appearance:none resets the style but not the accessibility behavior.
no_wizard 6y ago
Yes. This is a good article from CSS Tricks on the subject matter, which describes it all better than I could. https://css-tricks.com/custom-styling-form-inputs-with-modern-css-features/ https://css-tricks.com/custom-styling-form-inputs-with-moder...

ddevault 6y ago

You should fix this attitude, becuase it's making your applications worse. The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse. If the browser can do something for you, you ought to let it do that for you. If you insist on writing your own controls, its behavior will differ from how the browser's own UI works in subtle ways, repeated indefinitely for each combination of OS and browser and user input paradigm. People who rely on muscle memory to use these features, people who perhaps cannot percieve whatever UI hints you come up with to teach your custom control, or people whose needs you have forgotten about, will all struggle to use your UI. And for what? It looks prettier? No thanks.

corytheboyd 6y ago
I didn’t downvote because I can agree to a certain extent. Are you suggesting a completely unstyled web or something? Maybe if you fleshed out that idea you would be met with less criticism. There is a good lesson here though, native browser controls should ALWAYS be your first consideration when building UI for the web. Try everything under the sun to stick as close to these as possible before you give up. You will thank yourself for having less code in which something can break. Your users will thank you for already knowing how to use the controls. An example that drives me crazy is when dropdowns that could have been a select/option group of controls are not. Because most of the time the subtle but insanely helpful keyboard controls are completely missing. Being able to type with the menu selected to jump to items is insanely helpful when the creator insists on jamming too many options into it. Think about that, it’s not exactly trivial to implement, and by the time you have the dozens of lines of JavaScript to implement it correctly... pretty hard not to ask yourself “what the hell am I doing...”
- fiddlerwoaroof 6y ago
  Dropdowns are frustrating because the select/option is only really good for simple cases and browsers block restyling: as soon as you get a requirement like “Dropdown with multiselect”, you have to rewrite the whole thing: and, for visual consistency, this usually means rewriting all the dropdowns.

Vinnl 6y ago

Interesting - I would have expected the reverse to be true, i.e. if you often reach for divs first, you'd often be burned by e.g. enter-to-submit not working, or the wrong keyboard showing up on mobile, etc.

chrismorgan 6y ago
The trouble is that it’s users that are burned by this, and only a subset of them, so the developer doesn’t notice unless it affects their particular usage patterns. But if you have things like “I put my button inside a form, and now when I click on it the page reloads” (because it’s now a submit button, so you need to either change it to type=button or add event.preventDefault() to your click handler or form submit handler, according to taste), that’ll affect everyone, and thus you’ll notice it immediately, and thus it’s you as a developer being burned by it, and so you notice it.
- Vinnl 6y ago
  I see; pretty much the same reason a common problem is that only the happy path works properly - that's the thing for which it's inherent to the development process that it gets tested.