[whatwg] URN or protocol attribute

[Brett Zamir]

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