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



On 7/11/13 7:47 PM, "François REMY" <francois.remy.dev@outlook.com> wrote:

>> [Sylvain noting that <label> state inheritance and
>> a :contains-focus pseudo-class would be better
>> solutions to some of my use-cases]
>
>I totally agree with you. Meanwhile, they represent a class of problems
>that cannot be solved efficiently right now and could benefit from lazy
>rules.

The point Boris and I are making is that the most efficient solution for
the main use-case (labels) does not require slow selectors at all.

> 
>
>
>>>[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.
>>
>> Not quire sure how we make things faster by having hover apply/ignore
>> entire
>> sets of rules based on yet another timer in the system.
>
>When you move the mouse, the selectors containing :hover have to be
>reevaluated very frequently. If you look at the last selectors, they're
>actually very slow to update because they can be applied on so much
>elements to begin with. You probably want to debounce their reevaluation.

Yes, I understand this; :hover is one of the hot-path scenarios which make
these new selectors too expensive for the fast profile. You therefore
assume there may be a 'safe' 'reevaluation' interval that makes them
affordable in this scenario. Except the shortest affordable interval will
depend on a variety of factors I.e. it's not a known fixed quantity that
the UA or the author can easily and reliably estimate. And whether the
actual runtime interval is in fact short enough for a quality user
experience is largely a function of the design. A 200ms delay on a 100ms
transition would be painful in many cases.

Also, as Boris points out, much of the cost may lie in what you call the
'reevaluation' I.e. your assumed solution may well derive from a mental
model that's not quite aligned with implementation reality.

>
>>>
>>> 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) ~ li:hover { opacity: 0.6; }
>>> }

Received on Friday, 12 July 2013 03:02:07 UTC