Re: W3C can say (?) what an ID means to CSS4, in the fast profile context

On 8 April 2015 at 09:17, Florian Rivoal <florian@rivoal.net> wrote:
>
> (little side track, as we can't do this anyway as both you and Boris said)
>
>> On 08 Apr 2015, at 01:11, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> There's no significant speed difference between matching all elements
>> with a given ID vs matching only the first, so I don't think there's
>> really a use-case for doing this.
>
> Really? I'd think matching all elements with a given ID is actually faster
> than matching only the first, and possibly significantly so.
>
> If an ID selector matches all elements with the id, to find out if any given
> element matches you only need to consider this element in isolation, but if
> an ID selector matches only the first one, you now need to take the whole dom
> into account (or build additional data structures to keep track of the
> relevant info), making the whole thing slower, or more memory intensive of
> both. No?

Assuming that you just have the DOM data structure in memory, you have
an in-order traversal of the DOM. Match all (class) applies the
operation on any matching DOM node, whereas match first (id) stops at
the first matching node, so could be faster depending on where the id
is in the tree, but worst case you are still enumerating over the
entire DOM.

You can optimize this where as you build the DOM, you build a map of
`id => DOM node` (or `class => array of DOM nodes`). This is then a
map access, with a list traversal only in the match all case. This is
complicated by keeping the information up-to-date on JavaScript DOM
manipulations, for example if the JS adds an ID before the one you
have in the map, how do you know this?

Thus, it is easier and more reliable to just use DOM traversal --
there are less moving parts and DOM traversal applies to any selector
(you just need the match all and match first traversal operations).

Thanks,
- Reece H. Dunn

Received on Wednesday, 8 April 2015 11:29:42 UTC