On 3/11/2010 9:19 AM, Ian Hickson wrote:
No, to my knowledge, there is no special behavior in IE with regard to
how it is used. I was really more listing it as a precedent, since I was
more in favor of a more general purpose "defaultProtocol" attribute
which could not only allow URNs but other protocols to be tried before
defaulting to a regular "href" link.
On Mon, 8 Feb 2010, Brett Zamir wrote:
Internet Explorer has an attribute on anchor elements for URNs:
This has not caught on in other browsers, though I believe it could be a very
powerful feature once the feature was supported with a UI that handled URNs
(as with adding support for custom protocols).
Imagine, for example, to take a link like:
urn="isbn:9210020251">United Nations charter</a>
The default behavior would simply follow the link, but if a user agent
supported the @urn attribute, and if the browser (or browser add-ons)
had registered support for that URN namespace identifier (here "isbn"),
it could, for example, open a dialog to ask which handler to use (or
whether to always use it), it could ask or otherwise allow in
preferences an HTML page (with wildcards) where the attribute's content
could be passed, or it could give the option whenever the user
right-clicked to choose which handler they wanted to use for a given
Does this match IE's behaviour with the urn="" attribute?
The problem with this is that it is not an approach which can likely be
taken by browser extensions nor be offered to websites which wish to
register themselves as handlers. And URNs by definition are not specific
to any site.
Historically, browsers that have wanted to offer dedicated services for
specific features, e.g. the iPhone handling map views using a dedicated
Maps application, have done so by simply overriding parts of the URL
space, e.g. in that case detecting when a page is on the Google Maps site
and parsing the URL locally instead of sending it to the remote site.
Is there really a need for a more dedicated mechanism? It's not clear that
there is much pent-up demand for this.
There wasn't a lot of pent up demand for the web itself either ("why
would people or companies want to link to other people's sites?"); if
people aren't able to use a feature or know of the concept, they might
not think of asking for it. I think that as with my earlier suggestion
on shared databases or storage, I think people are just not accustomed
to thinking that the web can be used in a way which collaborates between
sites (more than mere links), since the first idea that pops into
people's minds is how they can put their own site up. That doesn't mean
they wouldn't like to work with other sites or offer a feature that
would have normal fallback behavior in browsers that didn't support it.
If people can see a need for registering protocol handlers, the
"defaultProtocol" attribute is I think the best way to make it work.
Why would someone want to experiment in using a protocol (including
urn:), say ISBN:, if the interface will only say to their users, "This
browser does not recognize that protocol/namespace ID". The
defaultProtocol attribute would give a chance for the protocol/URN NID
to be checked for support, but if not working could default to visiting
the "href" target. Wouldn't that be a useful feature? Few will
experiment with <a href="urn:isbn:...">...</a> as it is just a dead link
for browsers that don't support the protocol, but I'm sure many sites
would be willing to allow <a defaultProtocol="urn:isbn:..."
href="http://books...">...</a> as it doesn't hurt to add one extra
attribute, even if say browsers are slow at supporting the attribute.
The web is not only about companies that want to make money and shuffle
people in the direction they want. There are also sites (including
companies without a stake in certain content) who want to offer more
choice to their users (e.g., Wikipedia, governments, individuals, etc.).
And no doubt any company wouldn't mind being able to register themselves
in a way where they could offer themselves to users visiting those more
neutral sites (e.g., Amazon registering itself for links leading to ISBN
links at other sites). It simply offers more choice to users...