Last modified: 2012-12-21 13:46:14 UTC
Hi, I have proposed two new attributes be added to HTML5, @uris and @alternateURIs for the <a/> element. (This is relevant to Mediawiki, please keep reading) Custom protocols or URNs have very limited usefulness to any site such as Wikipedia if the link will do nothing when clicked. This proposal allows: 1) specification of protocols to be tried first as part of a link (<a uris="..."/>), and failing that, falling back to 'href' (which will work fine in non-supporting browsers). 2) specification of protocols that can be auto-detected by a supporting browser and opened via right-click or the like, but which does not override the "href" attribute by default. The editor of the HTML5 specification suggested that I try this out first as an extension (which I did at https://addons.mozilla.org/en-US/firefox/addon/162154/ ) so that it could be gauged whether there were sufficient interest in the community for this kind of functionality. Given that HTML5 is to support custom protocols, and given the failure of potentially useful URNs from taking off, I think it is pretty obvious that something must be done to foster experimentation with URNs and non-HTTP protcols since no one wants to click a link that does nothing. I believe that given Mediawiki's reach, and its interest in both being of service to its users and being a neutral party, I believe Mediawiki in particular would be most suited for trying out this functionality. Use of @uris (where priority is given to @href) might be usable within some form of markup to indicate that a link should try the given protocol first (e.g., an XMPP link when the subject was information about a chatting forum). But of even greater interest to Mediawiki might be @alternateURIs where you could link to say your own page about an ISBN, but allow this attribute to be added to cue browsers (or for now, at least users of the Open URIs Firefox extension) to be able to right-click to try out their own registered handler for ISBNs. Do you also see the potential for Mediawiki here? You already handle ISBNs in a similar way, but this does requires extra steps (and bandwidth) and doesn't offer the complete control that client-side flexibility can offer. I know this is still non-standard, but there is a chicken-and-egg scenario here in that HTML5 doesn't seem willing to implement given other priorities without some experience and indication of wider interest. Would you be interested to support this? It should not disrupt anything for your current users. Thank you...
Just to add another specific use case besides ISBNs. If a URN were to come into effect for say verses of the Bible, you could make these neutral links which could be interpreted by browsers (though perhaps defaulting (if not preferring) say a WikiSource copy). With wider, but neutral linking, people could also confirm authenticity more readily and improve the experience for users, without forcing them to give priority to a specific site over others (except perhaps as a convenient default if none already existed at a Wikimedia site).
I wouldn't mind this on irc:// urls either. There's potential there for cases where you do have a web based interface as well for fallback.
Yes, absolutely for IRC URLs too. Two more cases, though I'm sure the list could keep going on, especially for such a vast site as Wikipedia... 1) In one of my Firefox extensions, Unicode Input Tool/Converter (at https://addons.mozilla.org/en-US/firefox/addon/5235 ), I've implemented support for my custom protocol which allows linking to display Unicode characters, e.g., in context with their code point, definition, etc. I think this could be useful for language pages. See http://brett-zamir.me/tests/unicodeProtocolExamples.html for example links. 2) While I'm not sure whether Wikimedia would be open to the idea of encouraging links which could be redirected to other encyclopedias, given Wikimedia's support of choice and standards, perhaps it would be willing to work with other encyclopedias (whether wiki-based or not) to create a generic protocol for referencing an encyclopedic article, allowing browser redirects via use of this protocol (as my Open URIs extension already supports) from a site which did not wish to favor any particular encyclopedia but did wish to provide links for the convenience of its users. Of course, there would need to be a means of deciding which article names were canonical, but if nothing else, such links could use Wikipedia names as a base. For example, there might be a protocol, "pedia:" in a link like "pedia:?show=Love" and it would open the article "Love" in the user's favorite encyclopedic site (or local program). Or "pedia:?edit=Love" could bring one to the edit page (or alternatively, perhaps another protocol could specify editability: edit:?uri=pedia:?show=Love). The protocol could also be designed to allow the user to configure whether they wished to be brought to an edit page if the page's HEAD request did not turn up a Last-Modified, or to search another encyclopedia.
We should not add attributes that aren't supported by real-world implementations. It's a waste of effort and bytes, even if it maintained validity, which it wouldn't. Please reopen when at least one widely-used browser supports this feature.
I'm sure you understand the catch-22 here. The WhatWG editor told me that this needed to be tried out and demonstrate traction before it can be standardized. I'll probably be told by the browsers that this needs to be first standardized (if I get an answer at all: still waiting at https://bugzilla.mozilla.org/show_bug.cgi?id=539889 ). Meanwhile, this obviously useful functionality has no way of getting implemented if no one of significant standing will experiment with it either.
I should add that IE did specify a URN attribute already, but it defines no specific behavior. At least using this attribute could be utilized by the likes of my extension to offer alternative processing for the attribute.
The normal procedure to get features added to the standard web platform is: 1) At least one browser implementer expresses interest in implementing it. (If none are interested, there's no point in proceeding.) 2) It is written it up in a vendor-neutral draft specification published by a recognized body such as the W3C. 3) At least one browser implements it. 4) Sites start using it. Browser implementers routinely deploy experimental extensions and then ask sites to use them. They do their own internal testing by writing simple web pages that use the feature, and leave the extension experimental until they've gotten enough author feedback to standardize and finalize the API. This is the normal way things are done. Your Mozilla bug might be closed because they're not interested, but not because sites aren't using the feature, so there's no catch-22.
https://github.com/w3c/html linked from http://www.w3.org/TR/2012/CR-html5-20121217/ does not define any "@alternateURIs". Closing as WONTFIX as per comment 7.
