On 3/11/2010 9:19 AM, Ian Hickson wrote:
On Mon, 8 Feb 2010, Brett Zamir wrote:
Internet Explorer has an attribute on anchor elements for URNs:
http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx

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:

<a href="http://www.amazon.com/...(shortened)...."
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
link.
Does this match IE's behaviour with the urn="" attribute?

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.

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.

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.
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...

Brett

Reply via email to