4 ms·

What gets me is when fancy-pants JS devs disguise complexity and features nobody has asked for behind native html looking controls like select menus. I see thi

What gets me is when fancy-pants JS devs disguise complexity and features nobody has asked for behind native html looking controls like select menus. I see this most often with the city and state inputs, where city is a text input and state is a drop-down/select menu. As a Texan, I will type my city, tab to the State select menu and type "t" followed by another "t" then tab to the next form element. But what I'm seeing lately is a text input (search field) dressed up like a drop-down menu... So my t , t input results in a text search for a literal "tt" instead of selecting Tennessee then Texas. It's so aggravating. Now if someone chooses to click the triangle in the drop-down menu, and scroll through the states, the element would work as expected... If you only wanted to interact with the element with you mouse. If it ain't broke, don't fix it.

cletusw 3y ago
This is (was) largely a problem caused by holes in the web platform. Historically it was incredibly hard (if not impossible) to style or otherwise extend the behavior of a true <select>, so most apps had to reimplement it (poorly). <selectmenu> seems to be the new styleable built-in replacement. And then because code sharing across apps/frameworks/companies/etc was historically very hard, only really big companies had enough headcount to build fully functional, accessible, customizable replacements for built-in components. Web Components solve this, allowing global collaboration on common leaf node components like <select>. Related: https://blogs.windows.com/msedgedev/2022/05/05/styling-select-elements-for-real/ https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...