Hi,
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.
Likewise, a link like:
<a href="http://en.wikipedia.org/wiki/United_Nations_Charter";
urn="wikipedia:United_Nations_Charter">United Nations charter</a>
...could alternatively be opened in the corresponding Encyclopedia
Britannica (or Amazon, etc.) page (assuming "wikipedia" could be
accepted as a URN namespace, thus unburdening the IANA from coming to
consensus on the web community's many and ever-expanding names). Users
would be free to follow the content in the data viewer they wished to
use, while sites would be free to avoid committing too strongly to any
particular handler implementation (i.e., the website they specify is
only a default).
Although software has been made to handle URNs within @href (see, for
example, https://addons.mozilla.org/en-US/firefox/addon/1940 ), it is
really a lot to ask for website creators to support a protocol without
being certain of support (or at least a JavaScript fall-back which could
test for support). With this proposal, there is no real down-side to
content creators, users, etc. (nor, given the simplicity of this
proposal, even really, it would seem to me, to specification editors!),
to adding an extra attribute (which need have no precise behavior
associated with it).
Actually, maybe even a "protocol" attribute would be in order to give a
similar alternative between a default website and a generic protocol
handler (and maybe the "urn:" protocol could be subsumed into this even
more general attribute).
So, my suggestion is to add to <a/> a @urn or, even better, a @protocol
attribute (since the latter is more comprehensive and also already has a
formal API for JavaScript registration of handlers). If some browsers
are not keen on supporting it, maybe there could be a simple test to
check for support, since it is not strictly necessary, but could
unobtrusively offer more choice to users.
best wishes,
Brett
