Thoughts on the HTML5 hidden attribute
Last Friday Maciej Stachowiak submitted a patch for supporting the HTML5 hidden attribute in WebKit. While supporting new features the HTML5 draft specifies usually is a good thing, I’m having quite some doubts about the added value of the new attribute. Shelly Powers submitted an issue to the HTML Working Group with quite an extensive change proposal, which has led to a decent amount of discussion on the subject.
Something which undoubtedly has been affecting the discussion are the other issues opened by Powers, which propose removal of <progress>, <meter>, <aside>, <figure> and various attributes. While her rationales often are decent and complete, it’s more of less becoming a vengeance: getting anything removed from HTML5 which does not directly improve semantics or accessibility. While I disagree with removing tags like <meter>, I do believe removing the hidden attribute would be a good idea.
What exactly is the hidden attribute?
It’s one of the clearest and most straightforward definitions of an attribute available. Defined in section 8.1 of the HTML5 specification, any element which has the attribute should be considered irrelevant and thus shouldn’t be rendered by the browser. However, the specification also defines that the attribute should not be used for content that could legitimately be shown in another presentation, like tabs or collapsible menus.
Using the attribute is really simple, take the following snippet as an example:
<section hidden>
<h1>The HTML5 hidden-attribute</h1>
<p>
This text should not be displayed by a browser.
</p>
</section>
While the example could contain any element, as the hidden attribute can be applied on all HTML elements (including on <html>), I think it’s quite clear. The section, including all its contents, should not be rendered by the browser, even though it will be available in the DOM and for search engines.
The primary problems I see with the current definition of the hidden attribute are the following:
- Its purpose is going to be misunderstood — it will be abused.
When I’m thinking about use-cases for the hidden attribute, one of the first things that comes to mind is using it for tabs. Easily hide any tab which isn’t active at that very moment without having to use a CSS class like “hidden-tab”. This is, however, wrong. Tabs could be defined as a form of presentation, which specifically has been excluded by the specification as a use-case. - There are two identical alternatives available, one of which is widely used already.
The first alternative is quite clear: use a CSS class or inline style which sets the “display” property to none. The second alternative would be using the “aria-hidden” attribute, which would be identical after adding a CSS attribute-selector hiding the element. Laura L. Carlson of the Accessibility Taskforce has already replied to the proposal stating that the accessibility gains are negligible, and given “aria-hidden” takes precedence over the normal display property, using both statements could create a contradiction. Browsers could automatically assign the “aria-hidden” attribute/role to elements which are hidden if accessibility would really be an issue here. - It’s a clear layering violation.
Now that a fair number of presentational elements have been removed from HTML5, such as <u>, <font> and <center>, layering problems are becoming more visible. Layering means using HTML strictly for the content, CSS for the presentation and any JavaScript code for behavior of the page, which the hidden attribute is violating. Considering all the attribute does is setting the display property to none, the attribute barely is different from tags like <u> and <i>.
The added semantical value of @hidden
Of course, since the attribute has been accepted as a feature of HTML5, it isn’t all bad. The attribute initially was named “irrelevant” but was renamed to “hidden”, mostly because the former is unclear. Having native attributes which could be used to address accessibility is one of the more important use-cases for the attribute. Web developers are much more likely to include a “hidden” attribute, than they are to type aria-hidden=”true”. In fact, most of the developers won’t even know what aria is in the first place.
On top of that, it could be beneficial for search engines. Even today the more popular spiders, such as GoogleBot and Yahoo Slurp, do not download or parse the CSS code used on any page. Consequently, all hidden content on a page will therefore be included in the search results, which leads to less accurate search results. The text you’re searching for is not per definition visible on the page itself, it might very well be (legally) hidden using JavaScript or CSS.
Keeping the attribute in the spec, or remove it?
I personally support Shelly’s proposal to remove the hidden attribute. Even though there is a semantical improvement, mostly for applications which are not capable of parsing CSS, a possible improvement in terms of accessibility and the ease of simply hiding an element, I believe the attribute is too prone to being abused, imposes a layering violation, already has two valid and widely used alternatives and does not add sufficient value in order to be included in specification.
Furthermore, your browser does not support the attribute yet 😉