This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html Multipage: http://www.whatwg.org/C#the-hidden-attribute Complete: http://www.whatwg.org/c#the-hidden-attribute Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: More a request than a bug report. Posted from: 84.220.208.48 by master.skywalker.88@gmail.com User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36
What are the current & expected behaviors from user agents in case of @hidden? Is it equivalent to CSS{display:none}, from a presentational point of view? Will it be overridden via style properties also in the future, as it is now in all major browsers? And what about other UAs, e.g. screen readers? Thank you.
(In reply to Andrea Rendine from comment #1) > What are the current & expected behaviors from user agents in case of > @hidden? Is it equivalent to CSS{display:none}, from a presentational point > of view? Yes. > Will it be overridden via style properties also in the future, as > it is now in all major browsers? Yes, just like <p> being a block can be overridden by author styles. > And what about other UAs, e.g. screen readers? What about them, exactly?
(In reply to Ian 'Hixie' Hickson from comment #2) I think the answer has already arrived with your previous statements. Anyway, what happens (what is expected to happen now and in future) when screen readers encounter a @hidden element with nothing else to change its behavior? Do they read it? And what if the @hidden element has a CSS rule in the style sheet which overrides the attribute for presentational ways? i.e. <p id="test" hidden="hidden">This paragraph is meant to be hidden</p> and, in CSS, #test {display:block;} Will the sentence be read in an aural UA?
Screen readers and aural UAs aren't special, they'd just do the same as visual UAs. If they support CSS, and the CSS says display:block, then it'd be read; if they don't support CSS, or if the CSS is left at the default for hidden="" (display: none), then it wouldn't.
This also makes things clearer about aural UAs mechanics. Info about this are confused in articles and full of "I think that...". Thank you.
If there's anything I can add to the spec to make this clearer, please let me know.
(In reply to Ian 'Hixie' Hickson from comment #6) Perhaps only a slight change in a sentence could do it. E.g.: "User agents should not render elements that have the hidden attribute specified." -> "unless the rendering behavior is influenced by style sheet, thus making the element visible though it is still irrelevant as a content". As a side note, one of my uses for @hidden is in some specific cases with heading graphics consisting mainly of an important text. Sometimes I can't afford the risk of a title not showing if background presentational images are not loaded. Then I couple the text with a <img> arranged in a personal way: a transparent GIF with the text in the @alt attribute, width and height set to 0 and @hidden (both for semantics and for another purpose). The stylesheet then makes the text invisible (via css{visibility} for the container) and applies styles to the transparent GIF, including display, dimensions and the proper graphics as background. If images fail, the @alt shows at least the lost text. If the CSS loading fails for any reason, then the image disappears and the text is conveyed by the now-visible text node. The behavior of @hidden about which I requested ensures that an aural user agent failing to load CSS reads the text only once (i.e. the text node).
Yeah, adding a note in the hidden="" attribute's section is probably warranted, since this indeed causes come confusion.
Checked in as WHATWG revision r8295. Check-in comment: Add a note about hidden='' and CSS http://html5.org/tools/web-apps-tracker?from=8294&to=8295