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
