W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2015

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 6 Jan 2015 23:29:01 +0000 (UTC)
To: Florian Rivoal <florian@rivoal.net>, Ryosuke Niwa <rniwa@apple.com>
Message-ID: <alpine.DEB.2.00.1501062303280.6681@ps20323.dreamhostps.com>
Cc: whatwg@whatwg.org, Boris Zbarsky <bzbarsky@MIT.EDU>
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.


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


> that this cannot be expressed by css selectors otherwise

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.


> and taking IE’s behaviour as evidence of a lack of widespread compat 
> issues

How recent is IE's behaviour?


> I suggest making this propagation of the :hover and :active state 
> between label and labeled control bidirectional for both :hover and 
> :active.

On Mon, 10 Nov 2014, Florian Rivoal wrote:
> > On 10 Nov 2014, at 16:38, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
> > 
> > On 11/10/14, 9:23 AM, Florian Rivoal wrote:
> >> that authors occasionally ask for by the ability to style the label 
> >> based on the state of the labeled control
> > 
> > "The label", or "the labels"?
> > 
> > The problem of "hover the control if the label is hovered" is simple: 
> > the label already has a reference to the control it's labeling; when 
> > an element enters hover state you at worst have to deal with one other 
> > element (plus their ancestors) entering hover state.
> > 
> > And even that gets a bit complicated given the "ancestors" thing.
> > 
> > The backreference, however, is a one-to-many relationship, which makes 
> > things quite complicated, or fairly slow, or both, when multiple 
> > labels label the same form control.  So I would be a bit careful here.
> 
> You’re right, the relation is one-to-many, making the cost in this 
> direction greater than in the other one.
> 
> That said, the labeled control also maintains a list of references to 
> the associated labels, so there is no particular difficulty involved in 
> finding them.
> 
> Also, while the relationship is indeed one-to-many, I expect that this 
> is actually fairly rare for controls to actually have several, let alone 
> many associated labels. Even when they do, it should be even more rare 
> for these labels to have long ancestor chains that don’t merge quickly, 
> and when they do merge the walk up the dom can be cut short, as there’s 
> no need to continue if you find an ancestor that already has the state 
> marked as on. Turning it back off is probably a bit more involved at the 
> point where the ancestor chains merge, but this already has to be solved 
> to deal with the label's and the control’s ancestor chains merging, and 
> I don’t think going from 2 to n changes the nature of the problem.
> 
> All in all, while I agree this is potentially slower, I don’t think it 
> will be significantly different in anything but pathological cases. Or 
> am I missing a common pattern involving a control with many labels in a 
> deeply nested dom, with mostly distinct ancestor chains?

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?

On Fri, 14 Nov 2014, Ryosuke Niwa wrote:
> 
> Indeed.  It appears to me that this use case can be solved by the 
> proposed :has() relational pseudo class as long as the author has 
> structured so that the label is an ancestor of the input control it’s 
> associated with: http://dev.w3.org/csswg/selectors4/#relational

It's even simpler than that. If you limit yourself to containment rather 
than the for="" attribute, then you can just do:

   label:hover input { ... }


On Sat, 15 Nov 2014, Florian Rivoal wrote:
> 
> There’s two problems with that:
> 
> * You constrain the markup beyond what html normally allows to be able 
> to achieve some specific styling effects
> 
> * the :has() pseudo class is not part of the so called fast profile, 
> which means that by spec, CSS implementations must not support it (the 
> DOM query() method should).

On Thu, 27 Nov 2014, Florian Rivoal wrote:
> 
> 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.

 
> Since you raised specific concerns about performance, Microsoft, who 
> already implements this, went through their bug database to check: 
> “there is not a single bug filed against IE regarding performance issues 
> by tying the the label to the labeled control”.

Different vendors have different thresholds for performance concerns.


I haven't added this, since two vendors here raised some concerns and 
there doesn't seem to be a strong use case or much demand. It can be 
somewhat trivially worked around using some script or by constraining the 
markup appropriately.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 6 January 2015 23:29:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:32 UTC