undefined | Better HN

0 pointslhorie4y ago0 comments

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

0 comments

4 comments · 1 top-level

egeozcan4y ago· 3 in thread

I'm arguing that you DO need custom controls. Did you read the thread?

lhorieOP4y ago

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.

egeozcan4y ago

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

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

j / k navigate · click thread line to collapse

0 comments

4 comments · 1 top-level

egeozcan4y ago· 3 in thread

I'm arguing that you DO need custom controls. Did you read the thread?

lhorieOP4y ago

Of course I did. You're the one going on about unstyled elements and whatnot?

egeozcan4y ago

Ah, okay now I get the subtlety, I stand corrected.

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

lhorieOP4y ago

j / k navigate · click thread line to collapse