> 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.wri
te(" ")}
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.o
rg/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-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
