[Bug 19277] Relationship and precedence of hidden="" and display:none should be clarified/defined

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277

--- Comment #29 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 10 December 2013 04:31:44 UTC