A fieldset is :valid when none of its controls is invalid

[jdalton]

Tooling update

Rebased onto merged #212 as one commit. Sources and tests use .mts, Node tests use Vitest, and the published JavaScript paths stay unchanged. The original engine changes are preserved.

Local lint, formatting, Node and packed-package checks pass. All 41 WPT pages pass against both generated builds.

Change

Summary

:valid decides a <fieldset> by asking whether it contains a :valid descendant. The rule is the other way round: a fieldset is valid when none of its controls is invalid, which is a different question whenever a fieldset holds no validation candidates at all.

Such a fieldset currently matches neither :valid nor :invalid, so it falls out of both halves of a stylesheet that uses them.

The two shapes where the difference shows, and what browsers answer

<fieldset id=fsempty></fieldset>
<fieldset id=fs disabled>
  <input id=fi1>
  <fieldset id=fsin><input id=fi3></fieldset>
</fieldset>

fsempty has no controls, and fsin sits inside a disabled fieldset, so every control under it is barred from constraint validation. Chromium matches both with :valid. Before this change the engine matched neither, because neither contains a control that is itself :valid.

Where browsers implement it

Blink answers true for a fieldset's validity pseudo-classes and then loops its controls, failing only on one that is a candidate and invalid, in html_field_set_element.cc#L108. :valid is that pair of checks together, in selector_checker.cc#L2811.

The spec text is :valid, which says a fieldset matches when all of its descendant controls satisfy their constraints — a condition an empty fieldset meets.

The change is one character of logic: the engine already had s.first() and already compiled a :invalid resolver, so asking for the absence of an invalid descendant costs nothing new.

References: the spec, the browser source, and what each part was reasoned from

This patch applies to master on its own. The sixteen in this series were checked by cherry-picking them onto master one after another, in this order and in reverse, and all sixteen land without a conflict.

• Spec: selector valid — a fieldset matches when all of its controls satisfy their constraints.
• Chromium: html_field_set_element.cc#L108 — the loop that fails only on a candidate that is invalid.
• Chromium: selector_checker.cc#L2811 — :valid as the pair of checks.
• MDN: :valid.

[jdalton]

This one sits with #190 and #191 and #193, which touch the conformance fixes found by comparing against Chromium.

They do not depend on each other. All seventeen in the series cherry-pick onto master in any order, and I checked that in both directions, so any one of these can land alone. The order below is the one they read best in:

• #190 makes :enabled the complement of :disabled, fieldsets included.
• #191 anchors the :required and :optional tests, and lets :optional take a button.
• #192 makes a fieldset :valid when none of its controls is invalid.
• #193 makes every built-in element :defined.