[uf-discuss] Microformats UI in Firefox 3

[Alex Faaborg]

> Instead of having to checking whether the userAgent is right or  
> wrong in my javascript - wouldn't it be possible to check for the  
> presence of any hCard-related function instead?

Yeah, if we wanted to solve this problem with javascript, that is  
probably what we should do.  But I'm a little weary of requiring  
javascript for exposing microformatted content to browsers due to it  
commonly being blocked on most wikis, and it potentially being  
unfamiliar to content creators.

Perhaps a good compromise would be to just break backwards  
compatibility on wikis, since they can't use javascript to figure out  
if the action is going to actually work.

There are really two separate issues here:

1) backwards compatibility
	-navigator.userAgent
	-style="visibility:hidden" hack
	-if (navigator.microformatAware("hCard")){document.write(" ")}
2) instructing the browser to take action on a piece of data
	-user-action-app class
	-protocols
	-third solution?

> Couldn't another solution be to add some kind of a "protocol"?

The general uf:// protocol wouldn't distinguish what the user wants  
to do with the content (for instance, hCards could be sent to an  
address book, or a map).  So this might result in some really  
implementation-level UI, like links that say "Send hCard to your  
Browser."

We could create protocol handlers for each generic application type  
(map://, addressBook://, calendar://).  The only thing that seems a  
little unusual is that normally content creators would expect to send  
the data by value instead of my reference, for instance:

  mailto://name@domain.com?subject=this is the subject?body=this is  
the body

(although I'm not really sure how commonly known this is)

> Like uf://foobar.com/foo.html#bar-hcard Firefox could process such  
> a link by extracting the hcard with the id "bar-hcard"

I do like really like the idea of being able to reference  
microformats elsewhere on the page, or on any other page.  Something  
else that makes this is a little unusual is that the browser may not  
get a 404, but the data is still missing.  Also, since the  
information is still being transported using http, using a new  
protocol in the URI would be technically inaccurate.

This design might encourage people to reference information instead  
of duplicating it.  I honestly don't know if that is a good thing or  
a bad thing.

One potentially major problem: if you change the scheme from http,  
you can't have a relative URI, you have to create an absolute one:

    Relative URI references are distinguished from absolute URI in that
    they do not begin with a scheme name.  Instead, the scheme is
    inherited from the base URI
		http://www.ietf.org/rfc/rfc2396.txt

This could be a problem for content creators because in most cases  
they would want to reference the microformat they are currently in,  
but they may not know what its URI is going to end up being, or they  
don't want to take the time to figure it out.  It would also be  
impossible for creators (like the hCard creator) to know what the URI  
is eventually going to be.

I think overall using protocols is conceptually simpler, because what  
you are creating is in fact a hyperlink.  But what we would need is  
relative URIs with different schemes, maybe something like:

<a href:"map:#the-id">Map</a>

Unfortunately this twists the definitions of "relative" and  
"absolute."  It's likely that other people from Mozilla (or on this  
list) won't be too fond of breaking a bunch of RFCs from the 90s.

What do other people think about using protocols for microformat  
handling?

-Alex




On Aug 27, 2007, at 10:54 PM, Pelle W wrote:

> Alex Faaborg skrev:
>> This is a bit of a hack, but it is also considerably easier than  
>> asking the author to write javascript to check  
>> navigator.userAgent, know which browsers handle microformatted  
>> content (and subsequently update this as it changes), and then  
>> display the link accordingly.  Also, I'm interested in allowing  
>> user generated microformatted content to be added to blogs and  
>> wikis where javascript is not commonly allowed.
> A bit of friendly fedback here, not saying that I would be right at  
> all only sending out some thoughts that may be useful or may be  
> garbage.
>
> Instead of having to checking whether the userAgent is right or  
> wrong in my javascript - wouldn't it be possible to check for the  
> presence of any hCard-related function instead? This way it would  
> at least be theoretically possible for any web browser to add such  
> a function, either officially or through a third party plugin, and  
> so trigger the website to view the possible actions.
>
> It seems a bit unusual to me to have a class like "user-action"  
> which the browser should find and change to visible and make a link  
> out of or something. Couldn't another solution be to add some kind  
> of a "protocol"? Like uf://foobar.com/foo.html#bar-hcard Firefox  
> could process such a link by extracting the hcard with the id "bar- 
> hcard" and for Internet Explorer a third party program could deal  
> with the link in the same way that Skype deals with call: and  
> Thunderbird deals with mailto: or I could choose to hide the link  
> from IE users. This would be a more usual approach because it  
> already exists for other kind of data like mailto: , javascript: ,  
> call: etc.
>
>
> / Pelle W
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss