Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos

> On 07 Jan 2015, at 00:29, Ian Hickson <ian@hixie.ch> wrote:
> 
> On Mon, 10 Nov 2014, Florian Rivoal wrote:
>> 
>> :hover matches on the labeled control of a label element currently 
>> matching :hover.
>> 
>> Similarly, :active interoperably matches on the labeled control of a 
>> label element currently matching :active (and 
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27247 is about reflecting 
>> that in the spec)
>> 
>> In addition, IE (tested IE10 and IE11) makes it work the other 
>> direction, making :hover (resp. :active) match on the label of a labeled 
>> control currently matching :hover (resp. :active).
>> 
>> Given that this behaviour sounds reasonable
> 
> Why does it sound reasonable? I'd argue it's the other way around. Having 
> :hover match an element that isn't being hovered is weird.

It seems no less reasonable than in the other direction, which we already have. If state is going to propagate, propagating both ways is an easier to understand model.

>> that authors occasionally ask for by the ability to style the label 
>> based on the state of the labeled control
> 
> Can you provide some pointers to such requests?

A tiny bit of googling yields these (and more):
http://stackoverflow.com/questions/4388102/can-you-style-an-active-form-inputs-label-with-just-css
http://stackoverflow.com/questions/5978239/anyway-to-have-a-label-respond-to-focus-css
http://stackoverflow.com/questions/16859542/toggling-styles-on-label-active-focus-for-input-field-with-css-only
http://stackoverflow.com/questions/3359390/how-can-i-activate-a-css-style-for-a-label-when-hovering-over-the-associated-che
http://stackoverflow.com/questions/10408068/html-label-before-input-css-inputhoverlabel

> I proposed the /.../ combinator long ago which would actually address 
> this. The idea of that combinator was that it would let you walk 
> relationships between elements. For example, we could define a "for" 
> relationship for labels and controls, so that you could do:
> 
>   input:hover /for/ label { }
> 
> ...or some such. This would be a much more generic solution.

Right, I am also pushing for this (or some alternative syntax like a functional-notation pseudo-class), and it's getting (very) mild support.
That said, /for/ takes compound selectors on both sides, making it more generic. This is good for expressivity, but likely comes with a performance cost, makes the relatively common (see above) and specialised use case of propagating :active and :hover back to the label slightly worse, not no mention more verbose.

I agree the case for this would be weaker if we had /for/, but I don't think it goes away entirely.

>> and taking IE’s behaviour as evidence of a lack of widespread compat 
>> issues
> 
> How recent is IE's behaviour?

Since IE10.

> The problem is that it requires extra cycles every single time you are 
> trying to check whether a :hover rule matches a control. If we add this, 
> then a rule like this:
> 
>  :hover { background: blue; }
> 
> ...requires O(N*M) extra cycles, where N is the number of controls in the 
> document and M is the average number of labels per control. Worst case, 
> you have to pay this cost every frame (60 times a second). It also 
> increases the size of the browsers, which means higher memory footprints, 
> more swapping, etc.
> 
> It all adds up.
> 
> Is the cost of these extra cycles on all pages worth the benefit to the 
> pages that use it?

I am not disagreeing there is a cost, but I don't believe it is large. In most cases, M will be 1 or very close to.

Also, while the argument does work for :hover, I don't think the point about 60fps is relevant for :active. You can move a cursor quickly / continuously, but activation cannot go that fast.

> If you limit yourself to containment rather 
> than the for="" attribute, then you can just do:
> 
>   label:hover input { ... }

If you have nesting, then sure. But using the for attribute is a perfectly good way to mark things up as well.

>> As selectors is a CSS topic as much as an HTML one, I brought this to 
>> the CSS working group (mailing list then telecon) for further discussion 
>> to see if its members thought this was worth pursuing or not before 
>> coming back here.
>> 
>> The group made a resolution agreeing that :hover and :active should be 
>> made to propagate bidirectionally between labels and labeled controls, 
>> as the behaviour was found useful, and the performance question not 
>> problematic.
> 
> Given that two vendors here said the performance question was problematic, 
> I question that judgement.

For Mozilla, while Boris Zbarsky did raise a concern about performance here, David Baron in the CSSWG said he had no issue with it.

For Apple, Ryosuke said (paraphrasing) "given that you can use :has(), it doesn't seem justified". But you cannot use ":has()" for selectors in CSS (see http://dev.w3.org/csswg/selectors/#profiles).

Microsoft already has it.

Google (via Tab Atkins) was explicitly in favour of both supporting this and /for/.

So the performance concern exists, but it isn't overwhelming.

As is often the case, this is not clear cut and is a matter of tradeoffs. Given that there is evidence for user demand, precedent by having it work in the other direction, and that the performance concern is not that strong, I'd lean on the other side.

 - Florian

Received on Wednesday, 7 January 2015 12:58:17 UTC