[whatwg] Select element suggestion
Ian Hickson
ian at hixie.ch
Sat Nov 29 13:26:52 PST 2008
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list