[whatwg] Predefined classes are gone

[Ian Hickson]

On Fri, 18 May 2007, Leif Halvard Silli 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.

I think it is premature to say that a a solution would be opposed when we 
don't even know what the problem is.


> Maciej Stachowiak interestingly told the HTMLwg list that 'rel=nofollow' 
> is a microformat.

Indeed it is:

   http://microformats.org/wiki/rel-nofollow


> 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. :-)

I recommend reading more on Microformats -- they're not just a general 
concept, there's a specific process involved:

   http://microformats.org/wiki/process
   http://microformats.org/wiki/introduction
   http://microformats.org/wiki/what-are-microformats


> «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.

It's not clear to me why accessibility is especially relevant here (any 
more than it is anywhere else, I mean, or any more than security, 
performance, and other concerns that underlie all design decisions).


> 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).

I don't really follow the proposal here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'