Propose upgrade to <select> element

[paulirish]

I think we've seen <select> boxes get huge UX upgrades via javascript libraries in the past few years.

The Chosen project was the first and was later improved on with select2

The idea: let's get this upgrade into browsers. We can make massive UX gains on both desktop and mobile, and kill off javascript that many sites have to ship with.

---

chosen-style<select> control

demo

pitch:

the interactive select box style popularized by Chosen should be available to the web platform natively.

benefits:

• UX
  • visual affordances over implied keyboard interface knowledge
  • searchability in long list
  • multiple selections are more clear
  • essentially backporting modern web app conventions to the <select> control
• visible placeholder
• others?

  questions:

• behavior in mobile/touch?
• is it opt-in? if, so probably an attribute on the tag like <select interactive>. There's probably a better name.
  • alternatively changing ALL <select> to this is more audiacious, but might be fine.

    todo:

• bounce the idea off #whatwg irc to see if there are any questions that need to be answered for sure in the whatwg list proposal
• investigate pulling scope from select2
• bounce it off web-standards-dev
• propose it to the whatwg list
  • we can rope in the chosen developers for support and to answer questions as well.
• make a polyfill.

  people involved so far:

• Irakli Nadareishvili - @inadarei - dir of engineering, digital media, NPR (proposal initiator)
• Paul Irish - Chrome developer relations (facilitator)
• Marcin Wichary - Chrome designer (idea enjoyer)
• you!

/cc select2 devs: @ivaynberg @ProLoser /cc chosen devs: @pfiller @mixonic

---

I think we need some more people to help flesh out the idea. I'm not sure Irakli has the bandwidth to drive this one, so looking for someone else to be the fearless leader.

[ProLoser]

Very awesome. However one of the things that has occurred to me is that this seems more of a task for the browser devs than anyone else (such as how they may visually choose to render a select). In addition, you already are capable of typing your search into a select to quickly find the option you want.

[inadarei]

Paul,

thanks for posting this. Beyond the bandwidth issue, to be honest it's a little too much for any single person so maybe I got scared? I would never admit to it, though :)

Dean,

the usability benefits of something like Chosen go far beyond what current select box can do. While the improvements may be marginal for a single-item select box, as you pointed out, when you get to a long, multiple-choice select box, the regular one becomes practically useless for a number of elements beyond 50 (or even 20?), whereas something like Chosen is still very functional.

A more minor issue is also 'skinnability' of a select box. Standard one looks completely different in each browser and on various operating systems and there is really no way to change look and feel through CSS, which as most designers would admit - really sucks.

cheers,

Irakli

[paulirish]

@proloser basically this idea needs to be proposed to the WHATWG in order for browser devs to kick off any work on it. And it needs some legwork to get it ready for that stage. :) That's why I started this ticket, to get some folks interested in helping drive this one forward.

And yes, part of this is that appearance was dropped from CSS3 UI and nobody has bandwidth to pick up that property. @tantek had his own reservations about its standardization potential. So for now styling form widgets is a bit stalled, but regardless, that's a separate issue from this enhancement, IMHO.

---

Looking closer at select2 I'd say its major enhancements are probably out of scope for the initial proposal, and would be handled by the UA and adding new <option> elements dynamically.

[ivaynberg]

Support for dynamically adding <option> tags has to be there from the beginning and properly thought through. There were a couple of attempts to do this in Chosen to achieve what Select2 does and they have all, imho, failed or were very awkward. Thus Select2 was born...

[paulirish]

Support for dynamically adding tags has to be there from the beginning and properly thought through.

Certainly. Can you list out the behaviors that should happen when new option elements are added?

[ProLoser]

Adding new items in select2 isn't noticeable until the next time it is expanded. If it was already open the results have been appended. There have also been use cases when a value is selected that is not present in the list immediately but must be retrieved dynamically. This case may be out of scope but it comes up quite often.

[ivaynberg]

Certainly. Can you list out the behaviors that should happen when new option elements are added?

its not about what happens when they are added, its more about how they are added and removed.

