`[hidden]` is implemented as a low-priority presentation attribute (see the
comment in layout/style/res/html.css), so any author rule setting `display`
silently overrides it. A lot of chrome/in-content CSS therefore guards
display-setting rules with `:not([hidden])` so the element still hides when the
`hidden` attribute is set.
Add a `:where([hidden]) { display: none !important }` rule to the two base
stylesheets -- global-shared.css (chrome) and in-content/common-shared.css
(in-content pages) -- so callers can set a `display` type unconditionally, and
drop the redundant `:not([hidden])` guards. `:where()` keeps the selector at
zero specificity, so the rare element that must stay shown can override it with
a plain `!important`: findbar[hidden] (slide transition), treecol[hidden] in
xul.css (column collapse), setting-control[hidden]:has(> moz-message-bar), and
the devtools toolbox webconsole/deck panels (kept laid out via visibility).
Guards are kept where the base rule can't reach: shadow-DOM widgets, the
newtab/activity-stream bundle, browser/fxr/*, and mixed-coverage sheets injected
into content documents or shadow roots (urlbar view sheets via the smartbar,
feature-callout sheets). Structural `:not([hidden])` uses (sibling/descendant
combinators) are untouched.
Also fix the moreFromMozilla QR-code box, which showed itself by setting
hidden="false". Since bug 1979014 made `hidden` a regular boolean attribute,
that value is actually hidden, so it now removes the attribute instead (and the
matching :not([hidden="true"]) CSS guards become a plain selector).
Differential Revision: https://phabricator.services.mozilla.com/D309290
Dão Gottwald
759f86dd9e