- From: Michel Fortin <michel.fortin@michelf.com>
- Date: Thu, 17 May 2007 16:36:11 -0400
Le 2007-05-17 ? 13:54, Adrienne Travis a ?crit : > 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. Well, you *can*, but it's not a pretty selector: .dc\:author { } or *[class~="dc:author"] { } > If the namespacing was handled with dashes, like class="dc-author", > that would work, though.) So I suggest doing it like this: class="-dc-author" which can be selected this way: .-dc-author { } The idea of the leading dash is to avoid potential clashes with existing values: it's common today to separate two words inside a class name with a dash, it's much less common to start a class name with a dash. So perhaps the spec should reserve class names starting with a dash for namespacing purpose and define the meaning of those as the XHTML Role Module would have defined them with the semicolon syntax. I don't think in any way that this is incompatible with the predefined class names that were just removed (which I liked), it's just a little addition so you're not limited to the few predefined ones. The XHTML Role Module also has a couple of predefined global roles it seems. Michel Fortin michel.fortin at michelf.com http://www.michelf.com/
Received on Thursday, 17 May 2007 13:36:11 UTC