Re: 'role' should be property

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.

What this effectively creates is a 'dynamic infoset', and although
it's unlikely to appear in a 'language near you' any time soon, for
those interested in the idea I talked about it in my paper for the
W3C's Web Application Workshop, three years ago:


I looked at the issue in more detail a year later, in a blog entry
concerning the debate about using XPath as a possible CSS selector




On 22/05/07, Thomas Broyer <> wrote:
> 2007/5/22, Dmitry Turin:
> >
> > I strongly disagree to make
> > "copyright, error, example, issue, note, search, warning"
> > values of any attributes: neither 'class', nor 'role'.
> > Because it's not comfortable to specify values of attribute
> > in _many_ tags in _one_ document ('copyright' maybe exception in this list).
> >
> > I think, that "error, example, etc" should be values of [CSS] property.
> > Name of property is deal of taste, for example name can be 'role'.
> I second Patrick H. Lauke that "roles" have nothing to do with
> styling. Moreover, I strongly believe they must appear in the *markup*
> for documents to be "accessible" without the need for any external
> resource. (I'm a believer that CSS should be optional and web sites
> remain accessible without stylesheets).
> --
> Thomas Broyer

  Mark Birbeck, formsPlayer | +44 (0) 20 7689 9232 |

  standards. innovation.

Received on Tuesday, 22 May 2007 22:41:22 UTC