[whatwg] DOMTokenList is unordered but yet requires sorting

Erik Arvidsson erik.arvidsson at gmail.com
Tue Jun 9 16:33:42 PDT 2009


I was about to follow up on this. Requiring
sorting which is O(n log n) for something that can be done in O(n)
makes thing slower
without any real benefit.
Like João said the order should be defined as the order of the class content
attribute.

On Tue, Jun 9, 2009 at 16:00, João Eiras <joaoe at opera.com> wrote:

>
>  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.
>>
>>
> I strongly think the order should not be sorted, but should reflect the
> order of the token in original string which was broken down into tokens.
> It would also make implementations much simpler and sane, and would spare
> extra cpu cycles by avoiding the sort operations.
>



-- 
erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090609/d354e043/attachment-0002.htm>


More information about the whatwg mailing list