The filter that silently did nothing

A tag filter on the site looked completely finished and did absolutely nothing. Click a category, the JavaScript ran without error, and every card stayed exactly where it was. No exception, no console warning — just a feature that was fully wired up and completely inert.

The cause was a one-line collision between the JavaScript and the CSS. The filter hid cards by setting the HTML hidden attribute, which works because the browser's own stylesheet says [hidden] { display: none }. But the cards carried their own rule — display: flex — set directly on the card class. The browser rule loses not on specificity but on cascade origin: author declarations beat user-agent declarations before specificity is even consulted (CSS Cascade Level 5). So display: flex won, hidden was overruled, and the cards refused to disappear. The WHATWG spec warns about exactly this: because hidden is implemented in CSS, CSS can cancel it.

The hardening fix is one rule — with one modern carve-out so it doesn't break hidden="until-found", which reveals content for find-in-page via content-visibility, not display:

[hidden]:not([hidden="until-found" i]) { display: none !important; }

The lesson is broader than the bug. Toggle the hidden attribute on an element that also carries an explicit display value and your own stylesheet quietly defeats you — a silent failure, the worst kind, because everything looks correct and simply has no effect. When a DOM-manipulation feature does nothing at all, suspect the cascade before you suspect your logic.

Want the full story — cascade origin vs specificity, hidden="until-found", and when the !important hammer is the wrong tool? Read the companion deep dive: The hidden attribute is a suggestion — here's how to make it a rule.