[css-selectors] :focus and :checked

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[css-selectors] :focus and :checked

Brian Kardell
People can do a lot with the 'checkbox hack' and I see designers all the time bend over backwards trying to manage this so that labels are in sibling relationships, but this is occasionally impractical or even impossible.  In other words, given


<div>
   <label for="x">Blah</label>
</div>
<input type="checkbox" id="x">

You're screwed. Labels proxy their clicks to set focus on their input or check a checkbox or select a radio button, but there's no bi-directional relationship. I know that this has come up in the past, but in the past it looks like there were mostly concerns about things like :hover[1] because of perf, or ideas that other things like subjects/reference combinators would solve the problem another way.  The latter doesn't seem like it is gonna happen soon and the former is only part of the problem - maybe the least useful one.

:focus and :checked are certainly more 'rare' events and it feels like at least maybe those we could afford to support-bidirectionally.  If developers were able to style a label when the input were :checked or :focused that seems like it would be a small, but powerful win that would open lots of new possible doors.

--
Brian Kardell :: @briankardell 
Reply | Threaded
Open this post in threaded view
|

Re: [css-selectors] :focus and :checked

Amelia Bellamy-Royds
+100

I would really, really love it if label elements matched all the form-related pseudo-classes from their associated input.  Not only :checked, but also :invalid and :required and so on.

Beyond the freedom from awkward DOM structures, it would provide another incentive for developers to actually use properly associated <label> elements, and also proper HTML form validation attributes, all of which go a long ways to improving form accessibility.

~Amelia BR



On 2 August 2016 at 13:31, Brian Kardell <[hidden email]> wrote:
People can do a lot with the 'checkbox hack' and I see designers all the time bend over backwards trying to manage this so that labels are in sibling relationships, but this is occasionally impractical or even impossible.  In other words, given


<div>
   <label for="x">Blah</label>
</div>
<input type="checkbox" id="x">

You're screwed. Labels proxy their clicks to set focus on their input or check a checkbox or select a radio button, but there's no bi-directional relationship. I know that this has come up in the past, but in the past it looks like there were mostly concerns about things like :hover[1] because of perf, or ideas that other things like subjects/reference combinators would solve the problem another way.  The latter doesn't seem like it is gonna happen soon and the former is only part of the problem - maybe the least useful one.

:focus and :checked are certainly more 'rare' events and it feels like at least maybe those we could afford to support-bidirectionally.  If developers were able to style a label when the input were :checked or :focused that seems like it would be a small, but powerful win that would open lots of new possible doors.

--
Brian Kardell :: @briankardell 

Reply | Threaded
Open this post in threaded view
|

Re: [css-selectors] :focus and :checked

Florian Rivoal-4
In reply to this post by Brian Kardell

On Aug 3, 2016, at 04:31, Brian Kardell <[hidden email]> wrote:

People can do a lot with the 'checkbox hack' and I see designers all the time bend over backwards trying to manage this so that labels are in sibling relationships, but this is occasionally impractical or even impossible.  In other words, given


<div>
   <label for="x">Blah</label>
</div>
<input type="checkbox" id="x">

You're screwed. Labels proxy their clicks to set focus on their input or check a checkbox or select a radio button, but there's no bi-directional relationship. I know that this has come up in the past, but in the past it looks like there were mostly concerns about things like :hover[1] because of perf, or ideas that other things like subjects/reference combinators would solve the problem another way.  The latter doesn't seem like it is gonna happen soon and the former is only part of the problem - maybe the least useful one.

:focus and :checked are certainly more 'rare' events and it feels like at least maybe those we could afford to support-bidirectionally.  If developers were able to style a label when the input were :checked or :focused that seems like it would be a small, but powerful win that would open lots of new possible doors.

Can we do this?

We've actually already resoled on this for :hover and :active (and transitively for :focus as well, since in the same session we resolved on having the same transitivity rules that apply to :active also apply to :focus).



But the definition of this is in HTML, not CSS, and IIRC I failed to convince the whatwg.

