Re: microformats, profiles, and taking back rel/class names [standardizedFieldValues-51]

noah_mendelsohn@us.ibm.com wrote:
> Dan Connolly wrote:
>
>   
>> I suppose the HTML WG has the right to "take back" @rel and 
>> @class values, but I'm uneasy about it.
>>     
>
> Me too, very uneasy.  Let me repeat here something that I said on the TAG 
> call, originally intended in jest, but I'm now thinking it might be a 
> serious proposal.  The current HTML 5 draft [1] says of the class 
> attribute:
>
> "Authors may use any value in the class attribute, but are encouraged to 
> use the values that describe the nature of the content, rather than values 
> that describe the desired presentation of the content."
>
> Perhaps to be a true guide to the intended use of this attribute in the 
> presence of technologies like microformats it should say:
>
> "Authors may use any value in the class attribute, but are encouraged to 
> use the values that describe the nature of the content, rather than values 
> that describe the desired presentation of the content. 
>
> NOTE: although this version of the HTML specification provides no specific 
> meaning for any particular class attribute tokens, future versions of this 
> specification, other specifications, or common public practice will likely 
> assign preferred connotations to some.  (For example, at the time of this 
> writing, the token 'vcard' is coming into common use for designating 
> information about people, companies, organizations, and places. [2]) 
> Because no means is here provided of identifying in advance which tokens 
> will later be given such preferred meanings, there is a risk that any 
> document using any value(s) for class attribute tokens will later prove 
> incompatible with widely deployed conventions."
>
> In short:  we know this is "broken" in this way.  Implicitly, we believe 
> the benefits outweigh the risks, but we are at least warning you of the 
> problem. 
>   
I see  absolutely no reason to *break* something which isn't currently
broken, at least when there is a "way" to do it correctly. The correct
way is to use @profiles as given by HTML 4, since a profile can assign a
way of "preferred meanings" for values of the class attribute.
Therefore, the preservation of @profile in HTML 5 is of importance, even
if it's empirical use on the Web is currently low. The Web itself is a
work in progress, and there's a huge use case to be given for the use of
profile for mobile and accessibility use-cases, regardless of
microformats and GRDDL.

If @profile is lost, and if @rel and @class are given a single
centralized repository with *no* way to extend HTML in a principled
manner, you are breaking decentralization of the Web, period. The W3C
should not endorse something so fundamentally broken, but should instead
both codify existing best practice but allow  hooks to correct current
broken common practice in hope that the Web remain decentralized.

Since the HTML 5 WG is part of the W3C, I suggest that they remain
compliant with Web architecture  given by both the W3C and as defined by
HTML 4. HTML 5 could be a great thing, but simply throwing away every
feature that does not have "widespread use" is a mistake. It would be
far better to combine empirically-driven codification of HTML with good
practice of Web architecture. If either viewpoint is missing, it should
be corrected asap.
> Now, I personally am not at this point convinced that the benefits of 
> retroactively assigning such universal meanings do outweigh the risks, but 
> I am increasingly convinced that we should warn users if this is likely to 
> happen.
>
> Noah
>
> [1] http://www.whatwg.org/specs/web-apps/current-work/#classes
> [2] http://microformats.org/wiki/hcard
>
>
>
>
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>   


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Monday, 16 July 2007 20:18:20 UTC