2009 Apr 7, 12:14This makes plenty of sense, that a site should be able to check if a protocol handler exists for some URI scheme, but it'd be nice if this were some sort of declaritive fallback plan rather than
having to do it all with script. "The HTML5 standard function registerProtocolHandler() should probably remain void as in standard, but WhatWG could invent yet another boolean
protocolRegistered("area"), with the only argument (protocol name as string), to check whether a protocol is registered."
html5 registerProtocolHandler html script url uri scheme protocol 2009 Apr 7, 12:12HTML5's registerProtocolHandler seems to come from a cool FireFox 3 feature: "With web protocol handlers, the web application can register the specific protocol it wants to handle. Firefox will then
prompt the user to choose which of the registered applications (web or desktop) it should use to handle the action. Any protocol, real or imaginary, can be used - mailto: is only one example,
webcal:, tel: and fax: are others."
firefox uri scheme protocol mozilla html5 registerProtocolHandler 2009 Apr 7, 10:45HTML 5 allows websites to register themselves as handlers of particular URI schemes and particular content-types. I think this is great, but I'm surprised it doesn't support POSTing files to allow
for interactions with local content.
html5 url uri protocol reference html standard javascript webbrowser registerProtocolHandler 2009 Apr 7, 9:02
I'm a big fan of the concept of registerProtocolHandler in HTML 5 and in FireFox 3, but not quite the implementation. From a high level, it allows web apps to register themselves as
handlers of an URL scheme so for (the canonical) example, GMail can register for the mailto URL scheme. I like the concept:
- Better integration of web apps with your system.
- Its easy for web apps to do.
- Links to URNs can now take the user to the sites the user prefers for the sort of thing identified by the URN. For example, if I have a physical address in HTML, instead of making that an http
link to Yahoo Maps, I can make the link a geo scheme URI and those who follow the link will get their preferred mapping site that
has registered for that scheme. Actually, looking at the geo scheme's RFC, maybe I'd rather use some other URN scheme to represent the physical location, but you get the point.
However, the way its currently spec'ed out I don't like the following:
- There's no way to know if you are the handler for a particular URL scheme which is an important question for web app URL protocol handler authors.
- There's no way to fallback to an http URL in the case that a particular URL scheme isn't registered. A suggested solution to testing the registration of a scheme is for browsers to provide an additional script method
to check if a scheme is registered. I don't like the idea of writing script that walks over all my page's links and rewrites them based on that method. I'd much rather see a declarative and
backwards compatible fallback mechanism, although I don't know what that would look like.
- There's no way to register for a namespace within the urn scheme URI, the info scheme URI, or the tag scheme URI. I want to register
info:lccn/... (Library of Congress Card Number identifiers) to LibraryThing or Amazon and I want to register urn:duri:... (dated URIs) to the Web Archive, among other things.
- Will this result in a proliferation of unregistered URL schemes with clashing namespaces? The ESW Wiki notes why this would be bad.
- And last, although this is nitpickier than the rest, I don't like the '%s' syntax used in the registration method. I'd much rather pass in an URL template, like the URL template used
in OpenSearch. If an URL template is used for matching rather than registering against a particular URL scheme, this could also allow for registering a namespace within a URN. For example
something along the lines of:
registerProtocolHandler("info:lccn/{lccnID}", "htttp://www.librarything.com/search_works.php?q={lccnID}", "LibraryThing LCCN")
url template registerprotocolhandler firefox technical url scheme protocol boring html5 uri urn
Some rights reserved