- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 05 May 2007 05:47:56 -0700
- 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