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

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

From: Timmy <timmywillisn@gmail.com>
Date: Fri, 12 Jul 2013 10:16:22 -0400
Cc: www-style list <www-style@w3.org>
Message-Id: <A80C0984-C8F0-449D-ADD5-837D90D11ED9@gmail.com>
To: Tab Atkins Jr. <jackalmage@gmail.com>
Forgive me for misunderstanding anything, but I'd like to understand the purpose of the at rule. So far, the reasons seem to be:
      
          1. To avoid blocking selectors from the fast profile as much as possible.
          2. To make it clear to the developer that using these styles comes with the caveat that they may not be fast.

Are there any reasons I've missed?

On Jul 11, 2013, at 7:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

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

	Of the two solutions, I like this one best, but I have some thoughts below.

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

	This doesn't seem like the best API to me. If the problem is that we'd like to be able to use selectors in the complete profile in CSS (rather than through QSA), you're still required to call a javascript function (i.e. the proposed .CSS) to use them? I say let's have a solution that is purely CSS.

Perhaps this was already suggested, but what about taking a queue from javascript strict mode and adding some sort of CSS statement to effectively "turn on" selectors in the complete profile? It would be a way for the developer to say that she is aware they are slower, but wants to use them anyway. Perhaps this flag could be scoped so that it could be applied only to a style element or only to a particular stylesheet.

This seems simpler to me than the deferred at rule (as styles from the complete profile can be anywhere in a user's CSS rather than separated into at rules). If any of the selectors from the complete profile get fast enough to warrant addition to the fast profile, no changes to code are necessary (they just get faster).

Just an idea.

- Timmy




Received on Friday, 12 July 2013 14:16:51 UTC

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