HTML5 hidden Attribute
HTML5 has given us some simple but incredibly useful HTML attributes: placeholder, download, and autofocus to name few. Another new attribute is the hidden attribute. When applied to an element, the hidden attribute acts very much like CSS' display: none; the element disappears from view and its dimensions collapse. It's as simple as:
<div hidden>
You can't see me!
</div>
If a given browser didn't support this attribute, you could likely style it via:
*[hidden] { display: none; }
So why use the hidden attribute? It's more semantically correct and should more efficiently aid screen readers. You'll even save a few characters on the display:none CSS!
![Interview with a Pornhub Web Developer]()
Regardless of your stance on pornography, it would be impossible to deny the massive impact the adult website industry has had on pushing the web forward. From pushing the browser's video limits to pushing ads through WebSocket so ad blockers don't detect them, you have...
![Animated 3D Flipping Menu with CSS]()
CSS animations aren't just for basic fades or sliding elements anymore -- CSS animations are capable of much more. I've showed you how you can create an exploding logo (applied with JavaScript, but all animation is CSS), an animated Photo Stack, a sweet...
![Using jQuery and MooTools Together]()
There's yet another reason to master more than one JavaScript library: you can use some of them together! Since MooTools is prototype-based and jQuery is not, jQuery and MooTools may be used together on the same page.
The XHTML and JavaScript
jQuery is namespaced so the...
![MooTools, Mario, and Portal]()
I'm a big fan of video games. I don't get much time to play them but I'll put down the MacBook Pro long enough to get a few games in. One of my favorites is Portal. For those who don't know, what's...
AAaaaand moving presentation back to the HTML aren’t we.
“Hidden” has more meaning than visual presentation on a screen; think screen readers.
The hidden attribute has become extremely useful for us not only for accessibility, but automating quality assurance testing as well.
The argument can be made for presentation, but it’s more a notion of states for objects/elements – and states can’t reside in the presentation layer alone.
The checkbox element is a fair example. While the “checked” attribute clearly has a visual affect on a checkbox, the fact it has states that makes it much more meaningful.
It’s not presentation, it’s not just visually hidden. For all intents and purposes it temporarily removes and element from the document.
How is this more semantically correct? It’s not in my opinion.
Semantics has limitations. The question is it is needed and useful. Is it useful for objects to have states…?
It’s weird:o)
seems IE thinks it doesn’t make sense to support it
IE sense nothing, I dont understand why the hell that browser exists ?? There is only one thing i appreciate about it, and that is “we can download firefox with it” :)
And, of course, it provides much cleaner way to output displayed/hidden state of a DOM element in your templates.
As far as I understand it, screen readers don’t actually read elements set to display: none; though. Generally, if you want something hidden from view, but readable by screen readers, it’s best to have an offscreen class.
I could see using this on an element that you want to display none initially, and then remove the attribute with JS for your state change, but accessibility wouldn’t be one of the reasons to use this.
Totally kool. for people who think that this is a presentation attribute it’s totally not, because this attribute tells browsers how to render the element on page. not how to style already rendered element. So I feel hidden is now where it belongs to “element attribute”
At this time, no accessibility API will pass this on to an aural AT and there is no aural AT that would understand it in this form anyway. The API would have to reinterpret the attribute, so that ends up being absolutely no different to parsing the equivalent CSS property. The only possible future advantage for accessibility is that a change in the DOM does tend to trigger a buffer refresh more reliably than a change in the CSS part of the API.
This attribute and some other aspects of HTML5 are, at this time, more damaging to accessibility than helpful because they are not yet fit for use in the real world. Your use of the CSS property as a fall-back makes this point. Some patience and pragmatism are required with things like this.
Though I like the idea… doesn’t this fail miserably in older browsers?
e.g. when browsers see a tag or attribute they don’t understand the rule is to ignore it… thus they would ignore the attribute and show the element!
Likewise the CSS to select it relies on attribute selectors and we all know that Internet Explorer is horrible at obeying them in older versions.
I think for now I prefer my “works everywhere” version…
CSS:
.hidden{display:none;}
HTML:
[div class=”hidden”]You can’t see me right now, but if I tweak the CSS (e.g. the visual styling of the element) I can make it so you can see me[/div]
How would one replace input[type=hidden]? That doesn’t make sense.
You could argue that it’s more semantic, but then the name “hidden” is wrong. It’s the same as with b, i, u etc. tags which don’t have a semantic meaning.
Now if you say screen reader, then “hidden” is just inappropriate. Maybe “ignored” (like enabled, disabled) or anything more representation-independent would have been a better choice.
Hi This is nice, But how can we show this element? we should remove the hidden attribute or we have to add some classes.
One more question will this support for jquery :hidden Selector ?
Ah never realised that this was a new tag. Need to get properly brushed up on my HTML 5. Shall be reading around and hopefully will pick up more tips from you.
Cheers
Nicely Done.
I’d like to see some research on this about how is actually interacts with screen readers. display:none actually isn’t accessible at all (it’s removed completely), that’s why we use top:-9999px; left:-9999px for skip links.
Tim, that is the point of the display:none property/value. One of the reasons for its existence is to prevent an element from being parsed by an accessibility API and therefore reflect its visual behaviour; and this (possibly not very well conceived) attribute is supposed to be doing the same thing. Also see my earlier comment.
Do mobile websites still download the resource like when using display:none?
gr8 article, definitely a great source for all web developers out there!!
Well, ‘hidden’ attribute seems so comfortable but I still have one thing in doubt. HTMl are not always available to us because it is mixed with codings but CSS is. So, I think CSS ‘display: none’ is more useful than html5 attribute hidden. What do you say?
We already have two ways to hide objects: display=none and aria-hidden=true (the latter of which is expressly intended for screen readers). Why do we need a third?
The W3c spec clearly states the attribute should not be used for content that could legitimately be shown in another presentation — like tabs or collapsible menus. The example above already gives no indication that using the “hidden” attribute to dynamically hide content is a direct violation of the spec.
Well @webdev, the spec also says that the hidden attribute is about the state of the page:
“When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user”
For example, when you have a textarea for comments and a submit button, and the textarea is empty, the idea is to use the hidden attribute to hide the submit button (although disabling it might be a better idea in this case) because you cannot submit an empty comment.
The second part means that you may want to use the hidden attribute for things like templates (even though there’s a template tag now as well). Other uses include for example XML content embedded in the document that you access, e.g. a mini-database for suggestions or similar.
The idea of using XML in the page scares me greatly. Microsoft tried that in IE and killed it completely in IE10 https://msdn.microsoft.com/en-us/library/ie/hh801224%28v=vs.85%29.aspx (Conceptually its a bad design, if you want “external” data for the page, load some JSON instead)
I guess the question comes back to this. We already have 6 methods for hiding content with different purposes/intentions.
1.)
display:none2.)
visibility:hidden(don’t show, but still hold the space)3.)
opacity:04.)
width:0;height:05.)
aria-hidden="true"6.) and in the case of form data,
input type="hidden"I’m struggling to see what can’t be done now (without the new hidden attribute) and what problem the (not backwards compatible) new attribute solves?
Especially when now to determine if an element is *really*, *really* hidden/visible I need to run an even larger set of tests to be sure.
*[hidden] is a terrible selector, as poor browsers need to check every single DOM element.
But it is also excellent in that it fixes the problem you get when you use a framework like Bootstrap which specifies display: inline-block for buttons. Chrome (and probably other browsers) will then display the buttons even if they have the hidden attribute. The selector solves this problem.
Every selector needs to check every DOM element.
@Mathias Could you please cite a source?
I’m actually really glad to see this attribute, but I’d love to have a better support table for it over at canIuse.com or another similar resource.
The spec does a really fantastic job of explaining exactly why it’s not a presentation level attribute (“When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user. “)
“Blue” is about presentation , “This element is used for another purpose than the current purpose of this page” is client-side business logic.
“All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user”
“The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.”[1]
[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-hidden-attribute
I primarily work with ng2, tried to use this attribute on a select dropdown – option, works in chrome desktop, but not safari, or mobile chrome. [disabled] worked as a fallback.
In terms of performance, do browsers read and parse the content of the div with hidden attribute? Or do they ignore it completely?
It’s very much like
<script type="template/html">tag (but the content of the script is used for presentation somewhere else, or for storing JavaScript data).