W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2012

[Bug 19159] allow use of hidden for tab panels

From: <bugzilla@jessica.w3.org>
Date: Fri, 05 Oct 2012 19:18:07 +0000
Message-Id: <E1TKDPT-0000gx-94@jessica.w3.org>
To: public-html-bugzilla@w3.org

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

> "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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:34 UTC