Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
On 07 Jan 2015, at 00:29, Ian Hickson i...@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
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
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 bzbar...@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
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
On 10 Nov 2014, at 15:23, Florian Rivoal flor...@rivoal.net wrote: I suggest making this propagation of the :hover and :active state between label and labeled control bidirectional for both :hover and :active. On 10 Nov 2014, at 16:38, Boris Zbarsky bzbar...@mit.edu wrote: 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. On 14 Nov 2014, at 21:34, Ryosuke Niwa rn...@apple.com wrote: I don’t find it compelling to natively support this behavior in the browser. 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. 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”. I also made a test case with a silly amount of labels plus some nesting. I am running IE(10) in a VM, and there’s no noticeable delay. http://jsbin.com/juzusopapu/1/watch?html,css,output Out of people who explicitly gave opinions, Google (Tab Atkins), Microsoft (Greg Whitworth), and Fantasai were for it, while Mozilla (David Baron Tantek Çelik) were fine with in. No one raised objections. - Florian
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
On 14 Nov 2014, at 21:34, Ryosuke Niwa rn...@apple.com wrote: On Nov 10, 2014, at 2:48 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/10/14, 5:31 PM, Florian Rivoal wrote: 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. The difficulty is not finding them. The difficulty is efficiently updating hover state on the set of ancestors of all the nodes involved, some of which might still be in hover state when the control ceases to be. 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 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). - Florian
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
On Nov 10, 2014, at 2:48 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/10/14, 5:31 PM, Florian Rivoal wrote: 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. The difficulty is not finding them. The difficulty is efficiently updating hover state on the set of ancestors of all the nodes involved, some of which might still be in hover state when the control ceases to be. 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 Given that, I don’t find it compelling to natively support this behavior in the browser. - R. Niwa
[whatwg] relationship between labeled control and label for :active and :hover pseudos
: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, that authors occasionally ask for by the ability to style the label based on the state of the labeled control, that this cannot be expressed by css selectors otherwise, and taking IE’s behaviour as evidence of a lack of widespread compat issues, I suggest making this propagation of the :hover and :active state between label and labeled control bidirectional for both :hover and :active. - Florian
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
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. -Boris
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
On 11/10/14, 5:31 PM, Florian Rivoal wrote: 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. The difficulty is not finding them. The difficulty is efficiently updating hover state on the set of ancestors of all the nodes involved, some of which might still be in hover state when the control ceases to be. and when they do merge Detecting that things merge is ... not that fast. Not if you have to do it in realtime as the mouse moves, and have to do it pairwise on a bunch of nodes at once. All in all, while I agree this is potentially slower, I don’t think it will be significantly different in anything but pathological cases. Unfortunately, browsers have to be fast on pathological cases too, in practice. :( -Boris
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
On 10 Nov 2014, at 16:38, Boris Zbarsky bzbar...@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? - Florian
