4 ms·

Someone tell me I'm wrong and why, but this whole thing seems like unnecessary complication? We have JavaScript for bespoke select tags.

by donatj 2y ago

_heimdall 2y ago
Writing your own select menu means having to redo all the accessibility built into the <select> element. Keyboard accessibility seems to be particularly bad for a lot of custom select menus I come across.
extra88 2y ago
We have endless different poorly-implemented variations that sort of look like <select> but typically lack the semantics or non-pointer operability they require. Also, the JS variations are less performant and often insufficiently responsive to viewport/container sizes (not that a highly stylable <select> will be immune to layout problems).
jaffathecake 2y ago
See https://news.ycombinator.com/item?id=41912960 https://news.ycombinator.com/item?id=41912960 - the custom ones are almost universally bad. https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/ - I think this is a good template for how the platform should grow. Folks defining the platform should observe what web developers do, and come up with features that make that work better, faster, and more reliable. In this example, folks historically have recreated their own <select> from scratch because <select> isn't customisable, and in doing so they create an experience with poor accessibility and keyboard navigation. This effort lets them take native accessibility and keyboard navigation, whilst being able to control the visual style of the <select> button and its popover. You can still use JavaScript with your customised <select>, but you don't need as much. Here's a podcast where I go through 10 related general features we got along the way to making this work https://offthemainthread.tech/episode/stylable-select-element/ https://offthemainthread.tech/episode/stylable-select-elemen....

Someone tell me I'm wrong and why, but this whole thing seems like unnecessary complication? We have JavaScript for bespoke select tags.

by donatj 2y ago

Someone tell me I'm wrong and why, but this whole thing seems like unnecessary complication? We have JavaScript for bespoke select tags.

_heimdall 2y ago

Writing your own select menu means having to redo all the accessibility built into the <select> element. Keyboard accessibility seems to be particularly bad for a lot of custom select menus I come across.

extra88 2y ago

We have endless different poorly-implemented variations that sort of look like <select> but typically lack the semantics or non-pointer operability they require. Also, the JS variations are less performant and often insufficiently responsive to viewport/container sizes (not that a highly stylable <select> will be immune to layout problems).

jaffathecake 2y ago

See https://news.ycombinator.com/item?id=41912960 https://news.ycombinator.com/item?id=41912960 - the custom ones are almost universally bad. https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/ - I think this is a good template for how the platform should grow. Folks defining the platform should observe what web developers do, and come up with features that make that work better, faster, and more reliable. In this example, folks historically have recreated their own <select> from scratch because <select> isn't customisable, and in doing so they create an experience with poor accessibility and keyboard navigation. This effort lets them take native accessibility and keyboard navigation, whilst being able to control the visual style of the <select> button and its popover. You can still use JavaScript with your customised <select>, but you don't need as much. Here's a podcast where I go through 10 related general features we got along the way to making this work https://offthemainthread.tech/episode/stylable-select-element/ https://offthemainthread.tech/episode/stylable-select-elemen....