[prev in list] [next in list] [prev in thread] [next in thread] 

List:       whatwg
Subject:    Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
From:       Florian Rivoal <florian () rivoal ! net>
Date:       2015-01-07 11:06:03
Message-ID: B344CB1C-8EAC-4781-85E9-AE2436C56005 () rivoal ! net
[Download RAW message or body]


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


[prev in list] [next in list] [prev in thread] [next in thread]