pub fn declarations_by_element(
css: &str,
) -> BTreeMap<String, BTreeMap<String, Specificity>>Expand description
Which properties a stylesheet sets on each bare element it names.
The blind spot declarations_by_class has by construction: it keys rules
by the classes in their selectors, so a rule carrying no class at all is
invisible to it. button { color: var(--content) } is exactly that, and it
sets the same property the generated .button does on every described act
in the app – including the tone of a destructive one, so a delete comes to
look like an ordinary button with the check reporting nothing.
Only a selector arm that is one bare compound counts: button,
button:hover, input[type="text"]. A scoped arm (.page button) reaches
the elements inside one region rather than every one of them, so whether it
lands on a described act depends on where that act is rendered, and a check
that guessed would fail correct builds. The certain case is the one this
reads.
Pair the result against classes_for_element to ask the question a
checker wants: does this element rule take a property the design system sets
on a class that element can carry.
The answer carries the strongest arm each property was set on, because the
app’s own remedy has to outrank the rule it remedies. .field does not beat
input[type="text"]: both are the app’s, both are in the same layer, and
the attribute makes the element rule the more specific of the two. A check
reading only “the app mentions this pair somewhere” waves that straight
through, which is the shape of every handoff that looked written and was
not.