Re: Extension Mechanism for HTML

Rene Saarsoo schrieb:
>> 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).

Yeah. It would actually work without their knowledge, as it would work 
for already-existing content. It's like magic.

> 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.

I think we could actually add a lot more names, as long as they are 
unambiguous enough.

> 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?

"search" shouldn't be dropped, if we can agree that limiting it to forms 
(and maybe input fields) makes sense. Of course it would still be 
allowed for all other elements; we're only defining meanings under 
certain circumstances.

"example" could be defined for aside, figure and section, although I 
don't find that class very useful anyway.

--Dao

Received on Tuesday, 8 May 2007 22:09:21 UTC