for example, to support the tagging use case, the control needs to support adding items on the fly. in Select2 this is accomplished by checking if there are any matches in keyup of the the search box, and if there are none prepending a new choice to the beginning and highlighting it.

to accomplish such a behavior we need:

• access to the search field events
• a callback that can create a new option
• ability to insert or remove an option into the specified position in the list
• tell the control to highlight a specific option and scroll it into view if necessary

we would also need an opening event so the initial list of options can be built as well as a closing event to perform any cleanup.

to support paging and lazy loading of results from the server the control needs to fire an event when the last option in the options list becomes visible.

for multiselect the control should be able to conditionally hide options that are already selected to prevent selection of duplicates

it would be nice if the presentation was more configurable. the option tag is too limiting. see the Infinite Scroll with Remote Data Select2 example here: http://ivaynberg.github.com/select2/

[mixonic]

@pfiller and crew decided to be extremely picky about what went into Chosen early on. IMHO, the reason Chosen was such a successful project was because it purposely ducks the question about how to do all kinds of special stuff, and focuses only on enhancing the features (and UI/usability) of select boxes today. Sticking to the common and expected select box features and not prescribing AJAX search solutions or data loading is what make Chosen popular and universal.

I'd suggest that there are two goals here: One is a usability question about how to enhance current select box functionality and encourage consistant form styles across browsers (without new HTML or APIs). Chosen makes for a nice inspiration.

The second is how/if the select UI could be used for other purposes, via more event and API hooks or new features on the DOM. This is a far more difficult problem to solve, and I think most people would agree separating the usability enhancement from the new features would give both a greater chance of success. In a wild and messy browser world, picking the smallest fight possible is to your advantage.

I'll make sure Patrick and Matt L. at Harvest are up on this conversation. I'm certain they would want to know there is some discussion of pushing Chosen-like enhancements right into the browser.

[paulirish]

Sounds great, Matt. Really appreciate you chiming in. Totally agree with the two problems and that the first chunk is the high priority for this effort.

[franzliedke]

It confuses me that the proposed multi-select fields are - visually - not clearly discernable as multi-select fields. I don't know whether an arrow would make sense, but making it a little clearer would be nice.

[tableless]

Great idea. We from Brazil can help. Let we know how we can help!

[brianreavis]

Not to hijack the thread, but I'm currently working on something like this that addresses quite a few of the problems of Chosen (item creation, unicode support, searching not just by the beginning of each value (smarter ranking, like Sublime Text), support for fluid widths, easy skinning, caret between items, natural-feeling keyboard control, etc). It's roughly similar to select2, but different in feel & [programming] interface. I'll be open-sourcing it in the next few days.

Here's the repository: https://github.com/diy/jquery-selectize.

I'm up to help in any way I can!

Chosen is nice... but it's anything but configurable (for better or worse).

[ivaynberg]

@brianreavis http://ivaynberg.github.com/select2/

[anentropic]

turning Antarctica into Albania is a "huge UX upgrade" ...??

[CWSpear]

I think the features in Chosen are great, but let's not run before we can walk. At this point, I'd be happy with being able to easily and fully style dropdowns without CSS hacks or JavaScript.

[n00b2pr0]

+1 I think this would be a great time to propose an upgrade to the select. This would be an opportunity to propose the select be completely styleable for those who don't like the browser default input UI.

[brianreavis]

@ivaynberg Edited my comment :)

[louisremi]

Those kind of "advanced controls" will never be configurable enough for everyone out there.

Isn't it the perfect use-case for Web Components? This isn't a solution to the script size problem, but you probably need much less code than what's included in Chosen+jQuery to achieve the same results in browsers modern enough to implement Web Components.

Maybe we could focus on creating native implementations of some features from those components that still require extra JS in modern browsers. I can already think of "searching for a string in an array", what else?

[paulirish]

I'd be happy with being able to easily and fully style dropdowns

Unfortunately, the appearance is totally frozen in the standards groups, so it may be less likely than the above.

Isn't it the perfect use-case for Web Components?

Yes.. Yes it definitely is. :)

