[whatwg] URN or protocol attribute

On 3/11/2010 10:44 AM, Brett Zamir wrote:
> On 3/11/2010 10:31 AM, Ian Hickson wrote:
>> I would recommend following a pattern somewhat like the Web's initial
>> development: create a proof of concept, and convince people that it's 
>> what
>> they want. That's the best way to get a feature adopted. This is 
>> described
>> in more detail in the FAQ:
>>
>>     
>> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F 
>>
>
> Ok, fair enough. I think I'll try that as a browser extension <snip>

Just as a follow-up, I have now made a Firefox extension which supports 
two attributes on <a/>: "uris" and "alternateURIs", whereby the former 
takes precedence over "href", and the latter are accessible only by 
right-clicking links (though potentially discoverable by custom styling 
of such links (automatable by the extension)).

My thought is that sites which have the following goals may be 
particularly interested:

1) Those wishing to maintain objectivity and refrain from endorsing 
specific sites, e.g., governments, news institutions, scholars, or sites 
like Wikipedia. Even for a site's internal links, use of "alternateURIs" 
could offer convenience (e.g., Wikipedia would no doubt wish to continue 
to use href to refer to its own ISBN page by default, but could use the 
"alternateURIs" attribute to allow right-clicks on the link to activate 
the URN link which in turn activates their chosen default handler, e.g., 
Amazon, Google Books, etc.). The same could be done for music, etc.
2) giving full user choice as to how to view the data (especially useful 
for information of common and particular interest to the site viewers, 
e.g., links to the Bible in a religious forum)
3) those wishing to try out new protocols of whatever type (not only 
URNs), such as chatting protocols, whether installed via web or browser 
extension, as the proposed markup gives them a convenient fall-back to 
"href", so they don't have to have dead links for those whose browsers 
do not support the protocol.

https://addons.mozilla.org/en-US/firefox/addon/162154/

Brett

Received on Thursday, 3 June 2010 21:59:00 UTC