2 ms·

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

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

lhorie 5y ago
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...