[kurtextrem]

Multiple selects should stay. I don't want every site to turn into a facebook like style.

[alexmingoia]

The reason chosen and select2 were created was because the select sucks but we couldn't modify it. I'd argue that the actual problem is the inability to modify the UI of document widgets (even to a minor degree).

If browsers change the UI of <select> without allowing developers to modify it, we'll end up in the exact same scenario a couple years from now but with a different <select>.

[pfiller]

I'm excited by the prospect of seeing a chosen-like select widget baked into a browser. Chosen attempts to solve some of the usability issues that exist as a result of select boxes becoming the defacto way developers show large lists of options. We've done our best to make Chosen work as much like a native select as possible, but browsers behave differently and it's certainly not perfect. A native control would work as the user expected without increasing page size. It would also be more performant for searching large lists.

It's a little disappointing that to see this thread has focused so much on aesthetic. Form elements are not beautiful, it's true, but that's a small pain point compared to the issues of an actual select element. Solving the biggest usability issues would be a much bigger win than being able to style it to match your website.

• Users cannot see all options available and don't know they can type to find options that may be off screen. Even those who do type find the typing behavior to be unpredictable.
• Users don't know how to select multiple elements in a multi-select effectively rendering them useless.
• Users can't always see their selections in a multi-select.

Native select elements would be greatly improved if they only added a handful of features. Anything else would just be icing on the cake.

• Search
• Showing all selected options (multiple)
• Easy to deselect options

I've tried to keep Chosen's scope focused on solving usability problems in the best way possible. Yes, we've added some things that aren't normally part of select elmeents, but we've done so carefully. I think Select2 is a great project, but there are features included that aren't essential to a native select element. I imagine narrowing scope would make it more likely for the browser vendors to get involved in something like this.

Select boxes have been virtually unchanged since the 90s and only a fool would argue there's no room for improvement. I'd love to be involved in whatever capacity made sense. Thanks for heading this up, @paulirish

[say2joe]

@pfiller I just want to say that your last comment regarding prioritization based on usability is, in my opinion, concise and exactly the basis for which browsers should implement the aforementioned changes in native code. Overriding styles or simply applying matching theme styles (though a simpler approach would be appreciated) is a nice-to-have; not a necessity from the perspective of usability. Search and showing all selected options is a definite necessity.

[jswartwood]

(It seems) the HTML5 menu element has shifted from being overtly generic to a focus on commands. I may be misguided on the semantics of this new element, but my understanding was that it was meant to replace CSS/JS crafted navigation or context menus and help avoid improperly used selects.

We may want to consider proposing an alignment of styling and functionality hooks (events). At the very least, single-select selectboxes should have a good deal in common with menu. While I believe the use-cases warrant divergent semantics, there is a great likelihood that designers will want the ability to style actionable lists exactly the same as data lists.

[gfranko]

I think this is a great proposal. Plugins such as Chosen, Select2, and SelectBoxIt (I write that one) are great plugins, but their functionality does go above and beyond what should be included in the first phase of this proposal. Having the ability to customize the style of dropdown's would be a huge win for the web.

[ghost]

So you're asking to make it a Shadow DOM component?

More on the Shadow DOM here:

http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ http://www.w3.org/TR/shadow-dom/

Nice video at Google IO 2012 on the Shadow DOM: http://www.youtube.com/watch?v=2txPYQOWBtg

Another lesser known effort by Mozilla is X-Tag components. Some-one should create an X-Tag component of Chosen first, then we can worry about making a Shadow DOM Component. (IMHO)

https://github.com/mozilla/x-tag-elements http://x-tags.org/

The only issue with using X-Tag is you need to include JS in your page, but the overhead is minimal compared to jQuery.

X-Tag is (22.096 kb) at time of writing, uncompressed: https://github.com/mozilla/x-tag/blob/master/x-tag.js

I am curious as to why a jQuery powered plugin was chosen for this proposed revision of the <select> element. Aren't Shadow DOM widgets usually done in vanilla JS / Library agnostic JS for performance reasons.

