W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re: Extension Mechanism for HTML

From: Rene Saarsoo <nene@triin.net>
Date: Tue, 08 May 2007 19:15:11 +0300
To: public-html@w3.org
Message-ID: <op.tr0nflupexn25i@localhost>

> That raises the question whether spec'ing a limited set of class names  
> must only be done with a full-blown extension mechanism underneath.

This is of course a valid concern.

But when we introduce predefined class names, we _are_ extending the  
current definition of @class. Therefore doing it with a clear extension  
mechanism seems appropriate.

You sayd:

> It's not obvious what '_' means, that authors mustn't invent their
> own names with that prefix etc.

But how obvious it is, what a class name without a prefix means? When  
there is a prefix, then authors would at least have a clue, that such a  
class name might be something special, while without a prefix they  
wouldn't have even a slightest idea (if of course they haven't read the  
spec, which most of them don't).

To me the current predefined class names proposal looks like lets have all  
the benefits now, and don't worry whether we would like to do something  
similar (add more predefined classes) at the future.

We already agreed, that "note" and "issue" were too ambiguous. I  
demonstrated how "search" could be used in different contexts, for which  
there were given a solution to limit "search" class only to the <form>  
element. This kind of solution would complicate the class attribute even  
further - limiting predefined classes to certain elements would put a  
great burden to the shoulders of authors to remember which predefined  
class goes with which element.

I easily found many examples of conflicting use of "example" class [1].

So now we are left only with "copyright", "error" and "warning".

And even these have conflicts with existing usage. It's still debatable,  
whether the percentage of conflicts is small enough.

And no-one has suggested, what should be used instead of "issue", "note",  
"search" and "example". Should these be dropped completely?

If we would go for an extension mechanism, we could still use the names  
"example" and "search". With currently proposed predefined classes we  


Rene Saarsoo
Received on Tuesday, 8 May 2007 16:15:05 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:20 UTC