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

Re: Getting beyond the ping pong match (was RE: Cleaning House)

From: Jonas Sicking <jonas@sicking.cc>
Date: Sat, 05 May 2007 05:47:56 -0700
Message-ID: <463C7CFC.8030408@sicking.cc>
To: Dão Gottwald <dao@design-noir.de>
Cc: "public-html@w3.org" <public-html@w3.org>

Dão Gottwald wrote:
> Jonas Sicking schrieb:
>> Dão Gottwald wrote:
>>> Jonas Sicking schrieb:
>>>> Dão Gottwald wrote:
>>>>> Jonas Sicking schrieb:
>>>>>> Maciej Stachowiak wrote:
>>>>>>> On May 4, 2007, at 9:30 AM, John Foliot - WATS.ca wrote:
>>>>>>>> One of the most exciting (to me) developments in the XHTML camp 
>>>>>>>> is the
>>>>>>>> emergence of the ROLE attribute - as it now provides a means of 
>>>>>>>> "explaining"
>>>>>>>> what something is or does... To quote the W3C spec:
>>>>>>>> "The role attribute takes as its value one or more white-space 
>>>>>>>> separated
>>>>>>>> QNames. The attribute describes the role(s) the current element 
>>>>>>>> plays in the
>>>>>>>> context of the document. <snip> It could also be used as a 
>>>>>>>> mechanism for
>>>>>>>> annotating portions of a document in a domain specific way 
>>>>>>>> (e.g., a legal
>>>>>>>> term taxonomy)."
>>>>>>>> http://www.w3.org/TR/xhtml-role/#s_role_module_attributes
>>>>>>> The purpose of the "role" attribute is addressed in HTML5 by the 
>>>>>>> "class" attribute, along with predefined classes.
>>>>>> Personally I think this was a very poor decision. The problem is 
>>>>>> that you have user names and standard names mixed in the same 
>>>>>> namespace. So there's a big risk that the user accidentally ends 
>>>>>> up marking semantic meaning to their elements simply by wanting to 
>>>>>> style them.
>>>>> Umm. You consider enriching the semantics of markup "by accident" a 
>>>>> bug, not a feature? Even if the author added class="copyright" for 
>>>>> styling purposes, what's the problem with telling the user agent 
>>>>> and thereby the user that there's copyright information?
>>>> It's fine if it happens to be the right semantic, sure. But it's 
>>>> very likely that they'll add that to elements that has an entierly 
>>>> different meaning, thereby adding the wrong semantic to it.
>>> You're sure that it would be "very likely"? My assumption is that the 
>>> hits would outnumber the false positives by far. "role", on the other 
>>> hand, would probably only be used by authors that care about 
>>> semantics and accessibility.
>> No, of course I'm not sure. But it does seem likely that it'll be 
>> wrong often enough.
> I still think it would be beneficial all in all. A prefix for predefined 
> classes would suffer from the same problem as the role attribute: most 
> authors wouldn't use it. It's also not obvious to a novice what such a 
> prefix means, or how role differs from class.

The more I think about it the less I think that the current list of 
predefined class names in the spec is a good idea at all.

The vast majority of authors is not going to look at that list. But as 
you point out many of them will probably accidentally use class names in 
that list appropriately anyway.

However wouldn't that be true for any class name? What is special about 
the class names in the list? Any semantic function that is commonly used 
on web pages will probably get a logical class name on many pages. I bet 
there are tons of pages that use "list", "headling", "navbar", "ad", 
"panel" and "group" (I made that list up by going to a site I visit 
often and looked at the various things that appeared on the front page).

We might as well periodically update 
<http://code.google.com/webstats/2005-12/classes.html> and say "look at 
that page, it's the class names people are using, the classes have the 
semantic meaning of what you'd imagine that the class name would be used 
for". That is clearly not a good idea to put in the spec and adds little 
value for anyone. But it has the same level of correctness as what the 
current list will have.

/ Jonas
Received on Saturday, 5 May 2007 12:48:02 UTC

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