[whatwg] Predefined classes are gone

[Adrienne Travis]

I understand the idea that classes were supposed to have semantics all
along -- though i don't think that idea is necessarily borne out by
the spec -- but the issue, for me, is NAMESPACING (whether formally
defined or otherwise). If i'm using class="navigation" and
class="copyright" (to use two overused examples from this long
discussion) in my projects from 2003 (before the mechanism went into
effect), i don't necessarily want parsers in 2008 to make assumptions
based on that. And there's no way to tell them NOT to.

If we could NAMESPACE the predefined class names, that'd actually
remove ALL my objections to the idea of overloading /class/ instead of
creating a new attribute (/role/ or whatever). But unfortunately, that
totally breaks backwards-compatibility if not done very carefully. (If
i declare class="dc:author" , i CAN'T address that in my stylesheet.
If the namespacing was handled with dashes, like class="dc-author",
that would work, though.)

The advantage of tying into the W3C's /role/ idea is that /role/ is
already defined to allow for explicit namespacing. But again, this
COULD, i suppose, be handled with class names, if there were an
explicit namespacing mechanism there too.

I REALLY DO like the idea of an attribute to add specified semantics
to content blocks. Let's not abandon that idea entirely!

Adrienne



On 5/17/07, Michel Fortin <michel.fortin at michelf.com> wrote:
> Le 2007-05-17 à 12:22, Adrienne Travis a écrit :
>
> > 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.
>
> Personally, I really don't like thinking of class="" exclusively as a
> mechanism to associate styles. The fact that CSS makes it easy to
> select on a class name doesn't mean that class names are targeted at
> CSS. Predefined class names made that clear, now it's less clear.
>
> While not much in favor at first, I started to like the idea of
> predefined class names after a while. What I like is that it doesn't
> try reinvent a new parallel mechanism for what class *should have
> been* from the start. I think the initial idea was that the class
> attribute would cover the the semantics while CSS the presentation of
> those semantics. The only problem is that earlier specs left those
> semantics undefined, with no way to define them unambiguously. This
> explains why many people, including some standard advocates, started
> thinking of class as a way to attach style rules of the same name to
> their elements (basically making class presentational).
>
> So either we fix class, or we create a new attribute (role) (and
> leave class as a purely presentational hook for CSS? Hurk!). The
> advantage of class is that it's a lot easier to use in CSS selectors,
> making authors more likely to use them. The advantage of role is that
> it begins in a clean state, which could mean less false-positive --
> I'm not sure this will stay true in the long run however, especially
> if people see role as "more semantic" than class and start to use it
> inconsiderably...
>
> I'd tend to think there are use cases where class is most appropriate
> and others where it'd be better to start with a clean new attribute
> (role), but that's just a general feeling based on everything I've
> seen to date.
>
>
> Michel Fortin
> michel.fortin at michelf.com
> http://www.michelf.com/
>
>
>