On 2007-05-18 00:37:53 +0200 Ian Hickson <[EMAIL PROTECTED]> wrote: > On Thu, 17 May 2007, Adrienne Travis wrote: >> >> Is there still room for discussion regarding the /role/ attribute with >> namespacing as an alternative? A lot of us loved the IDEA of predefined >> "classes", but didn't like the idea of confusing THAT mechanism with the >> CSS class mechanism. > > I'd rather we discussed use cases first, and then tried to work out what > solutions fit those use cases. The main reason the predefined classes were > removed is that they had no convincing use cases.
But opposition would still be there even when those cases are found. Especially if A) one cannot avoid this new semantic being applied to old pages, B) authors cannot easily avoid the predefined meaning of these names when they want to. Maciej Stachowiak interestingly told the HTMLwg list that 'rel=nofollow' is a microformat. So, why not think 'microformat' in this context also? Not so much in the picking of the specific class _names_ as in how we enable their _meaning_. On the HTMLwg list it was also said by someone that Tantek's microformats are typically hierarachical - they are a whole structure of elements with spesified class names. That way their CLASSes cannot easily clash with «meaningless» class names. So hierarchy seems like an important principle. Another principle is: the author must enable it. That is also how it is with REL=nofollow - author enables it. :-) «Predfined class names» is not a insentive for an HTML author. «Accessibility» _is_. In this message, I'll refer to these (now «gone») class names as «HTML5UniversalAccess». Then to create a hierarchic «microformat», we could require that their meaning is «enabled» by simply by applying class="HTML5UniversalAccess" either on HTML, BODY, LINK or STYLE. Namespace: Since CLASS on HTML, LINK and STYLE is not permitted in HTML401, using class on any of those elements would in effect create a kind of «namespace». For use in HTML401 documents, on could permit it in BODY. HTML or BODY may seem like the most natural place for such a class. But as authors do most things that are related to class & style in the STYLE and LINK elements, putting the «trigger class» there might also be recommendable. Also: it is easy to think of other predefined class names than those that HTML5 will define. If we think «microformat» when we define the (mechanism for the) predefined class names of HTML5, then I think we can create a pattern for how authors and groups themselves can define such things in a way that can be used by UAs. PS: if «copyright» etc really even before anything has become defined, are widely used in a way that is semantically inline with how HTML5 would define the same names, then I suggest UAs enable some kind of sniffing to handle those cases when for instance «class="HTML5UniversalAccess"» is lacking (or spelled incorrectly). -- leif halvard silli, oslo www.målform.no
