Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Old fashioned html option lists #65

Closed
rwales1000 opened this issue Mar 4, 2022 · 5 comments
Closed

Old fashioned html option lists #65

rwales1000 opened this issue Mar 4, 2022 · 5 comments

Comments

@rwales1000
Copy link

Traditional option lists limit the user to typing the first character when selecting. Why not offer type ahead? This would be a major step forwards for this vintage web control.

@tophf
Copy link

tophf commented Mar 4, 2022

AFAIK, the <select> dropdown is shown as a native OS control, so the browser can't change its behavior without hooking into the OS internals, which is fragile and not even possible on all platforms. The long-term solution would be to implement such controls in the browser, which would solve a lot of long-standing problems inherent to the platform implementation, which was based on UX/UI of the '90s when these controls where introduced.

Related: #11.

@maniatoffl
Copy link

I always wondered , How come we are not able to customize the view of heavily used select dropdown. This leaves majorly two options.

  1. Go with browser's default option (Mostly Designer won't be ok with that. Also you would have made fully colour full web page but still have to live up with default size and coloured select options)

  2. Go for librayYouUse-select. (Ex. react-select) component where you can customize the styles. Internally this select dropdown created with the help of div elements with javascript . Which is not recommended as per accessibility best practices.

As you can see , Both the options has cons. Would be better If we get this sorted in some way.

@gsnedders
Copy link
Member

@rwales1000 We just opened up for Interop 2023 proposals yesterday, see https://github.com/web-platform-tests/interop/blob/main/2023/README.md for the process and what to expect.

If you're still interested in proposing this, could you resubmit (or edit) this based on the template we now have?

@gsnedders
Copy link
Member

Also, from the implementer point-of-view: Safari does support this on macOS today, it will move to the first item matching the string thus far typed. This is likely something we don't really want to standardise, as we likely want to match OS behaviour here to avoid surprising users.

When it comes to more complex alternates, there's also work going on around groups such as Open UI with select elements which are more customisable.

@gsnedders
Copy link
Member

Closing this without prejudice; "If you're still interested in proposing this, could you resubmit (or edit) this based on the template we now have?" still holds.

@gsnedders gsnedders closed this as not planned Won't fix, can't repro, duplicate, stale Sep 24, 2022
@gsnedders gsnedders added focus-area-proposal Focus Area Proposal and removed agenda+ labels Sep 24, 2022
@gsnedders gsnedders added this to the Interop 2023 milestone Sep 24, 2022
@foolip foolip removed the focus-area-proposal Focus Area Proposal label Oct 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants