Note also that its is common practice to use CSS display:none to hide tab panels other than the selected panel in custom tba widgets.
examples:
* http://jqueryui.com/demos/tabs/#default
* https://dojotoolkit.org/reference-guide/1.8/dijit/layout/TabContainer-examples.html
* http://yuilibrary.com/yui/docs/tabview/tabview-basic.html
 
Note: CSS display:none is used by browsers to implement hidden attribute display properties. CSS display:none is also commonly accepted and implemented as meaning hidden from all users including AT users.

I do agree with that paragraph from the specification that there are different kinds of hidden content.

If we take the tabbed interface as an example, this does not work (as) well in situations where you have limited horizontal space like on a cell phone display. So one way to handle that could be that on a display that is big enough you get a tabbed interface but on a cell phone it would be presented in a different way where none of the content is hidden and you could reach all of it using scrolling (another way to handle overflow). Scripts are always involved when you interact with a tabbed interface so obviously they would have to detect which presentation that currently is being used so that something different (or nothing at all) is done when the “tabs” are activated on a cell phone. So it makes sense to use display:none here so that it could change using e.g. media queries on a smaller display.

There are situations where you have content that should be hidden regardless of how you present it, like a dialog box with an error message about an error that didn’t occur (yet anyway). Situations like this is what the hidden attribute is for, at least that is the way I interpret the current text in the specification. But on the other hand using display:none in all CSS media types seems to do that too. I don’t think it is clear why a document author should not just continue to use display:none for all hidden content.

I think that removing that paragraph would make it even less clear why the hidden attribute should be used instead of display:none (other other method of hiding things). I do however agree that something needs to change. Either remove the hidden attribute completely from HTML5 or add a better description about this attribute’s relationship with other methods of hiding content.

I guess that it is possible see the hidden attribute as a way to hide things without CSS. But at least according to the testing that I have done that is not the case. If CSS is disabled completely in the user agent all elements with the hidden attribute will be displayed (which makes sense because the user agent applies display:none to them).

(In reply to comment #2)
"other other method of hiding things" should be "or other method of hiding things".

(In reply to comment #3)

> If CSS is disabled completely in the user agent all elements with the
> hidden attribute will be displayed

This is not true. In WebKit (and probably Chrome), if you disable CSS, then elements with hidden="" set will remain hidden. I would expect all UAs that have implemented @hidden to behave that way.

(In reply to comment #2)
> I do agree with that paragraph from the specification that there are different
> kinds of hidden content.

Me too.

(In reply to comment #0)
> the following advice and MUST level conformance requirement in regards to the
> use of the hidden attribute is incorrect, a tabbed interface is not "merely a
> kind of overflow presentation " a tabbed interface has distinct semantics
> (role, states and properties) and interaction behaviours on all platforms. The
> ability to have content only displayed on selection is a common paradigm and
> useful for reducing cognitive overload especially for users with disabilities.

The "displayed on selection" paradigm does not rely on display:none. What it relies on is a "for some reason, currently out of sight" behavior. 

@hidden enforces display:none. But not all tabbed interefaces rely on display:none.

> "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."
> 
> Recommend removing the paragraph above at it provides incorrect advice and MUST
> level conformance requirements for developers.

I don't understand what the problem with this is.

(In reply to comment #1)
> Note also that its is common practice to use CSS display:none to hide tab
> panels other than the selected panel in custom tba widgets.
> examples:
> * http://jqueryui.com/demos/tabs/#default
> *
> https://dojotoolkit.org/reference-guide/1.8/dijit/layout/TabContainer-examples.html
> * http://yuilibrary.com/yui/docs/tabview/tabview-basic.html
> 
> Note: CSS display:none is used by browsers to implement hidden attribute
> display properties. CSS display:none is also commonly accepted and implemented
> as meaning hidden from all users including AT users.

While hidden="" implies display:none, display:none does not need to imply hidden="".  I don't understand whey we should change that.

Content that has hidden="" is hidden in all views an on all media. A danger with allowing hidden="" on every element that has display:none, regardless of the reason why it is hidden, would be that the this way hidden="" content becomes hidden also when CSS is disabled. Thus it could decrease accessibility for CSS-unsavvy usage and it could also decrease accessibilty for other media types. For example, to use hidden="" because of a need that occurred in screen media, would also hide that element in all other medias.

I think (In reply to comment #0)

> Recommend removing the paragraph above at it provides incorrect advice and MUST
> level conformance requirements for developers.

I think this is possible. But only if we remove the aria-hidden="true" mapping from the @hidden attribute.

As long as it is possible to style elements by using hidden as a selector - *[hidden]{display:block}, then some authors will do that.

The current spec text prevents it from happening too often. But if we remove that text, then it will happen often. (It might happen often even if we don't remove that text - it only takes that authors change their habits.)

Thus: I would be OK with allowing hidden="" to be used as display:none if it is made a 100% equal to display:none. But I would not be OK with  allowing hidden="" to be used as display:none as long as it has the additional semantic of aria-hidden="true".

test

Waiting for the HTML spec to be editable again...

see also 23347

Steve? Ping?

moved to https://github.com/w3c/html/issues/203