Make elements reflect CSS pseudoclasses on associated form element · Issue #1632 · whatwg/html (original) (raw)

There are a number of CSS pseudoclasses that reflect state of labelable elements. This includes the standard interactive pseudoclasses available on all elements (:hover, :active, :focus) and also form-specific pseudoclasses (:required, :optional, :invalid, :valid, :enabled, :disabled, :checked, :selected, :indeterminate, :default, :placeholder-shown, :in-range, :out-of-range, :read-only, :read-write).

The purpose of these pseudoclasses is to make it easy for the visual presentation to reflect the state. However, because there are only limited styling options available on most form elements, it is often desirable to convey the state by styling the label, instead, possibly using generated text content. For example, it is common to indicate a required form field with a red asterisk after the label.

Currently, in order to reflect the form element's state in the label with CSS, you must re-arrange the DOM order so that the label is a subsequent sibling in the tree (because CSS selectors only operate in tree order). For example, to create the "required" asterisk, you would need:

input:required + label::after { content: " *"; color: red; }

The HTML spec already requires that activation and hover interactions on the label should trigger the :active or :hover state on the control. However, the reverse effect only happens if the control is a descendent of the label.

In November 2014, the CSS WG resolved:

Both :hover and :active should propagate from the labeled control to the label, in addition to the other direction.

and also

reuse the hook from :active on :focus [meaning that :focus would also reflect the same relationships].

Florian Rivoal reports that this resolution stalled at the WHATWG and nothing went forward.

I would strongly urge the HTML spec to require that implementations reflect all pseudoclasses from a labelled input onto the associated label element, for the following reasons:

• It allows markup and styles to be independent; the DOM structure does not need to be constrained to allow styling.
• It encourages correct use of the <label> element, enhancing accessibility.
• It encourages correct use of form element attributes to indicate state, enhancing accessibility.
• It would reduce the use of sibling CSS selectors, which are problematic for performance; in some "checkbox hack" designs, it would reduce the number of total selectors considerably (because you wouldn't need a separate selector for each input/label pair).
• It would make developers lives much easier (once browser support catches up).

There may be reasons to make limited exceptions for certain pseudoclasses, such as :defined, where it could have a valid but distinct meaning on the label versus the control. But for the most part, the semantics of the label are the semantics of the element it describes.

Edit: On re-reading Florian's email, it seems he did not mention anything about W3C HTML WG, so I'm not sure why I was thinking he did. False claims removed!