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

Re: Use the role-attribute instead of predefined class names

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Sat, 07 Apr 2007 23:54:45 +0900
Message-ID: <4617B0B5.3080703@students.cs.uu.nl>
To: Matthew Raymond <mattraymond@earthlink.net>
CC: public-html@w3.org
Matthew Raymond schreef:
> Laurens Holst wrote:
>   
>> Matthew Raymond schreef:
>>     
>>>    Personally, if we're moving everything to XML, I don't see the point.
>>> You can just use attributes and elements from a new namespace. The
>>> |role| attribute just shift semantics to a lower structural priority
>>> (from elements and attributes to attribute values).
>>>       
>> In case of <section>, the advantage is in my opinion that instead of the 
>> fact that it’s a section being implicit (like in <article>, <nav>, etc), 
>> it’s good to have it explicitly being a section, and then specify the 
>> type of section on the role attribute, as a means of sub-classing it. 
>>     
>
>    First of all, an element specific attribute makes just as much sense
> in this case because you don't necessarily want "section types" defined
> on other elements.
>   

I agree. The predefined classes are also different per element, doing 
effectively this, and I would also see the ‘role’ attribute like so. 
However, I think it makes sense to generically name this attribute 
‘role’ throughout the specification, and not to trying to create a 
differently named attribute where they effectively are doing the same 
thing. E.g. like ‘type’ is also an attribute used in more than one 
location… Although that may be a bad example, given that it’s not 
consistently used for the same kind of thing :), sometimes a MIME type 
and sometimes an input type, etc.

>    Secondly, using attributes for "subclassing" can be a descent into
> madness:
>
> | <div role="section article">...</div>
> | <role="div section article">...</>
>   

That’s taking it too far obviously. The section types have in common 
that they’re all sections. Div doesn’t really mean anything. A role 
element means even less than div. I think you can hardly call it 
‘subclassing’ at that point.

I don’t think the argument that ‘subclassing’ is a bad idea just because 
you can do it wrong is a very good one.

>    Furthermore, not having elements means that if we want to add
> attributes to a specific kind of "section", we have to put them on the
> root element and instruct user agents to ignore the attributes for other
> types. Also, without elements we can't impose any logical structural
> restraints on the markup with regard to "sections".
>   

I don’t think such restraints are necessary. And even if they were, I 
don’t think having it as an attribute would prevent you from doing so.

>> The way it is currently, which elements are exactly section types and 
>> thus how they interact with headings is extremely unclear to me.
>>     
>
>    I don't see how this is a problem. We can just define certain
> semantics as applying to a group of elements rather than one. However, I
> would be content to see the use of <h> limited to being inside <section>
> elements specifically, in part because I prefer to have <section>
> defined as a "section of an article" rather than a section of the document.
>   

You can define it, yes. However, what I’m saying is that the current 
interaction of all the various types of sections and headings makes it 
very unclear to me, it is too complex.

>> Then again, I suppose it would depend on the exact definition in the 
>> specification. If e.g. non-namespaced values were reserved for the HTML 
>> specification, and authors were discouraged to invent any new role 
>> attributes individually and to use the class attribute instead, I think 
>> that problem might be avoided.
>>     
>
>    The web page can't break when an unknown role pops up, especially if
> new roles for HTML are defined at a later date and markup with these new
> roles are viewed by a older user agent that supports roles. Therefore,
> requiring that authors, and vendors for that matter, not invent their
> own roles is pointless. They'll do whatever they want, and we'll be back
> at square one.
>   

Maybe. Is this stopping you from adding new type attribute values to the 
input element? No.

Role just needs to be defined so that it’s very clear that it’s not an 
equivalent of the class attribute.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.


Received on Saturday, 7 April 2007 14:56:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:42 UTC