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

On Thu, Jul 11, 2013 at 6:27 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/11/13 7:28 PM, Tab Atkins Jr. wrote:
>>
>> Basic issue: we've got cool new selectors in Selectors 4 (and more
>> that we'd like to add in future levels) that we aren't allowed to use
>> in normal CSS because they're too slow.
>
>
> I would like to understand clearly what we mean by "slow".
>
> Do we mean that given an element it's slow to determine whether the selector
> matches?
>
> Or do we mean that given a change to some element (e.g. attribute change or
> state change) it's slow to determine the set of elements whose style might
> have changed as a result when selectors like this are present?
>
> Or do we mean both?
>
> Or something else?

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)".

In terms of Selectors 4, it's the things that are in the complete
profile but not the fast profile.  There is a list of these features
at <http://dev.w3.org/csswg/selectors/#profiles>.

>> The issue is that the new selectors are too slow to reasonably run as
>> often as we run other
>> selectors
>
> This concept of "running" selectors confuses me.  There is no such thing as
> "running a selector" outside contexts like querySelector.   What a CSS
> implementation has to do is determine the lists of rules that match each
> node and update those lists as needed.  Which of these are you trying to do
> less often here?

Both, depending on which is the slow thing that browser vendors are
complaining about.  (I think it's usually the updating that's hard.)

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.  I
know that in reality we do more efficient things when possible,
matching selectors against individual nodes on load and then just
modifying which selectors match when things mutate.

>> Instead, we add a new function to window.CSS or
>> document.CSS or something which requests the browser to run and apply
>> the deferred styles
>
> What does that mean, exactly?  Just recompute style on everything in the
> document?  Or something else?

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.

Same thing for the #1 approach, except that instead of the author
explicitly indicating they'd like to refresh the matched-element
lists, the browser just refreshes them whenever it has a chance.

~TJ

Received on Friday, 12 July 2013 03:22:06 UTC