W3C home > Mailing lists > Public > www-style@w3.org > July 2013

Re: [selectors] Finding a way to run "complete" profile selectors in CSS

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 11 Jul 2013 23:45:16 -0400
Message-ID: <51DF7BCC.5020603@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
On 7/11/13 11:21 PM, Tab Atkins Jr. wrote:
> Both.  More specifically, it's "anything that browser vendors have
> complained about implementing for CSS due to it being
> slow/expensive/whatever, but which are cool enough to still be worth
> speccing for qSA/etc (and which may have already led a long life in JS
> selector libraries)".

OK.  To the extent that these things are "slow" in different ways we may 
need different solutions for allowing them...

> I'm handwaving in that paragraph, alluding to the more folk conception
> of selectors and styling as involving the browser continually going
> through all the selectors and matching them against the document.

OK, no browser ever does it that way.  I think we should avoid about 
thinking about it this way, because it will lead us astray in terms of 
how we design solutions, I suspect.

> My thought for that was that, normally, the deferred styles are
> excluded from matching anything during style recalc.  When you call
> the function, the browser runs the selectors of the deferred styles to
> find the nodes matched by each, and then freezes that list - from then
> on, those selectors are interpreted as matching exactly that list of
> elements, no more and no less, regardless of what changes in the
> document.  Calling the function again refreshes this information,
> changing what elements are considered to match each selector.

I see.  This is ... pretty weird behavior if those nodes move around in 
the DOM, right?

-Boris
Received on Friday, 12 July 2013 03:45:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC