921738 - hidden attribute on visible elements

Status: REOPENED

(Core :: DOM: Core & HTML, defect, P5)

Description

[steve faulkner]

This bug was filed on the HTML spec "New: The implementation symantics of the HTML hidden attribute vs CSS display:none are not clear and in fact conflict" http://lists.w3.org/Archives/Public/public-html-admin/2013Sep/0112.html

It includes a test case where a visible element has the hidden attribute set http://jsbin.com/IKohIXe/4/edit

In firefox 24 the stated issue is evident, which suggests it is an implementation bug, since content with the hidden attribute should not be visible.

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

> This requirement may be implemented indirectly through the style layer. For example,
> an HTML+CSS user agent could implement these requirements _using the rules suggested
> in the Rendering section_.

http://www.whatwg.org/html/#the-hidden-attribute

> [hidden] {
>   display: none;
> }

http://www.whatwg.org/html/#hiddenCSS (as a part of the UA style sheet).

Author styles override the UA style sheet.

Comment 2

[steve faulkner]

simply marking the bug as invalid does not resolve the issue that the defined state "hidden" and the actual state of the content marked as hidden is in conflict.

Comment 3

[steve faulkner]

It is not a requirement that user agents implement hidden through the style layer or that UAs follow the suggestion for how to implement hidden in the CSS layer.

I suggest Mozilla consider more robust methods to implement hidden.

For example: I suggest adding visibility:hidden to the UA stylesheet would make it more robust and less likely that a developer would inadvertently override the hidden attribute.

[hidden] {
display: none;
visibility:hidden;
 }

Comment 4

[Mats Palmgren (inactive)]

We're compatible with Chrome and the spec, I see no reason to change that.

I think "[hidden] { box:none; }" would probably be a better UA rule, but 'box'
will take a while to reach the stable channel (bug 917313), and then we have
to get other UAs and the spec on board with that change.

It's easy to workaround, for example:
http://jsbin.com/IKohIXe/6/edit

Comment 5

[steve faulkner]

(In reply to Mats Palmgren (:mats) from comment #4)
> We're compatible with Chrome and the spec, I see no reason to change that.
> 
> I think "[hidden] { box:none; }" would probably be a better UA rule, but
> 'box'
> will take a while to reach the stable channel (bug 917313), and then we have
> to get other UAs and the spec on board with that change.
> 
> It's easy to workaround, for example:
> http://jsbin.com/IKohIXe/6/edit

Being compatible with spec or chrome is not a particularly good reason not to change something and besides the suggested change would not make it incompatible with other browsers or the spec as there is no requirement in this case.

Deciding its an edge case that will not be a problem in practice would be a better reason.

Comment 6

[steve faulkner]

Note that as long as the hidden attribute is set the content will remain hidden in the accessibility tree even though it is visible on screen as the hidden attribute flags that content not be exposed to assistive technology regardless of CSS display value.

Comment 7

[Hixie (not reading bugmail)]

Not exposing it in the accessibility tree is the point. It's the same as stuff that's inert. If it is rendered while it has a hidden="" attribute, it's only for stylistic effect (e.g. while it fades away). The whole point of the attribute is that it isn't there, semantically. The spec explains all this, I think... if it doesn't feel free to file a bug (http://whatwg.org/newbug) for it to be explained better.

Comment 8

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.