W3C home > Mailing lists > Public > www-style@w3.org > April 2015

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

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 8 Apr 2015 13:58:06 +0200
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Peter Krauss <ppkrauss@gmail.com>, "www-style@w3.org" <www-style@w3.org>
Message-Id: <04872269-5D75-4F05-B949-CEC6A4766D5E@rivoal.net>
To: Reece Dunn <msclrhd@googlemail.com>

> On 08 Apr 2015, at 13:29, Reece Dunn <msclrhd@googlemail.com> wrote:
> 
> 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.

In the case where you're doing the initial computation of styles,
you were going to walk the entire DOM anyway.

But consider this:

 <style>
 #foo { color: pink; }
 </style>
 <div><span id=foo></span></div>
 <!--[... insert arbitrarily large content here,
 which may or may not contain elements with id=foo ...]-->
 <p id=foo>

Now suppose some javascript comes along and removes the span. If id selectors
match all elements with the id, then no style recomputation will be needed.
If the span had siblings, these could be affected, but everything would be
limited to the div's subtree anyway. (Relayout may be needed, but that's another story.)

If id selectors match the first id only, you have to go over the whole DOM
again. You can build accessory data structure to speed this up, but shifting
complexity from time to space doesn't remove it.

 - Florian
Received on Wednesday, 8 April 2015 11:58:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC