- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 9 Jun 2009 22:55:39 +0000 (UTC)
On Wed, 13 May 2009, Erik Arvidsson wrote: > > Section 2.9.3 DOMTokenList says: > > The DOMTokenList interface represents an interface to an underlying > string that consists of an *unordered* set of unique space-separated > tokens. > > > Yet, the item method says: > > The item(index) method must split the underlying string on spaces, *sort > the resulting list of tokens by Unicode code point*, remove exact > duplicates, and then return the indexth item in this list. If index is > equal to or greater than the number of tokens, then the method must > return null. > > > What is the reason for requiring the set to be ordered in item? Ensuring consistency between browsers, to reduce the likelihood that any particular browser's ordering becomes important and then forcing that browser's ordering (which could be some arbitrary ordering dependent on some particular hash function, say) into the platform de facto. This is similar to what happened to ES property names -- they were supposedly unordered, UAs were allowed to sort them however they liked, and now we are locked in to a particular order. > If we still want to enforce that item returns the items in the sorted > order we should change the spec to say that DOMTokenList represents an > ordered set instead. The spec doesn't say that DOMTokenList represents an unordered set; it says that the underlying attribute represents an unordered set. On Mon, 18 May 2009, Erik Arvidsson wrote: > > Simon, I think you have convinced me at least. I therefore think that a > better wording in the spec is to say that DOMTokenList acts as a sorted > set. I've added a note to this effect. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 9 June 2009 15:55:39 UTC