Re: Extension Mechanism for HTML

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