👍 Thanks!

I had issues with that just now as well. display: block/none seems to work (better) for me, too.

/cc @mlettini

Display none/block didn't perform well on large lists, so then absolute positioning was introduced, moving elements out of the viewport (i.e. left: -10000) which caused issues with focusing.

So please be cautious with merging, because clip actually performed best of all options.

@koenpunt could you elaborate what you mean with "did not perform well on lare lists"? Do you really mean performance or something else?

@koenpunt Also curious about the performance aspect. And if display none/block is not going to perform well, would you suggest we go back to moving it out of the viewport with left: -9999px?

Edit: I see we shouldn't go back to left: -9999px based on the issues that clip originally fixed in 23a3ee6. But I do not see evidence of display none/block being in our code before or performing poorly, so curious about the testing you might have done yourself.

What I can provide is in our application, I tested on very large list, like hundreds of items. I have not seen any performance issues. I also would like to know more about other related issues.

This PR fixes problems I was experiencing in Internet Explorer 11 as well.

Never seen the performance issues myself, and don't know if they still exist in modern browsers. But I know that @pfiller brought it up some times, e.g.

#888 (comment)

#933

But that concern might have not been relevant anymore since #1339

And yes I know, these are all pretty old issues.

Anyway, if @pfiller could chime in about this matter that would be great

Maybe the question we need to ask ourselves is; do select options have to be accessible? Not that Chosen is really accesible right know, but at least the options are being read by screen readers and search engines.

How html5 boilerplate does it might be a solution too:

https://github.com/h5bp/html5-boilerplate/blob/master/src/css/main.css#L128

With these changes, tabbing does not work on the control.

Cross-linking this comment about this apparently being truly broken in Chrome 64, and:

According to their release schedule, looks like Chrome 64 is scheduled to hit stable on Jan 23rd, 2018, at which point we’ll be broken.

/cc @adunkman @mlettini @koenpunt

So to summarize where we're at right now:

• Using clip is deprecated and will break Chosen in Chrome 64 on Jan 23rd, 2018.
• Using display: none/block results in not being able to tab to a single Chosen.
• Using position: absolute and pushing the dropdown off the page will result in all the issues linked to here.

So we need to find another method of hiding the Chosen drop until it gets focus. HTML5 Boilerplate will also need to update, and I wonder if there is any current conversation on this topic happening there. No obvious solutions jump to my mind at the moment...

Thanks for the summary @mlettini!

I think the core issue stems from us using a text input inside of the drop container to receive focus events. This makes sense when that text input is always visible (when <select multiple>) but not when it’s hidden.

I’ve toyed around a bit with using two inputs, one to catch focus events (which lives outside of the chosen drop container) and the second being the text input that currently exists. This allows us to just use display: none on the drop container when appropriate, but still catch focus events.

I don’t have a working pull at the moment, but I’m mostly convinced it’s the right way to go — unless y’all have better ideas!

Replaced by #2939.