300 options is a lot but it's not unrealistic. How many countries are there in the world? As a matter of fact, I looked up a sample drop-down <select> widget with all the worlds countries that that's 210 options. So you're saying that as a hefty expense on rendering time?
Now, I can't think of any such widgets in any of my active projects but it would be cool too have some examples to "prove" this.
One thing I have noticed is that when you start having a bunch of SELECT elements, or even a heap of OPTION elements within a single SELECT, you can get really bad rendering times.
IIRC, it only took about 2-300 OPTION elements before it was basically unusable on some machines. And these are desktops, not mobile.
In our case, it was _faster_ (in terms of both developer and user time) to have a JS handler that turned a select element with too many options into an autocomplete.
Comment
300 options is a lot but it's not unrealistic. How many countries are there in the world?
As a matter of fact, I looked up a sample drop-down <select> widget with all the worlds countries that that's 210 options. So you're saying that as a hefty expense on rendering time?
Now, I can't think of any such widgets in any of my active projects but it would be cool too have some examples to "prove" this.
Parent comment
One thing I have noticed is that when you start having a bunch of SELECT elements, or even a heap of OPTION elements within a single SELECT, you can get really bad rendering times. IIRC, it only took about 2-300 OPTION elements before it was basically unusable on some machines. And these are desktops, not mobile. In our case, it was _faster_ (in terms of both developer and user time) to have a JS handler that turned a select element with too many options into an autocomplete.