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



On 7/11/13 5:40 PM, "François REMY" <francois.remy.dev@outlook.com> wrote:
>
>
>[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.

This makes me wonder whether the feature request here is really about
propagating state from the control back to its label(s). Labels propagate
their state to the control referred to by the for attribute per HTML5; in
addition, labelable elements hold a NodeList of the labels that refer to
them. This seems useful enough that maybe it shouldn't need a complex
selector at all. 


I just don't buy any assertion that people wouldn't care unless 'slight'
is known to be very small in most cases. Quite possibly smaller in many
cases than the impact this kind of selector may have on a real world page.
It wouldn't take much of a delay for the experience to look poor.


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

Yes, general use-case for this kind of selector.


>
>
>
>[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 }
> }

Seems like #1 except we want to propagate :focus to non-focusable elements
that are not <label> I.e. markup could indicate that's desirable. Not sure
that's better but complex selectors may not be the best solution for this
pattern either.

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


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

This assumes at least two other features - hooking JS into custom
pseudo-classes as well as custom pseudo-classes - which need their own
use-cases also. 

>
>
>
>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 01:18:35 UTC