Extension Mechanism for HTML (was: Re: Predefined Class Names Solution)

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.

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

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.


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.


2. The role attribute

    (Since I'm far from being a @role-expert, the following pros and
    cons about @role may or may not be the full truth.)

  + Already has it's own specification:
    <http://www.w3.org/TR/xhtml-role/>

  + Since values in @role can be namespace qualified, groups
    can create their own taxonomies.

  + Support for @role already exists in recent versions of Firefox [2].

  - Not so easy to select with CSS, e.g. [role~="copyright"] { ... }

  - Introduces many additional complexities regarding RDFa and QNames.
    Not as easy to implement, but even more problematically
    might be harder to understand for authors.


As I see, it's now the question: do we need all the advantages of
@role although it has some additional complexites, or shall we
settle with simpler (but maybe too simplistic) predefined classnames?


[1] <http://lists.w3.org/Archives/Public/public-html/2007May/0799.html>
[2] <http://developer.mozilla.org/en/docs/Accessible_DHTML>

--
Rene Saarsoo

Received on Tuesday, 8 May 2007 11:33:23 UTC