W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re: 'role' should be property

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 22 May 2007 15:52:00 -0700
Message-Id: <A430C7C3-A283-4E59-82DC-F08402F8443C@apple.com>
Cc: public-html@w3.org
To: mark.birbeck@x-port.net

On May 22, 2007, at 3:41 PM, Mark Birbeck wrote:

> Hi Thomas,
> I actually think Dmitry is exactly right.
> One is much more likely to want to say 'the third div is the footer'
> or that 'certain spans are check-boxes', than to have to put @role on
> each element. However, the ideal solution would be to have the
> capacity to to set properties on elements both directly *and*
> indirectly, the latter being done via CSS rules.
> The properties set by CSS rules are available via the DOM anyway, so
> there is nothing to say that CSS must be about styling.

CSS can't define document semantics, because it has to be possible to  
set a different stylesheet on the same document without affecting the  
semantics. Therefore a role CSS property would violate the  
architecture of CSS and the goal of separating semantics and  
presentation, even more so than presentational HTML elements.

(Side note: it's in general a bad thing to say "certain spans are  
check-boxes" instead of using <input type="checkbox">, but if you  
wanted to do that, you'd likely want a hook for styling or scripting,  
and what's most convenient for that is a class value, which really  
argues for predefined class values if you want to be able to turn non- 
checkbox elements into checkboxes for accessibility purposes.)

Received on Tuesday, 22 May 2007 22:52:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:21 UTC