- From: Dão Gottwald <dao@design-noir.de>
- Date: Tue, 08 May 2007 14:04:33 +0200
- To: Rene Saarsoo <nene@triin.net>
- CC: public-html@w3.org
Rene Saarsoo schrieb: > > When we think about the problem in the sense of adding an extension > mechanism rather than accommodating the exact proposed predefined class > names, then it looks pretty clear, that current proposal of using > predefined class names without any prefix, doesn't do the job. That raises the question whether spec'ing a limited set of class names must only be done with a full-blown extension mechanism underneath. > Because if you want an extension mechanism, then you don't want a > situation, where you also have to carefully choose extension names, > because there is high risk, that they could clash with current usage. If a name clashes with the current usage, then it's a bad name. If a name is ambiguous, a prefix doesn't really help -- it wouldn't clash with existing content, but later on authors would possibly use it contrary to the spec. > With good extension mechanism, you can choose freely any name you would > like, and consentrate on the discussion of whether this name is too > ambiguous etc, but not be additionally worried how the chosen name might > be incompatible of some pages, that use it in a different sense. "how the chosen name might be incompatible of some pages" is strictly tied to "this name is too ambiguous". > So, I would now go on discussing the two proposed alternatives, which > can be considered an extension mechanism: the role attribute and > predefined class names with some prefix. If that means that spec'ing class names without a prefix shouldn't be discussed any more, then I have to disagree with that way of proceeding. > 1. Predefined class names with prefix '_' > > (I will assume the underscore-prefix, as there doesn't appear > to be any objections against it, and it has several advantages, > that Lachan Hunt previously pointed out [1].) > > + Easy to select with CSS, e.g. ._copyright { ... } > > + Really easy to implement and also easy for authors to understand. > > - Complicates the existing class attribute. > The @class won't be purely un-semantical any more. The class attribute isn't purely un-semantic. Many authors use it in a semantic way, but the names aren't interoperable yet. Authors who don't use it in a semantic way would hardly be harmed by a set of spec'd class names. - It's not obvious what '_' means, that authors mustn't invent their own names with that prefix etc. - It doesn't enrich existing content. --Dao
Received on Tuesday, 8 May 2007 12:04:46 UTC