[whatwg] microformats incompatible with WebApps 1.0 ?

Mon Dec 11 16:45:44 PST 2006

Le 12 déc. 2006 à 09:24, Ian Hickson a écrit :

> On Tue, 12 Dec 2006, Karl Dubost wrote:
>> Le 12 déc. 2006 à 07:19, Ian Hickson a écrit :
>>>> I'm not sure what the solution to this problem is.
>>>
>>> Me neither. Suggestions welcome.
>>
>> For example for hcard, you could do:
>>
>> <link rel="hcard" href="http://www.w3.org/2006/vcard/ns"/>
>> <link rel="hcard" href="http://www.w3.org/2006/03/hcard"/>
>
> I don't really understand how that would solve the problem; could you
> elaborate?

ok. For microformats it is mandatory to have a profile URI in the  
head, it helps specifically parsers. It has also the benefits that an  
authoring tool can download automatically XMDP profile for creating  
an help to edit microformats.

So a page containing microformats looks like that.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head profile="http://gmpg.org/xfn/11">
       <title>Tantek's Thoughts</title>
       <meta http-equiv="content-type" content="text/html;  
charset=utf-8" />

Then in the page there are things like

<ul class="xoxo facets">
    <li><a href="http://technorati.com/profile/tantek"  
rel="me">Technorati</a>…</li>
    …
</ul>

rel="me" has a meaning because of the profile up there.

With the new proposal

<ul class="xoxo facets">
    <link rel="xfn" href="http://gmpg.org/xfn/11"/>
    <li><a href="http://technorati.com/profile/tantek"  
rel="me">Technorati</a>…</li>
    …
</ul>

* People can add this information even if they do not have access to  
the template (head section). Most common use case form editing.
* People have it right under their eyes near the information they  
want to describe (if they wish it).
* Parsers can still have the information to disambiguate when necessary.

>> I proposed to modify the link element as such:
>>
>> ==================================
>> 3.8.4. The link element
>>
>> Metadata element.
>>
>> Contexts in which this element may be used:
>>     Where strictly inline-level content is allowed.
>> ===================================
>>
>> Rationale:
>> So people can add it in a web form,  and then do in situ editing.  
>> Metadata can
>> be near the content when needed.
>>
>> I would also propose the same for the meta element.
>
> Unfortunately in both cases we don't really have any choice; for back
> compat, <link> and <meta> elements that aren't in the <head> must  
> be moved
> to the <head> by the parser.

Then for back compatibility you will have to keep the profile attribute.
See
4. Using GRDDL with valid XHTML
    http://www.w3.org/TR/grddl/#grddl-xhtml

Parsers are not only browsers parsers.

Do you have an explanation for the why of
	"<link> and <meta> elements that
	aren't in the <head> must be moved
	to the <head> by the parser."

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***