Created attachment 139175 [details] Sample that reproduces the bug When an element has the "hidden" attribute, it will be visible if a matching CSS rule includes the "display" property. Example: <!doctype html> <html><head><title></title></head> <body> <style> p { display: inline-block; } </style> <p hidden>Blah</p> </body> </html> In WebKit nightly & Chrome Canary, the text "Blah" is visible. I believe it should be hidden. If I remove the "display" line, it is hidden as expected.
Curious why HTML5 adds new presentation information to markup. > I believe it should be hidden. Could you please elaborate why it should be hidden? It's easier to people reading the bug if they don't have to redo the research you already did.
From the spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-hidden-attribute): "User agents should not render elements that have the hidden attribute specified." In the example I gave, I'd expect the paragraph to be hidden because the hidden attribute is on the element itself, and the CSS rule applies to all <p> elements. The hidden attribute should take precedence, just like if I put "display: none" in the element's style.
The rendering section suggests hidden="" is equivalent to "display: none", not "display: none !important": http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#hidden-elements So I think our behavior matches the spec.
(In reply to comment #3) > The rendering section suggests hidden="" is equivalent to "display: none", not "display: none !important": > > http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#hidden-elements > > So I think our behavior matches the spec. But wouldn't the attribute be considered more specific? If I replace: <p hidden> with <p style="display:none"> then the element is hidden. If hidden is supposed to be the same as "display: none", then I'd expect those two things to behave the same.
The specificity of [hidden] is {0,0,1,0}, whereas the specificity of style="display:none" is {1,0,0,0}. So no, there's no reason to expect those to behave the same way.
You're right, the current WebKit behaviour appears to match the wording of the spec. I don't think it *should* behave that way, but this is the wrong place for discussion.