[whatwg] Select element suggestion

I know it is rather late in the game, but there is an attribute that would be immensely useful for SELECT elements.  It is motivated by a desire to make web page interaction more efficient.

It is frequently the case that SELECT elements of size 1 (drop downs) are quite long, requiring scrolling to reach most of the options.  For example:
Year a person was born in
States of the US
Countries of the world
Height (in inches or cm)

This necessitates a minimum of 4 actions for most of the options (click to pull down the select, click on scroll bar, drag scroll bar, click desired option) vs. 2 actions (the first and last) for those options near the top.  Clearly the time difference is significant, especially when the same select element must be selected on repeated visits.  Furthermore, the overwhelming liklihood is that only a few of the many options will ever be of interest to any individual.

Therefore, it makes sense to float those values to the top of the select element in a reasonable way.  What's reasonable?  I would like to suggest:
frequencyLimit=percent


<SELECT name=states frequencyLimit=16>
<option>Alabama</option>
<option>Alaska</option>
<option>Arizona</option>
<option>Arkansas</option>
...
<option>Wyoming</option>
</select>

This would say that if any element is selected 16% or more of the time, it floats to the top part of the select element.  It would apply to any select element of the same name and frequencyLimit at [for efficiency reasons] the current page's directory level or lower.

Specifically, a reasonable UA implementation would be:
For each select element of a minimum size (say 9 elements) with frequencyLimit set, compute a checksum of the select element (e.g. md5) and if that matches the previous value, then frequency analysis should be done (otherwise, start with a fresh slate).  The initial position (for reinsertion purposes) of each option and frequency count of each option is stored.

If the frequency of an option being selected reaches the threshhold, it is moved to the top portion of the select element.  If the frequency drops below this threshhold, it is moved back to its original position.

This is clean, backwards compatible, and offers a clear advantage in usability, especially for impaired users.  It is something that could be implemented by javascript on individual web pages, but it makes more sense to have a uniform approach.

A few comments/pitfalls:
1.  If frequencyLimit=p, this does not float the Math.floor(100/p) most frequently selected options to the top.  At most that many will get floated to the top.  For example, with frequencyLimit=33, if Oregon and New York are both selected 40% of the time, while ILlinois and California are selected 10% of the time, only Oregon and New York will float to the top since only they exceed 33%.

    To consider a second example in this light, frequencyLimit=5 might seeem to mean that one can expect 20 elements to float to the top, but it is extremely unlikely that there would be such uniform distribution of selections.  It's far more likely that fewer than 10 elements float to the top.

    One could put lomething like frequencyLimit='.2', effectively floating anything that is selected to the top.  However, this would create two separate lists within the select, likely leading to confusion.  If M is the maximum number of options that can be seen at any one time, probably the frequencyLimit should ensure that no more than M options get floated to the top.

2.  Of course this proposal represents a demand on the UA to cache the information across sessions as with cookies, so it makes sense for the UA to limit the number of such cached select elements under any particular domain/directory.  In addition, there is some exposure of privacy, so these saved values should perhaps live and die with corresponding cookie information.

3.  As outlined above, the scheme does not work for dynamically populated select elements.  However, in those situations, frequencyLimit should not be set a priori (in the HTML); rather, it should be set after the select element is populated.  At this point, the UA would then compare the select element against any cached image (ie. checksum).  This also provides a mechanism for the server to clear out cached information, by setting frequencyLimit on an empty select element.

4.  Everything can apply just as well to multiselect elements and to elements of size greater than 1.

5.  One could envision only using the last n selections (where n is say 100) for analysis, but this puts an additional implementation burden on the UA.


Csaba Gabor from Vienna

Received on Tuesday, 15 July 2008 05:14:07 UTC