[whatwg] microformats incompatible with WebApps 1.0 ?

Mon Dec 11 17:53:48 PST 2006

On Tue, 12 Dec 2006, Karl Dubost wrote:
> > >> 
> > > 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, the above still works, but doesn't require the
> > profile attribute.
> 
> :) wonderful for all people using class="something" in their pages. For 
> backward compatibility, will it be asked to thousand of people to fix 
> their class names because it will be interpreted by parsers in the wrong 
> way?

Given that Microformat parsers currently ignore the profile="" attribute 
anyway, since so few people use it, the scenario you ask about is 
_already_ happening. So your implication -- that removing profile="" 
introduces a problem -- is false; the problem already exists.

> > 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.
> 
> because people *can not* do it in most cases. profiles in head section. 
> As we say in French, you just made a circular reasoning "Le serpent se 
> mange la queue."

This is simply not true; while many people can't edit their <head> 
section, many people can, and yet a ridiculously small number of people 
bother to do so anyway.

> > > > 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?
> 
> 	*nobody* … which is a false statement.

I am very confused about what you are arguing. On the one hand you are 
arguing that we should keep the profile attribute, yet you offer no 
evidence that there exists useful content with which processors would 
benefit from using the profile="" attribute. On the other hand, you argue 
that it cannot be used by authors because they cannot edit the head of 
their templates, and you propose an alternate syntax that is not backwards 
compatible and attempts to solve a problem you have not shown exists.

> > > See
> > > 4. Using GRDDL with valid XHTML
> > >    http://www.w3.org/TR/grddl/#grddl-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?
> 
> I though it was nobody just from above.

My argument is that nobody uses profile="", therefore not requiring GRDDL 
implementations to use it makes GRDDL implementations easier to write and 
makes them more compatible with existing content.

> > > 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?
> 
> So what you are saying is that old browsers now put back the link and 
> meta in the head section. Recovering the tag soup. Though it doesn't 
> forbid any microformat parsers to analyze the thing in situ in the tree. 

The entire point of having a single parser specification is so that we 
have a single parser specification that all parsers can comply with, 
ensuring that all processors use the same content the same way. We are not 
going to start requiring processors to handle elements in different ways 
depending on what the end use is going to be -- that way lies madness.

> And it is still a benefit for the end user.

You have yet to show that the end user has a problem to solve in the 
first place, let alone how the end user benefits from any changes here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'