Unless of course, jQuery itself is baked into the browser. That would be awesome.

[tchak]

We need to stop believing native controls will ever catch up with UX requirements... What we need from browsers are solid primitives for controls with reach javascript APIs and full shadow dom exposure for css styling.

[ghost]

I second @tchak. There needs to be more emphasis on CSS. Case in point:

http://iwantaneff.in/custom.webkit.scrollbar.css

The fact that native controls can be styled this way is fantastic. It puts more control in the hands of the designer. There is heated debate over how much control a designer should have though,

In the case of We Want Chromeless http://iwantaneff.in/chromeless/

I am proposing the whole UI of the browser can be freely styled with CSS, without the need for third party plugins, or additional extensions. This wasn't received well in the dev community because of the inherent security issue.

Which brings up the following conundrum as web designers:

How much freedom do we have to design? Are we limited to just the viewport, and what the browser vendors have set out for us, or can we Design All The Things?

[tchak]

@higgo I am not trying to emphasis on css. CSS is jast part of the problem. @pfiller made a very good point about inherent problems of select from interaction point of view. We need some rich javascript data manipulation APIs on select element. And as for full browser styling, I think it is a little bit out of the scope :) (and I do not see the point) On the other side, I am for full styling of controls inside the view port.

[ghost]

Good words @tchak. By all means, yes, JavaScript is needed. I agree with you there. It's just I see no point implementing a Chosen-like <select> widget if we can't freely style it via CSS.

There has been a long run of controls being thrown out left right and center in HTML5 (Range / Color-picker, etc) But their design / look-and-feel is then 'set in stone' by the vendor, and we can't style them.

The new native controls will probably get better in time design-wise, as they are fairly new, but the design decision of such controls should be considered, for a designer who wants the control to blend in with his website.

For example, if your site is designed in Bootstrap, you want a 'Bootstrapey' styled control. Case in point: http://iwantaneff.in/repo/plugins/effects-ui/jquery.ui.bootstrap/index.html

Consistency is the key here. This is why I proposed We Want Chromeless. The viewport's look-and-feel should match that of its surroundings.

It annoys me no end when the browser's encasement muddles up a beautiful looking website. You can't have a discussion on styling, and re-implementing the <select> element without discussing chrome. (Not Chrome, the browser) Actual chrome is important here too ;)

This has me wondering about the always funny situation when a designer tries to emulate an Operating system's chrome by making the colors the same as the site visitor's system. For example - modal alerts designed exactly like Windows dialog boxes, and using system colors to style the whole site.

For more on System Colors -

http://www.iangraham.org/books/xhtml1/appd/update-23feb2000.html

[jswartwood]

@higgo chromeless is too monolithic for this issue. While it would be fantastic to have a solution that solves all browser styling problems at once, we don't want to block smaller wins along the way.

The chrome less discussion should move to another lazyweb-requests issue which can be referenced here. Let's keep selects moving forward.

[ProLoser]

One of the things that confuse me personally is how the nav and menu elements are actually in any meaningful way different. If a menu is intended for actionable items, what about those scenarios that are mixes of information and actions. On a somewhat unrelated note, I recently came across the realization that some people think of chosen / select2 as a separate input to that of typeahead.

[ivaynberg]

@ProLoser chosen and select2 are different from typeahead. typeahead allows the user to enter an arbitrary string, while providing suggestions. chosen and select2 only allow a selection from a predefined list of choices.

[ProLoser]

Not when you have Select2 in tagging mode. What I'm saying is should a clear distinction be made, or should both of these functionalities be lumped together at all? The difference seems to only be with normal select2/chosen the input is a textbox before you start typing vs a button when you start typing. It's purely visual.

[niyazpk]

@brianreavis :+1:

Any progress on this?

It would be awesome if you can provide some documentation to the project. I feel like the lack of documentation is preventing the project form taking off..

[stuartpb]

I've started a thread for this on the WICG discourse: http://discourse.wicg.io/t/extending-select-a-la-chosen-select2/940

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had recent activity. Thank you for your contributions.