[whatwg] Predefined classes are gone
ian at hixie.ch
Tue Aug 7 23:51:23 PDT 2007
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:
> 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:
> «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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg