[whatwg] microformats incompatible with WebApps 1.0 ?
ian at hixie.ch
Mon Dec 11 16:56:17 PST 2006
On Tue, 12 Dec 2006, Karl Dubost wrote:
> > >
> > > <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
Mandatory but rarely done, so only mandatory de-jure. De-facto it's
optional and doesn't do anything.
> it helps specifically parsers.
Parsers rarely actually pay any attention to profile="", both because most
content omits it, and also because it's harder to do so. So while
profile="" was originally intended to be used by parsers to reduce
ambiguity, in practice it isn't used by them and doesn't help them.
> It has also the benefits that an authoring tool can download
> automatically XMDP profile for creating an help to edit microformats.
Auto-generated UI is rarely optimal, though.
> So a page containing microformats looks like that.
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> <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" />
In HTML5, the above can now be written as:
...which is far easier to write and understand.
> Then in the page there are things like
> <ul class="xoxo facets">
> <li><a href="http://technorati.com/profile/tantek"
> rel="me" has a meaning because of the profile up there.
With the new proposal, the above still works, but doesn't require the
> With the new proposal
> * 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.
With the spec as written now, however, people still don't need access to
The disambiguation thing is nice in theory (which is why I wrote a
detailed normative description for how to handle it about a year or two
ago, in far more detail than HTML4 ever did), but in practice nobody uses
it and it therefore it doesn't actually disambiguate anything.
> > 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.
I don't really see why. Nobody uses it. What useful content would you be
being compatible with?
> 4. Using GRDDL with valid XHTML
> Parsers are not only browsers parsers.
Removing profile="" makes GRDDL implementations easier and makes them more
compatible with existing content. How is that not a boon?
> 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."
It's what browsers do... what do you mean?
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg