Re: 'role' should be property

On 5/28/07, Matthew Raymond <mattraymond@earthlink.net> wrote:
>
> Dannii wrote:
> > A <roles> element or a <link rel="rolesheet"> seems to me to be a better
> > idea.
>
>    Sure, because then you could have your styling out of sync with your
> semantics. With the semantics in markup, you can bind to the markup
> itself and always know that you're binding a specific presentation onto
> a specific set of semantics. When you roll those semantics into a
> separate files, you have ensure that both files use the same selectors
> to keep the two in sync. In the former scenario, you could have a
> dedicated person specialized in CSS who handles styling and a second
> person who specializes in HTML. In the latter scenario, you have one
> person who does BOTH presentation and semantics so that the selectors
> are kept straight between files, and maybe a separate person who does
> structural HTML markup. Thus you have altered the traditional division
> of labor.


This has nothing to do with presentation at all. You have one person who
does semantics  and structure, as it is now, except they have an extra
option for specifying custom semantics to use if they like. Yes they would
have to learn selectors as you mention later, but selectors aren't very
complicated, and if they're making up new custom semantic roles then I'd
presume they're pretty competent already.

> It would allow you to specify the default roles of various
> > elements and collections of elements, rather than repeating that
> > information a hundred times or more (depending on your page it could be
> > this many). And you could use any class or ID to specify them, removing
> > any issues with defined class names. An individual element's role
> > attribute could be used to override the default roles.
>
>    Considering you have to have something to select via W3C Selectors,
> wouldn't you just be repeating a class name in the markup instead of a
> role name? Is saying |class="tree"| and then having ".tree {role: tree}"
> in a separate file that may fail to load better than just |role="tree"|,
> or |class="tree"| with some means of specifying a microformat to
> associate with the class name? To me, it doesn't really sound like it
> saves much effort, and it requires the HTML author to learn Selectors
> just to add semantics to their own markup.


I'm thinking more of roles with the complexity level of hcalendar. You could
easily have 50 calendar events on a page. Instead of marking up the same
class names/roles on each hcalendar, you could just set a single class to
the container of the hcalendar, and specify the rest in a rolesheet.

> People have said that having external rolesheets is a bad idea, but
> > isn't this what we already have, except that instead of having them on
> > your site, they're internal to the user-agent and based of the HTML
> > spec?
>
>    So we need external stuff because we have native, internally
> implemented stuff?!?... Wha?!!


We don't need anything. But we could have it.

> User-agents will already have some sort of system to understand
> > the semantics of a page, they could then augment that on a per-page
> > basis based on the rolesheet, rather than based on individual elements'
> > role attributes.
>
>    I think you're being a little too presumptuous about browser
> architecture. I can easily see scenarios where role sheet implementation
> would be non-trivial, especially for non-CSS user agents.


Selectors aren't too complicated... but I'm suggesting this mostly from a
author's point of view. If selectors are too hard to implement, then maybe
the Selectors API WG should make it easier.