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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 11 Jul 2013 16:28:50 -0700
Message-ID: <CAAWBYDDJcxHty58a89MmUis8HCA-8sF2FdMh-P10j7XnagU7oQ@mail.gmail.com>
To: www-style list <www-style@w3.org>
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.  Being able to use them in JS
is great, but it's really annoying that we can't do so in normal CSS.

The question then is how we can mitigate the problem that is currently
preventing us from using them in normal CSS.  The issue is that the
new selectors are too slow to reasonably run as often as we run other
selectors, so an obvious solution is to allow their use in some way
that indicates they're not run as quickly as other selectors.

Now, what we need use-cases for is to help decide which solution along
this vein might be useful.  The two solutions we've gotten for
evaluation so far are:

1.  Add a new at-rule, perhaps named @defer, which contains style
rules.  Within an @defer block, the "complete" Selectors profile can
be used.  Browsers are allowed to run deferred styles slowly; they're
not required to match as quickly as possible, like they do with other
style rules.  For example, a browser may choose to evaluate them every
250ms.

2. Add a new at-rule, perhaps named @defer, which contains style
rules.  Within an @defer block, the "complete" Selectors profile can
be used.  Deferred style rules are *not* applied by the browser
automatically at all.  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; when this is done, the set of elements that
receive those styles is "frozen" until the next request.  I guess the
method would return a promise that accepts when the layout is done,
and browsers should be allowed to respond to the request at their
leisure, coalescing multiple requests into one (to prevent authors
from spamming the request too quickly and thus negating the whole
point).

What are the use-cases for "slow selectors", how well are they
addressed by either of these two solutions, and is there anything
better we could do?

~TJ
Received on Thursday, 11 July 2013 23:29:37 UTC

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