4 ms·

Which becomes a nightmare to look at with no styling: https://jsfiddle.net/wdqjyvsu/ https://jsfiddle.net/wdqjyvsu/ and then it gets complicated very quickly:

Which becomes a nightmare to look at with no styling: https://jsfiddle.net/wdqjyvsu/ https://jsfiddle.net/wdqjyvsu/ and then it gets complicated very quickly: https://jsfiddle.net/wdqjyvsu/1/ https://jsfiddle.net/wdqjyvsu/1/ You also have still undiscovered problems: How to let people filter the options if you have lots of them (and don't say ctrl+f because it doesn't restrict the search within the element)? What about lazy-loading if you have lots and lots and lots of them? Usability is not improved, it takes too much space now. API is even worse. Accessibility is improved contrast-wise but all the tabbing is not very friendly, and try using that with a screen-reader. It takes ages to make a selection.

lhorie 5y ago
No offense, but this feels like trying too hard to make the argument that a perfectly normal pattern is somehow too obtuse to be considered. I'm guessing you're trying to argue that something like a pill autocompleter is more appropriate for specific use cases (e.g. the `to:` field in email clients). And sure, sometimes some controls are better suited than others depending on the use case, but that doesn't necessarily mean that it's impossible to implement similarly complex controls by leveraging standard controls as opposed to reinventing headless behaviors on top of div soup[0] [0] https://codepen.io/lhorie/pen/xxPJpeB https://codepen.io/lhorie/pen/xxPJpeB
- egeozcan 5y ago
  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.
  - lhorie 5y ago
    > 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 :)
    - egeozcan 5y ago
      I'm arguing that you DO need custom controls. Did you read the thread?
      - lhorie 5y 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.
        egeozcan 5y 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).
runarberg 5y ago
You can hide multiple checkboxes in a <details> if it gets to messy: https://jsfiddle.net/3mohuw7e/ https://jsfiddle.net/3mohuw7e/ <details> is pretty easy to style and shouldn’t be to complicated to add extra features like filter fields by search etc.

lhorie 5y ago

No offense, but this feels like trying too hard to make the argument that a perfectly normal pattern is somehow too obtuse to be considered. I'm guessing you're trying to argue that something like a pill autocompleter is more appropriate for specific use cases (e.g. the `to:` field in email clients). And sure, sometimes some controls are better suited than others depending on the use case, but that doesn't necessarily mean that it's impossible to implement similarly complex controls by leveraging standard controls as opposed to reinventing headless behaviors on top of div soup[0] [0] https://codepen.io/lhorie/pen/xxPJpeB https://codepen.io/lhorie/pen/xxPJpeB

egeozcan 5y ago
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.
- lhorie 5y ago
  > 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 :)
  - egeozcan 5y ago
    I'm arguing that you DO need custom controls. Did you read the thread?
    - lhorie 5y 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.
      - egeozcan 5y 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).

runarberg 5y ago

You can hide multiple checkboxes in a <details> if it gets to messy: https://jsfiddle.net/3mohuw7e/ https://jsfiddle.net/3mohuw7e/ <details> is pretty easy to style and shouldn’t be to complicated to add extra features like filter fields by search etc.