[whatwg] Select element suggestion

[Ian Hickson]

On Mon, 17 Nov 2008, Csaba Gabor wrote:
> 
> > This might be a useful feature for a User Agent, but I don't think it 
> > needs to be standardized.
> 
> > If browser A uses the most common responses from similarly named 
> > fields, browser B uses the most common responses to this field in this 
> > form, browser C uses the user preferences (so that "State" always 
> > default to "Michigan" for me), and browser D never reorders (or 
> > doubles) options -- then so what? Will the server side ever know the 
> > difference?
> 
> No, the server side will not know.  As [I've] presented [it], there is 
> no compelling reason for the server to know the ordering (other than 
> perhaps statistical gathering reasons, for which there is a mechanism).
> 
> > *Not* reordering them from a DOM perspective (only from a display 
> > perspective) is needed for backwards compatibility.
> 
> This is probably the most important point from a technical view.  
> Implementing the proposal means that there will either be a dissociation 
> of selectElement.options order from the display order (which means, for 
> example, that if you simulate the down arrow key, you do not necessarily 
> wind up at the next point in the options array), or that the 
> selectElement.options order must be constantly rejuggled as the display 
> statistics change and cause the displayed options to be reordered.
> 
> I'm inclined to say that the latter option (of selectElement.options 
> being reordered each time selection stats change sufficiently) is 
> preferable so that the model (DOM) reflects reality.  Of course this is 
> only relevant when javascript is interacting with the select element. 
> Consider, for example, where two elements are selected in a 
> selectElement (say, the 2nd with a shift key) so that all in between 
> elements should be selected.  Under the first scheme, this is difficult 
> to impossible.
> 
> When javascript is not active, then any selected element will submit to 
> the server whatever it would have submitted to server before statistical 
> rejuggling (ie. backwards compatible in the absence of javascript).  If 
> the option of frequency rejuggling is not turned on, then it is again 
> backwards compatible.
> 
> So it should be clear that the UA cannot implement this on its own 
> because the UA cannot determine that there will be no javascript 
> interaction with a select element.  That is to say, the web page 
> implementor must let the UA know that it is OK to reorder the select 
> element.

I think your conclusion is backwards.

Rather than saying:

   to implement this options would have to be rejiggled ->
       browsers implementing this would mean options rejiggled ->
           scripts would break ->
               browsers can't implement this

I think the line of reasoning should be:

   browsers implementing option rejiggling would break scripts ->
       options can't be rejiggled

This still lets browsers implement the rendering-level tweaks that 
improve the user interface, without having to affect the page.


> > Doing the transform on the server would also work, though it would be 
> > a horrible idea in general.
> 
> Yes, this does not belong on the server.  It's a lot of information 
> flowing back and forth between the server to no good end.  It also means 
> that the benefit is only available on a per site basis, which means 
> adaption would be very slow.
> 
> > (What other users select may or may not correlate with your own 
> > desires well enough to break the natural ordering -- that is something 
> > an author really ought to determine by hand.)
> 
> Of course if this were to be implemented server side, it would imply 
> being done on a per user basis.

I agree that doing this server-side is also not ok.


> Ian Hickson has written:
> 
> >  This seems like something the user agent could do on its own without 
> > help from the page,
> 
> As discussed above, the UA cannot uniformly do the SELECT element 
> rejuggling when there is javascript interaction with the SELECT element.  
> However, since it's impossible to know whether this would happen, the 
> page must let the UA know.

Or, the UA could simply not jiggle the options in the DOM.


> There is an alternate approach.  The UA could assume that there is no 
> javascript interaction of any select element, and then if there is, it 
> would revert the affected select element to the standard behaviour and 
> not engage in reordering. This standard reverting could be overridden by 
> the frequencyLimit setting.

If we assume the DOM isn't affected, then I don't see any problems 
blocking browser implementations here, nor any need for the attribute.


> > or that the server could do on its own without help from the client. 
> > I'm not sure that the language needs to be adjusted to support this 
> > idea.
> 
> The server could implement this, but it's a massive hit, both in terms 
> of development (ie. needs to be repeatedly independently developed) and 
> bits flying across the internet.  And takeup would be VERY slow.

I agree that the server shouldn't be involved.



In conclusion, this still seems like something a browser could implement 
independently of the page. This would improve all pages, not just the ones 
using the feature. Thus, I have not added this to the spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'