- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 15 Jan 2010 12:46:16 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, "Edward O'Connor" <hober0@gmail.com>, Sam Ruby <rubys@intertwingly.net>, HTML WG <public-html@w3.org>
On Jan 15, 2010, at 02:07, Tab Atkins Jr. wrote: > Like Jonas, I feel there is great value in @hidden. My reasoning is > very practictal; I want to be able to maintain the handful of CSS > hacks that *do* hide something from the visual rendering only. It's > already impossible to use display:none to hide content just from > visual UAs (leaving it for screen readers), as it is used too commonly > to indicate that the element should be hidden entirely, and so > non-visual UAs are forced to also ignore it to be useful to their > users. The CSS hacks we still have available to us are less > widespread and slightly more work, and the existence of a single, > simple attribute that can handle the "hide this element" role should > hopefully minimize the misuse of those hacks, ensuring they remain > useful for longer. The hidden attribute is *not* appropriate for the use case of hiding stuff from the visual rendering only. The hidden attribute is meant to mark a DOM subtree pruned from all presentations on all media. Hence, the hidden attribute is supposed to make it appear as though accessibility API mapping could work from the DOM without querying the computed style for the screen media and as though non-CSS HTML+JS UAs could work with Web apps. That is, the hidden attribute is a "semantic" way of saying display: none;. See: http://www.whatwg.org/specs/web-apps/current-work/#display-types -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 15 January 2010 10:47:05 UTC