[selectors4] :for selector

[ryanve]

This is a proposal for a new :for selector applicable to <label>. Its primary use case would be to allow developers to target labels based on the state of their associated form control. It should work regardless of whether a label is associated via [for] or nesting. My initial idea was pseudo selectors like :for-checked. While I like that simplicity, a :for selector function similar to :matches seems more capable.

Proposed Syntax

:for(selector) would target labels whose associated form control matches selector

Examples

• :for(:disabled) would target labels whose associated form control is :disabled
• :for(:checked) would target labels whose associated form control is :checked
• :for(:valid) would target labels whose associated form control is :valid
• :for(:required) would target labels whose associated form control is :required
• :for(.a, .b) would target labels whose associated form control is .a or .b
• :for(.a.b) would target labels whose associated form control is .a and .b

[fantasai]

I think #397 is a better solution for this problem.

[AmeliaBR]

Copying over the comment by @Boldewyn from the duplicate issue #5240:

In 2015 I suggested on the mailing list to add a new pseudo-class :for() to address <label>s by the features of their referenced control element.

@frivoal said, that such a feature is actually planned. However, as far as I can tell from the current WD, there seems to be no motion in this particular direction. Therefore I wanted to bring it back to attention. After 5 years I still would find it tremendously helpful to style non-trivial forms. Thanks to @CarlosMadeira to poke me to write up this issue!

Back in the days I also prepared a gist to showcase the features and define the problem set, that :for() would help to address.

Copy ’n pasted description, that I posted on the mailing list:

A pseudo-class :for() can provide better control over addressing <label>
elements. Its content must be a single selector or selector list
(mirroring :not()), that is matched against label.control. The
specificity of :for() is the specificity of its arguments. Examples:

    label:for([type="text"])             /* all labels with
label.control.type === "text" */
    label:for(:invalid)                  /* all labels with
label.control.invalid === true */
    label:for(:focus)                    /* label.control ==
document.activeElement */
    label:for(:disabled):for(read-only)  /* chaining :for(): labels for
disabled read-only inputs */
    label:for(#foo)                  /* label, that refers to the input
#foo */

If a <label> has no corresponding `control`, it will never match a
:for() selector. It could be matched by :not(:for(*)).

The :for() selector does not rely on any ID reference but on the
algorithm to find the control for a label outlined in
<http://www.w3.org/TR/html5/forms.html>. In later specifications it
could be extended to also match references defined in another way, e.g.,
"reverse lookup" via aria-labelledby or a[href^="#"].

If there is anything I can do to help further this proposal (opening tickets in browser vendor bugtrackers, drafting copy for the spec, ...), I’d be glad to help.

[Boldewyn]

Thank you, @AmeliaBR!

To respond to @fantasai’s comment from 2017: Yes, #397 would address a substantial subset of the needed features. But AFAICT there are other use cases, that are not covered, because they are not bound to the state of the input. E.g., addressing all labels for some kind of currency input, :for(.our-currency-picker), or the classic “replace the checkbox” game, :for([type="checkbox"]).

[SebastianZ]

To extend on @Boldewyn's post, a function has the advantage of allowing to filter the form controls by more than their states.

The syntax for this could be:

:for([<type-selector>? <subclass-selector>*]!)

Note: This syntax does not cover the :for(.a, .b) case above. That one can simply be achieved via :for(:is(.a, .b)) or :is(:for(.a), :for(.b)).

Sebastian