[whatwg] Feedback affected by the predefined classes being gone

[Ian Hickson]

On Fri, 8 Dec 2006, Michel Fortin wrote:
> > 
> > A document must not use a class defined in the Wiki on an element 
> > other than the elements that the Wiki says that class name is allowed 
> > on.
> 
> Does that mean that conformant documents can suddenly become 
> non-conformant because a class it uses has been added to the Wiki with 
> somewhat different semantics?
> 
> I have nothing against registering class names, but in some cases it 
> doesn't make any sense to register class names you're only using 
> internally, and it'd be a bad thing if they were to clash with 
> predefined ones. But in practice, I'm not sure it matters much.

On Tue, 20 Feb 2007, Michel Fortin wrote:
> > 
> > The proposal to have predefined class names is still very much in the 
> > air, we're mostly waiting for author and implementation feedback to 
> > see if it is workable. Currently the HTML5 spec leaves a number of 
> > things unanswered (like what happens if two classes on an element are 
> > contradictory), so it's definitely not finished.
> 
> About that, I would like to suggest that the current text be changed to 
> reserve class names starting with a dash "-" for private use. That way 
> that we would have a pool of class names which are guarantied to not be 
> taken over later when new predefined class names are added. It could 
> even encourage some kind of namespacing for class names, in a similar 
> way that CSS extensions -- or not yet standardised features -- are 
> prefixed by the engine name like in -moz-border-radius or 
> -webkit-column-count.

On Wed, 21 Feb 2007, David Latapie wrote:
> 
> This seems an interesting feature to consider. Maybe we shall reserve 
> *two* class names=
> 
> • "-*" for experimental, as for CSS vendor profiles. Same prefix, same 
> meaning and consequently easier to understand/adopt.
> 
> • "micro-*" for what Michel suggested (that is, class names that have 
> a definitive meaning). I decided on micro, like microformat, but this is 
> really just a suggestion and maybe a bad one (refer to the <m> element 
> naming debate), so please investigate any other possibility.

On Wed, 21 Feb 2007, Michel Fortin wrote:
> 
> By the way, it would certainly be more coherent if unregistered class names
> were disallowed too (unless they start with a dash), but that would also make
> countless documents non-conformant with HTML5 so I'm not sure it's a so good
> idea. I can't say I dislike the idea though.

On Wed, 21 Feb 2007, Elliotte Harold wrote:
> 
> Good idea. Should we follow MIME types, and maybe make these x- instead 
> of simply -?
> 
> Also, should we reserve one spac eof names for the spec? e.g. html-?

On Wed, 21 Feb 2007, Michel Fortin wrote:
> 
> That could also work, but based on aesthetics I still prefer my first 
> proposal.
> 
>     <p class="x-superparagraph">You are here</p>
>     .x-superparagraph { font-size: 90% }
> 
>     <p class="-superparagraph">You are here</p>
>     .-superparagraph { font-size: 90% }
> 
> It seems to me that the current spec allows itself to define any class 
> name as its own while still allowing authors to use any yet-undefined 
> ones. Are you suggesting that the spec disallows the use of undefined 
> class names starting with "html-"? What would be the purpose?

On Fri, 4 May 2007, Henri Sivonen wrote:
>
> Quoting the spec:
> > Conformance checkers must use the information given on the WHATWG Wiki
> > ClassExtensions page to establish if a value not explicitly defined in this
> > specification is defined, and if so, whether it is being used on the right
> > elements.
> 
> This is problematic as previously conforming documents would be made 
> non-conforming when a class name is registered and doesn't apply to all 
> elements (then the previously conforming documents use it elements for 
> which it doesn't apply according to the registration).
> 
> > When an author uses a new class name not defined by either this 
> > specification or the Wiki page, conformance checkers may offer to add 
> > the value to the Wiki, with the details described above, with the 
> > "proposal" status.
> 
> It has been pointed out to me that the offers would drive developer 
> crazy.

Regarding all of the above, now that this section of the spec has been 
removed, the above comments no longer apply. Thanks for the feedback, 
though.


On Tue, 20 Feb 2007, Michel Fortin wrote:
> 
> I think it'd be useful to have that on rel values (link types) as well.

On Wed, 21 Feb 2007, David Latapie wrote:
> 
> rel="microformat"?
> 
> class="-footer" rel="microformat" and class="micro-footer" 
> rel="microformat"?

On Wed, 21 Feb 2007, Michel Fortin wrote:
> 
> The rel attribute is about links. What I meant by that is that I think 
> it would be useful to have a private domain for link types too. It would 
> work a little differently than on class though, because the current spec 
> disallows unregistered link types while it allows unregistered class 
> names. My proposal would be to allow unregistered link types if they 
> start with a dash "-".

What's the advantage of allowing this, given that authors can already use 
class="" on links?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'