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



On 7/11/13 4:28 PM, "Tab Atkins Jr." <jackalmage@gmail.com> 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.  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?

So we have two solutions and we're asking people to think of problems
they could solve?

Received on Thursday, 11 July 2013 23:41:39 UTC