Add support for the `hidden`-attribute

[ZoeBijl]

In the past I've run into the lack of support for the hidden-attribute in SVG a few times. Today I saw a tweet that mentions this lack too. Were there ever plans to include support? And if not, are there good reasons not to include it?

[yatil]

<w3c hat off>

It seems very confusing to not allow it, especially, as outlined in the tweets above, when SVG is used inline in HTML.

[ZoeBijl]

Found the tweet in which @AmeliaBR explained why it's not in the spec.

[AmeliaBR]

This would be another case of synchronizing with HTMLElement.

One complications, is that we would need to decide precedence relative to regular presentation attributes. (CSS rules would override, same as for HTML elements.)

As I mentioned to Michiel before, I really don't see a need for a new attribute in SVG. And I find it confusing that an attribute named hidden sets display: none in the UA stylesheet, not visibility: hidden.

But it is clearly a confusion for authors who expect it to be a universal attribute.

This is especially likely if they have in the past used a compatibility rule in their stylesheet (for older browsers) that didn't distinguish by namespace: [hidden] {display: none} will affect all elements with the attribute, even SVG. Native support for the HTML attribute is now good enough that devs might be using hidden without that extra rule, and so are only now discovering that the native implementations don't include SVG.

[ZoeBijl]

Thank you for your comments Amelia. Like you said, if nothing else, this will prevent a lot of confusion.

[simevidas]

The HTML standard suggests that [hidden] { display: none } should be included in the user agent style sheet, so why aren’t browsers doing this? If they did, we wouldn’t have this problem to begin with, if I understand correctly.

[AmeliaBR]

@simevidas

Because that HTML user-agent stylesheet is restricted to HTML-namespaced elements using a CSS namespace rule:

