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

About "what is *fast*?"

It is not about personal/subjective "preferences" or "visions",
is about compare an "optimized to fast profile" algorithm,
with a non-optimized (complete profile) algorithm... This comparison is
objective (!).
Of course, we are talking about a fast profile with the "good ID" aditional
constraint.

PS: to create a confortable "referencial image", you can imagine/think two
references,
  * benchmarks: cheap tablet or cheap smartphone running big pages in a
popular browser.
  * complexity: an algorithm that use of fast getElementById() (with hash
or lookup tables),
      and online strategies, https://en.wikipedia.org/wiki/Online_algorithm



2015-04-08 8:58 GMT-03:00 Florian Rivoal <florian@rivoal.net>:

>
> > 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