- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 11 Jul 2013 21:27:26 -0400
- To: www-style@w3.org
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? > The question then is how we can mitigate the problem that is currently > preventing us from using them in normal CSS. I would like to clearly understand the problem first, before we worry about how to solve it. > 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? > 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? -Boris
Received on Friday, 12 July 2013 01:27:55 UTC