@namespace url(http://www.w3.org/1999/xhtml);

[hidden], area, base, basefont, datalist, head, link, meta, noembed,
noframes, param, rp, script, source, style, template, track, title {
  display: none;
}

One outcome of this issue would be to add a matching rule for SVG-namespaced elements, along with the global attribute and IDL property.

[tigt]

display works as an SVG presentation attribute, right? So the question of precedence is interesting:

<g hidden display="inline">
  …
</g>

The straightforward answer is probably(?) that hidden overrides display="inline", since CSS is more specific than presentation attributes. I think this is simpler from an author perspective, since if they use a library like Normalize.css or their own styles for [hidden] { display: none }, that could produce a weird effect where the order-of-precedence differs depending on native support, especially if the author opts not to serve certain “polyfills” to newer browsers.

hidden is mostly useful for DOM scripting in my experience, where you don’t care what an element’s display value should be — you just want to toggle it on and off. This especially seems to catch SVG authors — technically display: block should result in a shown element, but but I keep getting bit by edge cases with stuff like CSS animations where it expects display: inline instead. Most show/hide snippets on StackOverflow (et al.) toggle elements between display:block/none, so I’d would like to see hidden parity between SVG and HTML to simplify future show/hide scripts.

[fsoder]

With an appropriate rule in the UA stylesheet (as "suggested" by HTML), display="inline" would override hidden in the example above because of the cascading rules [1]. It appears that current UAs [2] actually treat hidden (in HTML) as a "presentational hint" [3] though, and if hidden (in SVG) were to be implemented the same way, the above example would be sensitive to in which order the attributes were mapped (and in this particular example I believe that would lead display="inline" winning.)

[1] https://svgwg.org/svg2-draft/styling.html#PresentationAttributes [2] Blink (so quite likely WebKit too), and it looked like Gecko did. [3] https://html.spec.whatwg.org/multipage/rendering.html#the-css-user-agent-style-sheet-and-presentational-hints

[ianthedev]

Since HTML elements work with this attribute, I find it confusing that SVG elements in HTML documents don't. I personally think this attribute is useful and hope SVG elements would work with it, too.

[css-meeting-bot]

The SVG Working Group just discussed Add support for the `hidden`-attribute, and agreed to the following:

• RESOLUTION: Add a global hidden attribute to SVG with the same semantics as HTML that is expected to be implemented using UA stylesheets. Iff there is implementation commitment

The full IRC log of that discussion

<krit> topic: Add support for the `hidden`-attribute
<krit> GitHub: https://github.com/w3c/svgwg/issues/508
<krit> AmeliaBR: This is about HTML consitency. HTML element allows hidden attributes on any element that Is usually mapped to disaplay: none. It is encouraged in HTML as a way to keep semantics in the markup instead of the stylesheet.
<krit> AmeliaBR: In SVG we have presentation attributes to do this already. We didn't have a need for this attribute. But there might be confusion if we do not support it and people use it on SVG elements. Especially within CSS layout embedded in webpages/
<krit> krit: proposal is to add hidden attributes to all SVG elements? Or a list of elements?
<krit> AmeliaBR: If we add them then to all elements.
<krit> AmeliaBR: also for implementation complexity. My main concern is about wording and how it maps to display none or visibility properties. Or cascading attributes if you have this attribute and the regular presentation attributes.
<krit> AmeliaBR: Attributes have no particular order so we need to define the priority.
<AmeliaBR> HTML spec for hidden attribute: https://html.spec.whatwg.org/multipage/interaction.html#the-hidden-attribute
<krit> nzimmermann: There is a note in the HTML spec that display: block will cancel the effect of the hidden attribute. So it has precedence over the hidden attributes.
<krit> nzimmermann: So I don't think there is no issue with precedence with display or visibility.
<krit> AmeliaBR: We still need to specify how attributes affect each other in SVG because that is not defined in HTML. But I agree with your logic to overwrite hidden attributes.
<krit> nzimmermann: For authors it would make sense to have an explicit definition how attributes affect each other.
<krit> AmeliaBR: If we want to define the attributes in form of cascading it would override definition of presentation attributes. We can maybe ask for feedback from implementers what is easier to implement. And have a clear note in the spec how they relate
<krit> nzimmermann: your concern was that attribute might override UA stylesheets?
<krit> AmeliaBR: The opposite.
<AmeliaBR> `svg|[hidden] {display: none}`
<krit> AmeliaBR: The presentation attributes would be overridden
<krit> nzimmermann: you are right.
<krit> krit: what specific feedback we need from implementers?
<krit> AmeliaBR: this was specifically about cascade issues. We just need to make sure it is clearly defined.
<krit> krit: disagreement with being consistent with HTML and add hidden attributes??
<krit> krit: I need to look at it deeper. But it sounds like it is not just semantics but effects the styling
<krit> AmeliaBR: Implementation is not that complicated.
<krit> AmeliaBR: The semantic impact in fact of a11y is just coming out of the stylesheet. If I make something hidden it gets detected by accessibility software as well.
<krit> AmeliaBR: I'd like to hear implementers commitment before adding it to SVG 2 but have no concerns with adding them in general.
<krit> nzimmermann: no disagreement
<krit> Tav_: no disagreement
<krit> proposed RESOLUTION: Add a global hidden attribute to SVG with the same semantics as HTML that is expected to be implemented using UA stylesheets.
<krit> RESOLUTION: Add a global hidden attribute to SVG with the same semantics as HTML that is expected to be implemented using UA stylesheets. Iff there is implementation commitment
<krit> AmeliaBR: Who would be doing the work?
<krit> AmeliaBR: Will ask Zoe

[AmeliaBR]

@ZoeBijl, would you be interested in starting a PR for this? (It would follow an existing pattern used for e.g. tabindex, where we just reference HTML for the detailed definitions.) I'd be happy to help as needed.

[ZoeBijl]

Following the painful discussion in https://github.com/whatwg/html/issues/4904 I’m not so sure. To rephrase: I’m not sure this should be supported given the definition for the hidden attribute in the HTML spec with all the limitations that imposes.

I’ve gone from fan of the hidden attribute to thinking it’s the most useless attribute we have 🤷🏻‍♀️.

[AmeliaBR]

Hmm… hadn't seen that discussion on WHATWG HTML.

I'd still say there is a use, as an authoring convenience, to support <svg hidden> as a styling shorthand that behaves the exact same as in HTML. But if the HTML definition is under dispute, that does make it messier.

[ZoeBijl]

One use case I can think of is having a hidden SVG element with defs for icons that you link to with use somewhere down the page. I think that follows the HTML definition. But at this point I’m really not sure any more.

Under the (now defunct) W3C HTML 5.2 spec definition I would be totes in favour of this.

My aim with this issue was to reduce the confusion for authors. With the WHATWG definition I’m not sure allowing the hidden attribute will achieve that. The least we as spec editors could do is be consistent in advice. Which is also why I have already removed the hidden attribute from most APG code examples.

[thibaudcolas]

This hasn’t been discussed in a while but I thought it’d be worth following up on this thread based on a possible issue I foresee with hidden usage in CSS resets:

1. For cross-browser support reasons, a fair few CSS resets use [hidden] { display: none; } (see for example normalize.css). This means developers working with such resets are none the wiser that SVG elements lack support.
2. The introduction of hidden="until-found" (spec, Chrome Developers explainer) will likely cause a lot of those resets to reconsider the appropriateness of this now dated override, which breaks the until-found value.

If those types of widely-used resets remove their [hidden] { display: none; } overrides to support hidden="until-found", a lot more people will find out that SVG elements inline in HTML unexpectedly don’t support hidden.

---

This will be be pretty straightforward for maintainers of CSS resets and authors generally to resolve, but I thought it worth mentioning here nonetheless. I personally found out about this because Tailwind CSS removed this override from their reset for the reasons I mention above.

For context, I use the hidden attribute on SVG elements exactly as described above – to hide a "sprite" of icons as symbols, which only works thanks to the CSS resets:

<svg hidden>
  <defs>
    <symbol id="circle"><circle cx="8" cy="8" r="7" /></symbol>
  </defs>
</svg>

<svg class="inline" width="16" height="16"><use href="#circle"></use></svg>Test