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

> I'd rather just wait until these become critical enough
> that someone wants to implement them with appropriate optimizations. [1]
> Speccing, implementing, teaching, and asking authors everywhere to use
> some kind of crazy-awkward performance hack is not imho good for the Web,
> or a good use of anyone's time.

You make that such assumption optimizations are possible to implement, and that their complexity will be worth the use-cases. Some hard stuff will remain hard forever. For sure you can just wait for devices to become increasingly fast but that feels weird to me.

Also, there's another use case Tab didn't talk about and that's the fact you can leverage that to delay the evaluation of non-critical selectors that may trigger new paintings/renderings during time-critical periods like scrolling (example: hover effects, new elements being added at the bottom of an infinitely scrollable list having an effect on siblings...).

Only the author can actually assess how delayed the execution of those selectors can be. For sure, there's still the option to leave the authors deal with those selectos in JavaScript and toggle classes on the elements that matches but it can quickly become messy.



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

Some use-cases are:


[1] !label /for/ input:focused

Modify the styling (text color) of the labels of the currently focused element. This selector will need to be reevaluated whenever the DOM change or when the focus is shifted. This can be done in a delayed fashion, people do not care about a slight delay for the color change. For now it's not possible to do in CSS because the subject selector and the reference combinators are not part of the fast profile.



[2] !ul#toc li li li li

This is actually an use-case Lea gave to me a while back. You may want to alter the style of a table of contents when its number of nested levels goes over a certain threshold (for example more from a floating aside to a block level display).



[3] drop-down menu + keyboard

To create accessible menu, you want to make sure the focused element 
make his ancestors stay displayed, so that you can use the menu using 
just the keyboard.

 .drop-down-menu> a                    { display: none }
 .drop-down-menu:any(:hover,:focus)> a { display: block }
 @defer 0ms {
    !.drop-down-menu a:focus          { display: block }
 }



[4] carousel un-hovered elements styling

In some cases, you may want to decrease the opacity of elements inside a
 carousel that are not under the mouse if there's an element inside the 
carousel that is under the mouse cursor. However, when the mouse is 
moving very fast, you may don't care about this effect; that's why you 
may want to put these selectors in a @defer at-rule and specify that the
 state should not get updated every time frame.

 ul.carousel> li { opacity: 0.9; transition: opacity 0.5s; }
 ul.carousel> li:hover { opacity: 0.99; }
 @defer 100ms up-to 300ms {
     ul.carousel:hover> li:hover ~ li:not(:hover), ul.carousel:hover> !li:not(hover) { opacity: 0.6; }
 }



[5] javascript-based pseudo-classes polyfill

Let's imagine we allow a (restricted) javascript function to be used as a test method for a custom pseudo-class. The author may acknoledge that rerunning the function everytime is not needed for his use case and can actually decrease his frame rate for no valid reason. He may want to have some control over how often his selector is being reevaluated.



Most of them are achievable through JS, but being able to put some of that burden on the browser may be great.

Received on Friday, 12 July 2013 00:40:59 UTC