[whatwg] microformats incompatible with WebApps 1.0 ?

Le 11 d?c. 2006 ? 21:25, Ian Hickson a ?crit :

> On Mon, 11 Dec 2006, Michel Fortin wrote:
>
>>     <div profile="http://microformats.org/wiki/hcard-profile"  
>> class="vcard">
>>      <a class="url fn" href="http://tantek.com/">Tantek ?elik</a>
>>      <div class="org">Technorati</div>
>>     </div>
>
> Given that nobody does the former, why would anyone do the latter?  
> Bear in
> mind that to all intents and purposes, the page looks and works  
> exactly
> the same with or without the profile. Also bear in mind that enough
> content exists that doesn't use the profile="" attribute that
> implementations will always look for content regardless of its  
> presence.

The only reason this is supported in my proposal is for when people  
want to define their own extension without having to register it with  
anyone. If someone wish to have a short name, it has to be  
registered. Obviously, hCard will have a short name, so there is  
little reason to use the long form.


>>     <div profile="hcard">
>>      <a class="url fn" href="http://tantek.com/">Tantek ?elik</a>
>>      <div class="org">Technorati</div>
>>     </div>
>>
>> How is that?
>
> It's one step away from:
>
>      <div class="vcard">
>       <a class="url fn" href="http://tantek.com/">Tantek ?elik</a>
>       <div class="org">Technorati</div>
>      </div>
>
> ...which would work just as well, and has the added advantage that  
> it is
> compatible with how hCard is used today.

I'm not arguing that everyone would need to change hCard on their  
website once HTML5 becomes a recommendation. hCard is already  
deployed as it is and tools still need to support that syntax. But  
for the future, using a profile attribute instead would ensure that  
existing documents do not become non-conformant the day a new  
extension is added.


>> What's different is that you have to care about conformance only  
>> to the
>> profile you're using, and no other. When new profiles are created,
>> adding new classes and link types, you know they won't bother you.
>
> Except that in practice they will, because if suddenly your class name
> clashes with a new class name, regardless of whether we have  
> "profile" or
> not, processors looking for that class name will start treating  
> yours as
> one of theirs.

And that's exacly the problem I'm trying to solve by making the  
profile attribute easier to use. It's probably true that parsers will  
have to continue to work with what's currently out there, but I'd  
like this problem to be avoided for future microformats.

And as you noted, the profile attribute I illustrated above is only  
one step away from current practices. That's deliberate as it would  
make adoption and understanding easier, at least for future formats  
and possibly for new versions of currents formats too.

I'd like to add that the same problem can exists in reverse too:  
there is always the possibility that someone influent, through the  
deployment of software or by other means, carelessly popularize a  
class also in use by a microformat. This would make the microformat  
unusable on the web. The more microformats there are, the bigger are  
the risks that this happen. With a separate profile attribute as  
defined in my previous post, this can hardly happen without  
deliberately violating the registration process.


Michel Fortin
michel.fortin at michelf.com
http://www.michelf.com/

Received on Tuesday, 12 December 2006 10:27:53 UTC