- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 11 Jul 2013 16:28:50 -0700
- 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