A team hides table rows with the HTML hidden attribute, but rows carrying a class whose stylesheet rule sets display: flex stay visible. Why does hidden stop working, and what is the fix?

## hidden is a style rule, not a magic flag `hidden` is a boolean global attribute meaning "this element is not currently relevant". Crucially, browsers do not implement it with a special rendering path. They implement it in the **user-agent stylesheet**, with a rule equivalent to: ```css [hidden] { display: none } ``` That single fact explains the entire class of bugs around it. Declarations from the author origin outrank the user-agent origin, so any rule you write that sets `display` on the same element defeats the attribute: ```html <tr class="row" hidden>…</tr> ``` ```css .row { display: flex } /* author origin — wins, so the row is visible */ ``` Nothing about specificity is even needed here; origin alone decides it. The element still carries `hidden`, devtools still shows the attribute, and the row is on screen anyway. Worse, the element is now in a contradictory state: it renders, but the semantics of the attribute say it should not be perceivable. ## What hidden is supposed to mean When it works, `hidden` does more than remove pixels: - The element is not rendered at all — no box, no space reserved. - It is **removed from the accessibility tree**, so a screen reader does not encounter it. This is what makes `hidden` different from merely moving something off-screen. - It stays in the DOM, so scripts can still find it and read it. - It is a *state*, not a permanent property: remove the attribute and the element returns. Two things it does **not** do, both of which get asked as follow-ups. It does not disable anything: a form control inside a hidden subtree is still submitted with its form, because only `disabled` excludes a control from submission. And it does not cascade as an override — an ancestor being hidden hides descendants only because nothing inside a `display: none` subtree renders, not because `hidden` is inherited. ## Fixing it properly In preference order: 1. **Do not fight yourself.** Stop setting `display` unconditionally on elements whose visibility you also control by attribute. Hoist the layout `display` onto a wrapper, or apply it through a class you only add when the element is shown. 2. **Strengthen the rule in your own stylesheet.** `[hidden] { display: none !important }` near the top of the author styles is the standard defensive line, and many resets ship exactly that. It is a deliberate use of `!important` to protect a semantic guarantee, not a hack to win a specificity fight. 3. **Pick one mechanism.** Either the attribute owns visibility or a class does. Two systems both claiming to control whether something is on screen is the actual defect; the CSS collision is just the symptom. ## The until-found variant HTML also defines `hidden="until-found"`, a different state for content that should be hidden but still **discoverable**. Content in that state is not rendered, but it remains findable by the browser's find-in-page and reachable by scroll-to-text and fragment navigation. When the browser locates a match inside it, it fires a `beforematch` event and removes the attribute, revealing the content so the user lands on it. The intended use is collapsed accordions and "read more" sections, where plain `hidden` makes the text unfindable. Note that this is newer than plain `hidden` and engine support arrived at different times, so verify current support before relying on it; the mechanics also differ from plain `hidden` (`until-found` content participates differently in rendering so that it can be searched), which is another reason not to assume the two behave identically. ## The diagnosis to say out loud When an interviewer describes "the hidden attribute is not hiding anything", the expected answer is one sentence: `hidden` is a user-agent `display: none` rule, and an author rule that sets `display` on the same element overrides it. Everything else follows.