- From: <bugzilla@jessica.w3.org>
- Date: Fri, 05 Oct 2012 19:18:07 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19159 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xn--mlform-iua@xn--mlform-i | |ua.no --- Comment #4 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2012-10-05 19:18:06 UTC --- (In reply to comment #3) > If CSS is disabled completely in the user agent all elements with the > hidden attribute will be displayed This is not true. In WebKit (and probably Chrome), if you disable CSS, then elements with hidden="" set will remain hidden. I would expect all UAs that have implemented @hidden to behave that way. (In reply to comment #2) > I do agree with that paragraph from the specification that there are different > kinds of hidden content. Me too. (In reply to comment #0) > the following advice and MUST level conformance requirement in regards to the > use of the hidden attribute is incorrect, a tabbed interface is not "merely a > kind of overflow presentation " a tabbed interface has distinct semantics > (role, states and properties) and interaction behaviours on all platforms. The > ability to have content only displayed on selection is a common paradigm and > useful for reducing cognitive overload especially for users with disabilities. The "displayed on selection" paradigm does not rely on display:none. What it relies on is a "for some reason, currently out of sight" behavior. @hidden enforces display:none. But not all tabbed interefaces rely on display:none. > "The hidden attribute must not be used to hide content that could legitimately > be shown in another presentation. For example, it is incorrect to use hidden to > hide panels in a tabbed dialog, because the tabbed interface is merely a kind > of overflow presentation — one could equally well just show all the form > controls in one big page with a scrollbar." > > Recommend removing the paragraph above at it provides incorrect advice and MUST > level conformance requirements for developers. I don't understand what the problem with this is. (In reply to comment #1) > Note also that its is common practice to use CSS display:none to hide tab > panels other than the selected panel in custom tba widgets. > examples: > * http://jqueryui.com/demos/tabs/#default > * > https://dojotoolkit.org/reference-guide/1.8/dijit/layout/TabContainer-examples.html > * http://yuilibrary.com/yui/docs/tabview/tabview-basic.html > > Note: CSS display:none is used by browsers to implement hidden attribute > display properties. CSS display:none is also commonly accepted and implemented > as meaning hidden from all users including AT users. While hidden="" implies display:none, display:none does not need to imply hidden="". I don't understand whey we should change that. Content that has hidden="" is hidden in all views an on all media. A danger with allowing hidden="" on every element that has display:none, regardless of the reason why it is hidden, would be that the this way hidden="" content becomes hidden also when CSS is disabled. Thus it could decrease accessibility for CSS-unsavvy usage and it could also decrease accessibilty for other media types. For example, to use hidden="" because of a need that occurred in screen media, would also hide that element in all other medias. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 5 October 2012 19:18:08 UTC