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.

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.

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.

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?

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

`appearance: none;` gets you a long way

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.

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.

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.

To those disagreeing with Drew here: he’s expressing it very bluntly, but what he’s saying is absolutely correct. People keep on reimplementing what browsers already provide, and they seldom do a good job of it. In fact, often it’s impossible to do a flawless job of it—e.g. you can’t get a custom dropdown to behave (not look, behave) like a native <select> without some fairly detailed user-agent and platform matching (I mean things like whether selection is focus or not, and what Tab does when the dropdown is open and selection is not focus), quite apart from the other details that people often skip over (see https://www.w3.org/TR/wai-aria-practices/#Listbox for a summary); and scrolljacking is always bad because the primitives exposed are insufficient to reimplement scrollable areas.

This is an attitude problem with a large fraction of web developers that causes trouble for users. You should very strongly prefer to use a native element and technique for something if you can. And buttons… well, buttons are a great example of something fundamental that the browser has a good implementation of, which is often reimplemented annoyingly incorrectly.

I don't disagree with this, the main issue I have is that the browser controls are stuck in the 90s/00s: browsers should implement new controls so we have less need for custom work here.

>The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse.

There are plenty of counterexamples.

For example, the date input control does not allow to enforce date format by design, and the auto-detection of user facing format is buggy and inconsistent across browsers on the same system (e.g. Edge legacy ignored Windows' region preference and used the keyboard locale). It tends to show the American-style dates even on non-American locales, making the control not just useless but sometimes actively misleading.

Even apart from that it's pretty basic. Keyboard navigation is bad everywhere bad but in Chrome where it's just mediocre - there's no inline/auto-popup mode like other js pickers, and it requires nonintuitively pressing ENTER to pop-up.

Some browsers like Firefox don't have a 'Today' button, and even in Chrome you can't hide it when it doesn't make sense. No browser has a 'Clear' button which makes sense in some scenarios.

I can go on and on about how flawed that control is, but this is long enough.

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

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.

"Dropdown with multiselect" is addressed by adding the "multiple" attribute to your select tag. Which has been possible since the 90's.

Nope, per MDN:

> When multiple is specified, most browsers will show a scrolling list box instead of a single line dropdown.

This is not “dropdown with multiselect” because it doesn’t “drop down”

Tough shit? It does what you want. It doesn't have to look like what you want.

Your extreme stance is not helping the cause. I recognize, for instance, that the HTML select element, with its current limitations, is unsuitable for some real-world use cases. We shouldn't tell application developers that they're wrong to need something more complex than what the NCSA Mosaic team (edit: or maybe Netscape) defined in the 90s. We need to meet developers where they are and make it as easy as possible for them to do the right thing.

Yeah, I do html/css whenever I can: part of the issue is just that html has been neglected compared to css/js over the last ten years or so: the form controls are mostly just what we had in the 90s and they haven’t really developed into a comprehensive set of the controls we need to make applications. It’d be amazing to have something like react-select or a datagrid/Google Sheets-style table as an element but, instead, we mostly are getting CSS and JS improvements, which means that people are going to tend to use divs with CSS/JS for behavior.

It doesn’t do “what I want”, it’s completely unsuitable for most of the use cases I’ve run into. Additionally, this sort of response will never work with a product manager or ux designer.

It's your job as the engineer to tell the product manager or UX designer "no" when they ask you to build interfaces which lock disabled users out of the product. Take some responsibility for the code you write. And if you really cannot use <select multiple>, then have the discipline to read the AIRA guidelines and make sure that whatever you come up with works for everyone.

Not really, the point of having these people is for them to make product and ux decisions. It’s my job to implement the use case they come up with (or quit): I can provide technical advice and suggest easier/better ways to solve their problems but, ultimately, it’s their call.

That's a really shitty way to think about your job. If you don't have the courage to advise your peers (which is what the product manager and UX designer are, your peers), then you aren't worth your salary as an engineer. Thinking for yourself and pushing back against bad designs is part of your job. Do your job.

> "fix this attitude"

I agree with you, hence my first sentence, "guilty of this more often than I should be". I'm much better about using semantic and accessible markup nowadays but I wanted to give some perspective to others who may not be webdevs and are wondering how and why those damn monkeys can screw things up so badly ;)