https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0147.html (I think there were more mails, but I cannot find them right now).

Theoretically, there's still an action on me to convince them, but I am happy to get your help on that. If revisiting the discussion in the CSSWG to get a fresh resolution would provide a better basis for arguing the case, I'm fine with doing that too.


 - Florian
Reply | Threaded
Open this post in threaded view
|

Re: [css-selectors] :focus and :checked

Brad Kemper


> On Aug 5, 2016, at 2:15 AM, Florian Rivoal <[hidden email]> wrote:
>
> But the definition of this is in HTML, not CSS, and IIRC I failed to convince the whatwg.

Why can't we just create our own independent definition in CSS for the :checked behavior, and then let WHAT change their definition to match the new reality once browsers implement it our way?
Reply | Threaded
Open this post in threaded view
|

Re: [css-selectors] :focus and :checked

Amelia Bellamy-Royds
Labels and form elements are defined in HTML, so that's the natural place to define what makes an element match a given selector.  CSS Selectors (https://drafts.csswg.org/selectors-4/#input-pseudos) specifically states that the details of which elements match which state are host-language dependent.

To continue the discussion with implementers responsible for the HTML specs, I started (at Anne van Kesteren's suggestion) a Github Issue for WHATWG.  Comments appreciated: 


In particular, feedback is needed from developers working on the CSS side of browser implementations, regarding the potential performance issues raised previously by Boris Zbarsky (https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0076.html).

~ABR

On 6 August 2016 at 11:01, Brad Kemper <[hidden email]> wrote:


> On Aug 5, 2016, at 2:15 AM, Florian Rivoal <[hidden email]> wrote:
>
> But the definition of this is in HTML, not CSS, and IIRC I failed to convince the whatwg.

Why can't we just create our own independent definition in CSS for the :checked behavior, and then let WHAT change their definition to match the new reality once browsers implement it our way?

Reply | Threaded
Open this post in threaded view
|

Re: [css-selectors] :focus and :checked

Brad Kemper

On Aug 6, 2016, at 3:27 PM, Amelia Bellamy-Royds <[hidden email]> wrote:

Labels and form elements are defined in HTML, so that's the natural place to define what makes an element match a given selector.  CSS Selectors (https://drafts.csswg.org/selectors-4/#input-pseudos) specifically states that the details of which elements match which state are host-language dependent.

I saw where it says "What constitutes an enabled state, a disabled state, and a user interface element is host-language-dependent” in the section you linked. I didn’t see anything specifically about that with regard to the checked state, or what makes :checked special compared to hover and :active and transitively :focus. What am I missing?

And anyway, Selectors 4 is a draft, which we are free to change.
Reply | Threaded
Open this post in threaded view
|

Re: [css-selectors] :focus and :checked

Tab Atkins Jr.
In reply to this post by Brad Kemper
On Sat, Aug 6, 2016 at 10:01 AM, Brad Kemper <[hidden email]> wrote:
>> On Aug 5, 2016, at 2:15 AM, Florian Rivoal <[hidden email]> wrote:
>>
>> But the definition of this is in HTML, not CSS, and IIRC I failed to convince the whatwg.
>
> Why can't we just create our own independent definition in CSS for the :checked behavior, and then let WHAT change their definition to match the new reality once browsers implement it our way?

Because we're not jerks, basically (and neither is WHATWG here).  The
previous contention was for good reasons, based on actual implementor
feedback. Those are the same implementors that read and implement
*our* specs.  The fact that the discussion happened in the HTML spec
rather than a CSS spec is irrelevant; the feature itself was
more-or-less rejected at the time.  Reopening the discussion with
changed requirements and/or data is reasonable, but it's extremely
*un*reasonable to just treat it as "nuts to y'all, CSS can do what it
wants".

If WHATWG was unreasonable or rejected it for reasons not related to
implementor concern, the situation would be different. But that's not
the case here.  This has nothing to do with venue right now.

~TJ