Basically, should hidden="" behave like display:none, or should hidden="" behave more like <input type=hidden>?

This is already clearly defined in the specification.  Specifically, http://dev.w3.org/html5/spec/single-page.html#hidden-elements defines a CSS rule:

  [hidden] { display: none; }

that http://dev.w3.org/html5/spec/single-page.html#the-css-user-agent-style-sheet-and-presentational-hints says is:

  expected to be used as part of the user-agent level style sheet defaults for
  all documents that contain HTML elements.

Then http://www.w3.org/TR/CSS21/cascade.html#cascade defines how this interacts with other CSS rules.

In particular, the TF's conclusion seems to be the exact opposite of what the spec says right now, and of what UAs which implement @hidden interoperably implement.  A testcase is at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1815 and renders identically in Presto, Gecko, and WebKit.  Trident does not seem to support @hidden at all (tested IE9 and IE10).

As an implementor, I would object to breaking web compat and compat with other implementations here by changing the behavior.

(In reply to comment #1)
> should hidden="" behave like display:none, or should hidden=""
> behave more like <input type=hidden>?

It would appear from the first link Boris provided (http://dev.w3.org/html5/spec/single-page.html#hidden-elements) that <input type="hidden"> and @hidden have the same default CSS rendering:

{
  display: none;
}

(small quibble: there is no hidden="" in HTML5 that I am aware of)

***

(In reply to comment #2)
> This is already clearly defined in the specification.  

Except, since that part of the spec was written, other aspects of the spec have changed, and specifically that @hidden content won't be hidden to all, but rather just most: the content will continue to be exposed to the Accessibility APIs via ARIA, and thus NOT hidden to Screen Readers and other tools or user agents that support ARIA. http://www.w3.org/html/wg/wiki/ChangeProposals/AllowAriaReferHidden

(I note that the section of the spec covering @hidden still states "if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers." which I believe is not actually true anymore. - http://dev.w3.org/html5/spec/single-page.html#the-hidden-attribute)

Despite some protestations, this was adopted by this Working Group, and subsequently the rules have changed. To date {display: none;} has also been processed by Screen Readers as content that "isn't there", but the Decision for Issue 204 changed that: content that is @hidden will still preserve and convey semantic structure to ARIA aware tools and those accessibility APIs. It would seem then that instead it will now be much closer to {visibility: hidden; height:0; width:0; overflow:hidden;}

Yes? No? Maybe?

If yes, it would appear that another bug needs to be filed against the parts of the spec that Boris referenced, to bring them in-line with the Issue 204 decision.


From the same links Boris provided, a hint to the answer posed by Michael:

   "What happens if the author changes to display:block but leaves @hidden set?" 

...can be found with this statement: "The user agent is expected to force the 'display' property of noscript elements for whom scripting is enabled to compute to 'none', irrespective of CSS rules." - that last part seems to indicate (at least to me) that in the case of conflict, the HTML attribute's "display rules" trumps any other CSS declaration supplied by the author (manually or via scripting). If this is correct, it should likely be better reflected in the spec.

(In reply to comment #3)
> Except, since that part of the spec was written, other aspects of the spec have
> changed, and specifically that @hidden content won't be hidden to all, but
> rather just most: the content will continue to be exposed to the Accessibility
> APIs via ARIA, and thus NOT hidden to Screen Readers and other tools or user
> agents that support ARIA.
> http://www.w3.org/html/wg/wiki/ChangeProposals/AllowAriaReferHidden
> 
> (I note that the section of the spec covering @hidden still states "if
> something is marked hidden, it is hidden from all presentations, including, for
> instance, screen readers." which I believe is not actually true anymore. -
> http://dev.w3.org/html5/spec/single-page.html#the-hidden-attribute)

If the hidden attribute is only for user agents that don't access the document using the Accessibility APIs does aria-hidden cover the Accessibility APIs? Like you discuss here [1]?

If so, then the Strong Native Semantics section [2] might need an update as well because right now the hidden attribute implies aria-hidden set to "true". Which doesn’t seem right if aria-hidden is for the Accessibility APIs and the hidden attribute is for everyone else.

But even if the relationships between display:none, hidden, and aria-hidden was cleared up I still think it would be a much better solution to use CSS media types for this. If I wanted to hide something from a screen reader I would use this (or similar):

@media speech {
  #example {
    display:none;
  }
}

But that would require that all user agents / ATs to use the media type that you would expect it to use.

[1] http://john.foliot.ca/aria-hidden/
[2] http://dev.w3.org/html5/spec/single-page.html#sec-strong-native-semantics

(In reply to comment #3)

> (small quibble: there is no hidden="" in HTML5 that I am aware of)

You link to it yourself:

> http://dev.w3.org/html5/spec/single-page.html#the-hidden-attribute)

> Yes? No? Maybe?

The spec says "User agents should not render elements that have the hidden attribute specified." and the rendering section says display:none.

>    "What happens if the author changes to display:block but leaves @hidden
> set?" 

Then it overrides the declaration in the rendering section but the requirement "User agents should not render elements that have the hidden attribute specified." still applies.

> ...can be found with this statement: "The user agent is expected to force the
> 'display' property of noscript elements for whom scripting is enabled to
> compute to 'none', irrespective of CSS rules." 

What the spec says about <noscript> has no relevance at all to hidden="".

(In reply to comment #5)
> (In reply to comment #3)
> 
> > (small quibble: there is no hidden="" in HTML5 that I am aware of)
> 
> You link to it yourself:
> 
> > http://dev.w3.org/html5/spec/single-page.html#the-hidden-attribute)

Correct, and that sections states that @hidden attribute is a boolean attribute where it's presence indicates "true" and its absence is the equivalent of "false". 

However it is never written as hidden="true/false" (as the HTML5 attribute), thus the small quibble.


> 
> The spec says "User agents should not render elements that have the hidden
> attribute specified." and the rendering section says display:none.
> 
> >    "What happens if the author changes to display:block but leaves @hidden
> > set?" 
> 
> Then it overrides the declaration in the rendering section but the requirement
> "User agents should not render elements that have the hidden attribute
> specified." still applies.

We seem to have arrived at the same conclusion, but for different reasons.

> 
> > ...can be found with this statement: "The user agent is expected to force the
> > 'display' property of noscript elements for whom scripting is enabled to
> > compute to 'none', irrespective of CSS rules." 
> 
> What the spec says about <noscript> has no relevance at all to hidden="".

(again, there is NO hidden="", it is @hidden, as in <div hidden id="ScreenReadersOnly">Only for screen reader users</div>. This may seem to be a pedantic observation, but can we as experts at least get things correct? Thanks)

I was focused on the final part of that statement: "...irrespective of CSS rules", which led me to conclude that the stronger semantic of "hidden" will continue to apply, and that "the user agent is required to force" that concept.

To be very clear, I have never been a supporter of this idea, but given that it has been adopted, I am working in good faith to get it right for all users, disabled or otherwise. If Opera and Mozilla are now concerned that this is introducing a number of rendering and interop/compatibility issues, the next step is to ask the Chairs to re-open Issue 204 based on that new evidence and ask to have the decision overturned. 

I for one would not oppose that effort.

(In reply to comment #4)
> 
> If the hidden attribute is only for user agents that don't access the document
> using the Accessibility APIs does aria-hidden cover the Accessibility APIs?
> Like you discuss here [1]?

In my opinion, there should be an exact 1-to-1 mapping between the 2 attributes (including rendering rules), but as @required and aria-required="true" shows us, that is not always the case today:
http://john.foliot.ca/required-inputs/

David Bolter (Mozilla) made what I consider a reasonable case for why this is the way it is, which I can accept given the uneven progress of the 2 attributes. 

As David noted however, both @required and aria-required="true" mapped back to the identical Accessibility API in Firefox, and that it was only the visual rendering that was different.  

With the decision on Issue 204 however, the WG has reversed even that emergent precedent, as now @hidden will NOT map to the same state as aria-hidden="true" with regard to the Accessibility APIs.

> 
> If so, then the Strong Native Semantics section [2] might need an update as
> well because right now the hidden attribute implies aria-hidden set to "true".
> Which doesn’t seem right if aria-hidden is for the Accessibility APIs and the
> hidden attribute is for everyone else.
> 
> But even if the relationships between display:none, hidden, and aria-hidden was
> cleared up I still think it would be a much better solution to use CSS media
> types for this. If I wanted to hide something from a screen reader I would use
> this (or similar):
> 
> @media speech {
>   #example {
>     display:none;
>   }
> }
> 
> But that would require that all user agents / ATs to use the media type that
> you would expect it to use.

...and that we had strong support for that CSS, both from the browsers as well as the screen readers. (It would require, for example, that Braille output devices also adopt the speech rules, which I believe is a reasonable position, but one outside of the browser-vendors normal reach)

(In reply to comment #2)
> This is already clearly defined in the specification.  Specifically,
> http://dev.w3.org/html5/spec/single-page.html#hidden-elements defines a CSS
> rule:
> 
>   [hidden] { display: none; }
> 
> that
> http://dev.w3.org/html5/spec/single-page.html#the-css-user-agent-style-sheet-and-presentational-hints
> says is:
> 
>   expected to be used as part of the user-agent level style sheet defaults for
>   all documents that contain HTML elements.
> 
> Then http://www.w3.org/TR/CSS21/cascade.html#cascade defines how this interacts
> with other CSS rules.
> 
> In particular, the TF's conclusion seems to be the exact opposite of what the
> spec says right now, and of what UAs which implement @hidden interoperably
> implement.  A testcase is at
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1815 and renders
> identically in Presto, Gecko, and WebKit.  Trident does not seem to support
> @hidden at all (tested IE9 and IE10).
> 
> As an implementor, I would object to breaking web compat and compat with other
> implementations here by changing the behavior.

Boris, what would you think about shifting the rule to be "display: none !important;"?  Whenever I've used hidden, I've put that rule in my stylesheet, because otherwise I have to code defensively to avoid "un-hiding" things accidentally.

(In reply to comment #7)
> (In reply to comment #4)
> > 
> > If the hidden attribute is only for user agents that don't access the document
> > using the Accessibility APIs does aria-hidden cover the Accessibility APIs?
> > Like you discuss here [1]?
> 
> In my opinion, there should be an exact 1-to-1 mapping between the 2 attributes
> (including rendering rules), 

The PF don't like when the HTML Working Group (re)defines things for them. Hence I'm not sor sure that there should be a 1-1 mapping. It is even so that aria-hidden="" is not completely defined yet. And as you have pointed out, @hidden is boolean, ulike @aria-hidden. (PS: If you write <p hidden> then it will typically become <p hidden=""> in the DOM.)

(In reply to comment #8)
>
> Boris, what would you think about shifting the rule to be "display: none
> !important;"?  Whenever I've used hidden, I've put that rule in my stylesheet,
> because otherwise I have to code defensively to avoid "un-hiding" things
> accidentally.

But isn't this what the Issue 204 decision wants to do? To "un-hide" the semantic structure under certain conditions (when referenced by an ARIA attribute) so that the structure and content remains intact and "rendered" by a speech synthesizer?

Right now, {display:none;} and {display: none !important;} are respected by screen readers (as it maps as such to the AAPI). This also brings back the question of what/how ARIA aware screen magnifiers are supposed to process this content?

(In reply to comment #10)
> (In reply to comment #8)
> >
> > Boris, what would you think about shifting the rule to be "display: none
> > !important;"?  Whenever I've used hidden, I've put that rule in my stylesheet,
> > because otherwise I have to code defensively to avoid "un-hiding" things
> > accidentally.
> 
> But isn't this what the Issue 204 decision wants to do? To "un-hide" the
> semantic structure under certain conditions (when referenced by an ARIA
> attribute) so that the structure and content remains intact and "rendered" by a
> speech synthesizer?

What Tab suggested only relates to whether an author would be able to do

   foo[hidden]{display:block} /*Current*/

or if the author would have to do

   foo[hidden]{display:block!important} /*The result of Tab's proposal*/

> Right now, {display:none;} and {display: none !important;} are respected by
> screen readers (as it maps as such to the AAPI). This also brings back the
> question of what/how ARIA aware screen magnifiers are supposed to process this
> content?

A screen magnifier that insists on making the ARIA semantics available to its user, would probably have to use foo[hidden]{display:block!important}. And this would work fine in the typical cases.

But note that ARIA allows you to point to for example <script> or <meta>, which could be situated inside the <head>. I think it is unlikely that screen magnifiers would be able to make such elements visible. But ARIA still allows it to be done.

(In reply to comment #11)
> What Tab suggested only relates to whether an author would be able to do
> 
>    foo[hidden]{display:block} /*Current*/
> 
> or if the author would have to do
> 
>    foo[hidden]{display:block!important} /*The result of Tab's proposal*/

Really, what I'm suggesting is that the following code:

.foo { display: block; }

should *not* accidentally un-hide a <div class=foo hidden> element.  Right now, it does, which means you have to code your selectors pretty defensively.

So yes, in order to un-hide a hidden element through pure CSS, you'd just have to be pretty explicit and use an !important rule to do it.

(In reply to comment #0)

> is @hidden equal to display:none? What happens if the author changes to
> display:block but leaves @hidden set? 
> 
> In discussion, the group concluded that the spec should say explicitly that
> @hidden trumps all CSS. Regardless of what changes are made to CSS for an
> element, all the processing requirements for @hidden elements remain in effect.
> For CSS changes to have any impact, the author would have to remove @hidden.

The hidden (sic!) issue here ie @hidden's mapping to ARIA-hidden="true", which
causes AT to not 'see' an element such as <foo hidden
style="display:block">Text</foo>.

If we stopped linking hidden="" to aria-hidden="true", then the hidden issue
would go away as making the hidden="" elements visible would also render them
to AT. Such a change would also 'pave the way' for allowing hidden=" to be used
for tab panels - see bug 19159. I don't know what the A11Y experts feel about this.

If we contineu to link hidden="" to aria-hidden="true", then I agree with Tab
that it could make sense to use [hidden]{display:none!important} in the user
agent CSS, to make it more difficult to accidentically make hidden content
visible.  Such a change would also be a step towards what the A11Y telcon
concluded, I think.

(In reply to comment #7)
> With the decision on Issue 204 however, the WG has reversed even that emergent
> precedent, as now @hidden will NOT map to the same state as aria-hidden="true"
> with regard to the Accessibility APIs.

Do you mean in general or when building the description for aria-describedby?

Note that @hidden being implemented simply via the UA style sheet for CSS-supporting UAs and the style being display:none; (or display:none !important;) does not mean the data behind @hidden could not be used in a context other than the CSS viewport & a11y API view corresponding to what’s in the CSS viewport. That is, it could still be defined that descriptions rendered outside the CSS viewport would not be hidden by display:none;.

Precedent:
EPUB3 Navigation Documents use @hidden to hide navigation data when the Navigation Document is rendered as book content in a CSS viewport but still show the data when the navigation data is rendered in the Reading System UI outside the “principal rendering”: http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-xhtml-nav-def-hidden

(For the aria-describedby case, consider the hypothetical Voice Over view of the description NOT a “principal rendering” per the EPUB terminology.)

For browser context precedent of having a case where AT exposure applies without CSS boxes:
The tree rooted at <canvas> is defined to be exposed to AT even though it has no CSS boxes (and display: none; means no CSS boxes).

FWIW, I think it’s a bad idea to make @hidden have CSS rendering effects that don’t fully follow from its CSS-expressible characteristics. We really don’t need more non-CSS rendering directives in the Web platform. Trying to make @hidden override explicit CSS-based contradictions is, IMO, in the same bad department of speccing as HTML4 trying to suppress empty paragraphs.

In other words, I think <div hidden style="display: block !important;">This should render in a CSS view port.</div>

See also the thread beginning with http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037905.html

Sorry for the lag here: I wasn't getting bugmail for a while there, so was unaware of this conversation.

Trying to answer the questions asked of me in some order:

1)  Making things with @hidden "display: none ! important" in the UA stylesheet would mean web pags cannot override the display at all, ever.  Which is suboptimal, possibly.  It would also, at least in the case of Gecko, require either accepting a small performance hit on every pageload because the selector "[hidden]" would be matched against every single element or building entirely new styling machinery for this one attribute, neither one of which fills me with glee.  But we could manage that, perhaps.

2)  I believe, though I could be wrong, that the accessibility model exposed by Gecko is based on the CSS box model.  No CSS box (e.g. display:none) means no accessible object.  Hence the observed display:none behavior.  I have no idea to what extent this is true for other browsers nor how difficult it is to change in Gecko.

3)  In general, adding one-off exceptions to CSS processing carries a very heavy implementation burden due to the complexity it causes.  Absent extremely strong justification, I would be opposed to adding such exceptions.

4)  <div hidden> and <div hidden=""> and <div hidden="hidden"> all behave identically.

5)  I would very very strongly prefer that whatever we decide to do here is done via defining styles on elements with the "hidden" attribute set instead of defining new magic.  See item 3.  What those styles should be obviously depends on the exact desired semantics of @hidden...

(In reply to Boris Zbarsky from comment #16)

> 2)  I believe, though I could be wrong, that the accessibility model exposed
> by Gecko is based on the CSS box model.  No CSS box (e.g. display:none)
> means no accessible object.

That's correct for WebKit, AX API, and (IIRC) most other platforms, so this is a non-issue for accessibility, as long as the UA has a default rule implemented via display:none.

when @hidden is present it is equivalent to what happens in the platform accessibility API with display:none in all test cases I have run. This means the element and its descendants are hidden from the the accessibility tree.

I have not tried: Making things with @hidden "display: none ! important"

The use of aria-hidden is such that if it is applied on Mac OSX and IE the corresponding accessible objects are not exposed. Firefox will expose the accessible object but it will expose the hidden attribute in the accessible object attributes. They do this as they are concerned that some authors will hide objects that they should not.

The JAWS screen reader will treat objects with the Firefox accessible object attribute as hidden (aria-hidden="true") as missing from the accessibility tree. 


Ric

Please see my plan for resolving this bug in this email:

http://lists.w3.org/Archives/Public/public-html-a11y/2013Nov/0050.html

There have been no objections to my proposed resolution, so:

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: No spec change.
Rationale: http://lists.w3.org/Archives/Public/public-html-a11y/2013Nov/0050.html

In PF discussion today, the issue is that an author could do this: 

[hidden] { 
  display: block !important;
}

So therefore:

<el hidden> would be displayed, but still mapped to aria-hidden="true", which would result in content that is accessible to everyone except assistive technology users. (weak or strong mapping is irrelevant; both result in the same outcome)

The resolution should potentially include:

1. Make it an author error/warning to override the CSS display of elements matching [hidden] in such a way that it "unhides" the content.

2. Make the @aria-hidden weak mapping to @hidden only apply to the rendered display outcome of the element with all CSS rules applied. (e.g. <el hidden style="display:block"> would not map to aria-hidden="true")

James,

I think (2) is preferable to (1); the mapping of hidden="" should fall out of its implementation as [hidden] { display: none; }. If an author overrides that implementation by styling hidden="" elements to be visible, those elements should not continue to map into A11Y API as if they were still hidden.

I was thinking both 1 and 2 should apply, but could live with your edit. Others in PF felt more strongly that there should be a warning or error when authors overrode the 'hidden' semantic.

Can you clarify your objection to making it an author error/warning to diplay content marked as [hidden]?

s/could live with your edit/could live with what you've described in comment #22/

(In reply to James Craig from comment #23)
> I was thinking both 1 and 2 should apply, but could live with your edit.
> Others in PF felt more strongly that there should be a warning or error when
> authors overrode the 'hidden' semantic.
> 
> Can you clarify your objection to making it an author error/warning to
> diplay content marked as [hidden]?

Per HTML5 it is already an authoring error to make an element with the @hidden attribute visible. Citing the NOTE i HTML51: 

“Authors therefore have to take care when writing their style sheets to make sure that the attribute is still styled as expected.”

http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-hidden-attribute

(In reply to Leif Halvard Silli from comment #25)

> Per HTML5 it is already an authoring error to make an element with the
> @hidden attribute visible. Citing the NOTE i HTML51: 
> 
> “Authors therefore have to take care when writing their style sheets to make
> sure that the attribute is still styled as expected.”

That's a note, not a normative statement. To the author "as expected" could mean, "I do expect it to be visible even though it's marked as hidden." The PF members were asking for this to throw an error or warning even if that's what the author expected/intended.

(In reply to James Craig from comment #26)
> (In reply to Leif Halvard Silli from comment #25)
> 
> > Per HTML5 it is already an authoring error to make an element with the
> > @hidden attribute visible. Citing the NOTE i HTML51: 
> > 
> > “Authors therefore have to take care when writing their style sheets to make
> > sure that the attribute is still styled as expected.”
> 
> That's a note, not a normative statement. To the author "as expected" could
> mean, "I do expect it to be visible even though it's marked as hidden." The
> PF members were asking for this to throw an error or warning even if that's
> what the author expected/intended.

(FWIW, I pondered citing the preceding paragraph, but cited the NOTE since the word "authors" occurred there.)

It is a note. But is not a "non-normative note". It is an explanation of the preceding non-note paragraph, which describes what @hidden is to be used for. I can hardly see that it is in line with the described purpose to render elements with @hidden visible. 

Perhaps the PF wants something that can be *validated*? If so, then I see two problems:
 1) UAs are not *required* to implement the semantics of @hidden via CSS;
 2) markup validators are not known for throwing errors or warnings for incorrect use of CSS;

(In reply to Leif Halvard Silli from comment #27)
> (In reply to James Craig from comment #26)
> > (In reply to Leif Halvard Silli from comment #25)
> > 
> > > Per HTML5 it is already an authoring error to make an element with the
> > > @hidden attribute visible. Citing the NOTE i HTML51: 
> > > 
> > > “Authors therefore have to take care when writing their style sheets to make
> > > sure that the attribute is still styled as expected.”
> > 
> > That's a note, not a normative statement. To the author "as expected" could
> > mean, "I do expect it to be visible even though it's marked as hidden." The
> > PF members were asking for this to throw an error or warning even if that's
> > what the author expected/intended.
> 
> (FWIW, I pondered citing the preceding paragraph, but cited the NOTE since
> the word "authors" occurred there.)
> 
> It is a note. But is not a "non-normative note". It is an explanation of the
> preceding non-note paragraph, which describes what @hidden is to be used
> for. I can hardly see that it is in line with the described purpose to
> render elements with @hidden visible. 


One of the normative statements:

> User agents should not render elements that have the hidden attribute specified. 

...would then be in violation with the current implementations, which allow this content to be rendered via author styles. If this is a normative statement, why not add the !important directive to avoid the cases listed in comment #12?


> Perhaps the PF wants something that can be *validated*? 

The members of PF are usually happy with statements that can be interpreted unambiguously, whether or not they are easy to validate with an automated script. Automation would be ideal, but not required.


> If so, then I see two problems:
>  1) UAs are not *required* to implement the semantics of @hidden via CSS;

True.

>  2) markup validators are not known for throwing errors or warnings for
> incorrect use of CSS;

Also true.

(In reply to James Craig from comment #28)
 
> One of the normative statements:
> 
> > User agents should not render elements that have the hidden attribute specified. 
> 
> ...would then be in violation with the current implementations, which allow
> this content to be rendered via author styles. If this is a normative
> statement, why not add the !important directive to avoid the cases listed in
> comment #12?

1) It is a “should”. Not a ”must”. 

2) Above you said you agreed to the idea that a visible <el hidden> would *not* map to aria-hidden="true". If so, why is it important to hide it with !important? It seems to me that “strong” authoring error is more important if CSS visibility does *not* affect the mapping to aria-hidden="true".

> > Perhaps the PF wants something that can be *validated*? 
> 
> The members of PF are usually happy with statements that can be interpreted
> unambiguously, whether or not they are easy to validate with an automated
> script. Automation would be ideal, but not required.

It is was interesting to read Henri’s words in comment #14 about how, in epub, a section with @hidden can still be viewed, when read in a "non-default" mode.

I think that one option could as well be to say that it is *not* an author
error to make hidden visible.

Perhaps @hidden should only relly mean that the element *defaults* to be hidden? That would be an unambiguous thing/statement, would it not?

The epub example is an example of non-JS interactivity in combination with @hidden. Clearly, the main idea with @hidden is that one can remove the attribute via JavaScript. But what when non-JS means (that does not remove the attribute) makes it visible?

Really, it would be a good idea to first implement the idea that a visible <el hidden> does not map to aria-hidden="true" before deciding about what the authoring error eventually should be.

(In reply to James Craig from comment #23)

> Can you clarify your objection to making it an author error/warning to
> diplay content marked as [hidden]?

I think the spec is already clear on this point, and what you're asking for is actually a bug report / feature request for the W3C's suite of validator tools.

It's for the whole suite, not just the HTML validator, because of this:

foo.html:
<link rel=stylesheet href=foo.css>
<h1 hidden>hi</h1>

foo.css:
h1 {
  display: block !important;
}

So, given that (1) doesn't really apply to the spec and (2) is (or should be) captured by bug 18574, I'm restoring the original resolution of this bug.

(In reply to Leif Halvard Silli from comment #29)
> I think that one option could as well be to say that it is *not* an author
> error to make hidden visible.
> 
> Perhaps @hidden should only relly mean that the element *defaults* to be
> hidden? That would be an unambiguous thing/statement, would it not?

But as currently specified/implemented, it's too easy to accidentally override this default with an author style that provides a higher specificity. For example:

main ul.searchresults > li {
  display: table-row;
}

Would prevent [hidden] from working on those list items. Adding !important to the default UA style sheet does not prevent authors from overriding the display, it just makes it so that they are less likely to do so accidentally.

*[hidden] {
  display: none !important;
}

> Adding !important to the default UA style sheet does not prevent authors from
> overriding the display

Yes, it does.  http://dev.w3.org/csswg/css-cascade/#cascade-origin is quite clear: !important author rules override everything except values set by CSS transitions.

Or if you prefer http://dev.w3.org/csswg/css-cascade/#importance :

   User agent style sheets may also contain !important declarations. These
   override all author and user declarations.