[uf-discuss] Signalling use of microformats?

[Tantek Ç elik]

On 2/9/06 4:04 PM, "Scott Reynen" <scott at randomchaos.com> wrote:

> On Feb 9, 2006, at 4:55 PM, Ryan King wrote:
> 
>> On Feb 9, 2006, at 2:45 PM, Andy Mabbett wrote:
>> 
>>>>>         <meta name="microformats" content="tag hAtom xFolk" />
>>>> 
>>>> Ironically, this is exactly the sort of thing microformats are
>>>> against
>>>> using-
>>> 
>>> But it's not a microformat; it's metadata.
>> 
>> Around here, hidden metadata == bad.
> 
> I think that needs some qualification.  Principles should organize,
> not replace, thought.  XHTML is hidden metadata.  If all hidden
> metadata == bad, then we should send XHTML as text/plain, so humans
> can read the XHTML metadata before telling their machines to parse
> it.  Short of that, we should put notes in our XHTML telling people
> that there are CSS and JavaScript documents attached, so they can
> make use of that important metadata.

Scott's right.  Folks, let's not confuse content and markup.

Markup isn't data nor even metadata -- it's more like data types.

The *content* (including metadata) should be visible.  That's all we are
saying here.  Tags (actual <> tags, not rel-tags), class names, link
relationships are all just markup (though link rels can be a bit fuzzy
there).


> I realize that it's still common practice to mention feeds in XHTML,
> but I stopped doing this as soon as browsers (machines) started
> recognizing feeds.

This is also true, and a subtly different point.

This is precisely why we have both <link rel> and <a rel>.  Some folks will
want to explicitly mention their feeds and thus <a rel="alternate"
type="application/atom+xml"> (or equivalent for RSS) makes sense.  Other
folks want to indicate the document level relationship invisible, and thus
they use <link rel="alternate" type="application/atom+xml">.

While from visibility perspective, <a> is better than <link>, the fact is,
that there rarely is any actual *content* being published in that markup.
(Sometimes the name of the feed is placed into the 'title' attribute or link
text).  Thus such links are not much different than links to style sheets -
a purely mechanical part of the page without any corresponding user content.

The problems occur when people stick things that *are* much more like user
content (e.g. keywords, description, location (geo), etc.) into invisible
meta tags.  That's invisible metadata and that's what we're saying is bad.


> I trust a machine to tell a human what it can
> read more than I trust myself to predict what a random human's
> machine will do with a given file (e.g. dump it to the screen and
> completely confuse them).  I see a PR benefit in promoting "This page
> contains microformat X" announcements, but I don't see how this would
> help humans at all.

There is of course the PR/marketing benefit, but you're right, there should
be a more user-centered benefit in order to justify such links.

One such benefit with hCard and hCalendar is the ability to add the
information to your address book or calendar.

With rel-tag links, the benefit is being able to see more detail (or
conversation) on the tag/topic being referenced.

With rel-license, the details of the license.  Etc.


> They can already see the content.  If their
> client can extract the machine-readable version of that content,
> their client will know it can do that, and their client can tell them
> this. 

Yes.


> If their client can't extract the machine-readable version of
> the that content, how does it help humans to tell them it's there?

It might help folks realize there may be more to the site than they are
looking at, or there are alternative ways to use a site.  If the current
browser they are using doesn't understand that, the user should at least be
given the opportunity to learn about such additional features or views and
find a client which does support them.  In that respect, it might make more
sense to (visibly) link to an explanatory page, or a page that would help
you with subscribing, rather than directly to a chunk of XML which in many
browsers will simply render an ugly mess.  (The so-called orange XML button
aversion therapy).

Thanks,

Tantek