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.<div><br></div><div>Like João said the order should be defined as the order of the class content attribute.<br>
<br><div class="gmail_quote">On Tue, Jun 9, 2009 at 16:00, João Eiras <span dir="ltr"><<a href="mailto:joaoe@opera.com">joaoe@opera.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ensuring consistency between browsers, to reduce the likelihood that any<br>
particular browser's ordering becomes important and then forcing that<br>
browser's ordering (which could be some arbitrary ordering dependent on<br>
some particular hash function, say) into the platform de facto.<br>
<br>
This is similar to what happened to ES property names -- they were<br>
supposedly unordered, UAs were allowed to sort them however they liked,<br>
and now we are locked in to a particular order.<br>
<br>
</blockquote>
<br></div>
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.<br>
It would also make implementations much simpler and sane, and would spare extra cpu cycles by avoiding the sort operations.<br>
</blockquote></div><br><br clear="all"><br>-- <br>erik<br>
</div>