Your implementation has a lot of accessibility problems AND requires javascript AND doesn't work on firefox mobile.
Also: Congratulations, we collectively proved the article wrong. It says, "The browser’s built-in controls are quite sufficient". Here we see that you usually can't "just use standard controls", and even when you do, you need a lot of JS on top to make them accessible, usable, nice to look at with an acceptable API.
> has a lot of accessibility problems AND requires javascript
I'm not sure what you're arguing for then, it feels like you're just hating for its own sake. Because obviously not using standard controls and auto-including aria attributes will require JS too. Turn off javascript and CSS as you're arguing for, and then come back with a proper working implementation and then let's talk :)
Of course I did. You're the one going on about unstyled elements and whatnot?
The article is about subtle behaviors that come built into standard UI elements. My point is you can get those behaviors from leveraging these elements instead of literally writing custom code to handle a series of keypresses in a div-soup-based <select>-lookalike.
As far as I can tell, nobody here is arguing for things like no-JS no-CSS solutions. The point is that custom controls implemented on top of div soup are usually much heavier and worse in terms of subtle behavior support than custom controls implemented on top of standard form elements, in the same way that using a sledgehammer as a nail gun is likely to yields sub-optimal results, because details.
Ah, okay now I get the subtlety, I stand corrected.
I'd still argue that there are times that you do have to use completely custom controls, like the case with the date-pickers. Not only because you cannot style them, but they also have a lot of API constraints, and accessibility problems. Even the example in the article, the beloved text area, has a lot of constraints like it's quite cumbersome to get the selection coordinates and it's impossible to offer any highlighting, so welcome to the world of contenteditable!
I completely agree that we should try to compose the native UI controls instead of reinventing the wheel when possible (like the text-input for that date-picker modal).
Yeah I can see why people get torn on date pickers. This was especially egregious back when they weren't as well supported/implemented across different browsers. The problem with them, as some people alluded in some comments, is that often times when people reinvent that wheel, they do an objectively worse job at it.
Because of my bad experience with these poorly implemented controls in the wild, these days I quite appreciate the way the <input type="date"> inputs appear on mobile (i.e. it's a completely different UI than desktop that optimizes against fat fingering/tiny hit areas/etc). Certainly beats implementations that rely on trapping input events and rewriting `input.value` on a plain text input...
Also: Congratulations, we collectively proved the article wrong. It says, "The browser’s built-in controls are quite sufficient". Here we see that you usually can't "just use standard controls", and even when you do, you need a lot of JS on top to make them accessible, usable, nice to look at with an acceptable API.