Or use basically *any* accessibility feature or try to input text in a different language. Please don't reinvent browser features in JS; you're going to miss on a *lot* of engineering work put into making stuff work for everyone.https://twitter.com/anatudor/status/945370849871265793 …
-
-
Accessibility is just a special case of "paste works, even when paste means long-press for an OS specified amount of time and select 'paste' from an OS supplied menu". Nobody can make <select> correctly work the way it should even when iOS redesigns or when mobile gets popular.
-
I wouldn't really phrase it as a special case; given that there are tons of other things you can get wrong (cursors for non Latin text, for one) even if you let the OS drive the actual input. But yeah, essentially, true.
-
Fair enough, you can't just lean on the OS. But as a starting point, leaning on OS-provided controls that the OS already knows how to make accessible will make the problem tractable. Rebuilding from the ground up makes it intractable.
-
Oh no, that wasn't what I was saying, I was saying that "paste working perfectly" is not the general case because you can get paste to work in accordance with expectations and still have other broken things which the OS would have handled for yourself.
-
Ahhhhh... I was just using "paste" as an analogy for a category of things that people try to reinvent ("I'll just intercept ctrl-v") but which break both *normal* usability as well as accessibility.
End of conversation
New conversation -
-
-
The trouble is these are still very crummy in most OSes and there is no way to fix them

-
Web browsers generally change the appearance and also give you the ability to style things in a limited but powerful fashion.
-
I meant in terms of functionality. For example, https://harvesthq.github.io/chosen/ is miles ahead of any desktop browser <select> implementation I've ever seen
-
Worth mentioning -- regular <select> also has a type-to-search, it just fills an invisible edit field. In this case this input field is implemented using other input fields, which is kinda ok. Doesn't work on my phone, though (kinda the point?)
-
This particular thing really should be improved by browsers.
-
Some search things that I'd love to see improved: string should not reset based on timeout, adding some visual feedback for the search, option to narrow the list of results, option to plug in custom search matching function
-
And for multi-select, making it more difficult to destroy your entire selection would be a good start.
-
And with all of this, replacing <select> destroys the experience on mobile, breaks most autofill, and breaks accessibility. I'm not opposed to people building from scratch, but form controls are a poor place to do it. As
@ManishEarth says, we should fix it if it needs fixing.
End of conversation
New conversation -
-
-
JS reimplementations of native controls annoy me to no end, especially when the author simply wanted it to fit with their theme, which can easily — albeit with some hacks — be done with CSS. Can we get icons in <select> for Christmas 2018 though?
-
Do you want help proposing it?
-
Yes, please!
End of conversation
New conversation -
-
-
When illustrations are a must in a drop down control is the only time I use a custom JS control, which I usually make sure is accessible via keyboard and whatnot, but it’s a lot of pain and still not the best solution for the problem.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
