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

On Thu, Jul 11, 2013 at 8:45 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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...

True, we might.  The simpler the better, of course - if a single
solution does suffice, I'd prefer it over multiple solutions that do
slightly better.  The details of why something is slow aren't
something that the average author should have to know if we can avoid
it.

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

It's only weird insofar as the styling is out of date.  It's the same
as :hover sometimes having a noticeable lag before updating, except
it's probably a somewhat larger delay.

~TJ

Received on Friday, 12 July 2013 04:48:08 UTC