Re: 'role' should be property

On 5/31/07, Maciej Stachowiak <mjs@apple.com> wrote:

I'm personally not in favor of either the role attribute in markup,
> or a hypothetical role CSS property.
>
> But either way, a discussion here about what to add to CSS will have
> no effect on what the CSS working group actually does, and is better
> taken up with them.
>
> Regards,
> Maciej


I am wholeheartedly against putting "role" anywhere other than in the markup
(except possibly the RDF suggestion, even though web authors will never use
RDF that way if at all).

"role" should be in the markup because it further specifies the meaning of
an element.  "role" should have different semantics than "class".

>From reading various threads about "role" it appears that there are various
ideas about what "role" is and what it should mean.  Here's my opinion:

- "role" should not be a substitute for existing elements: use the proper
elements instead.
- if a use case for "role" is very common, may that role should warrant its
own element
- "class" exists for authors to make up their own class names to serve as a
hook to scripting and styling.  "role" shouldn't be used for this purpose
- "role" should be like "rel".  It should have a predefined set of values
where authors can suggest additions.  A UA may provide extra functionality
for a "role" the way it does for rel="next", etc.  If authors make up new
values, they assume the risk that the UA may assign some functionality to
this in the future in addition to or in lieu of functionality the author
provides with scripting and styling.
- the best example I've seen for "role" so far is "copyright".  The role of
"copyright" can be played by various elements, but "copyright" itself may
not deserve its own <copyright> element.

I'm I on par with everyone's idea of "role"?

-- 
Jon Barnett



-- 
Jon Barnett