[Webkit-unassigned] [Bug 50608] New: Implement @uris and @alternateURIs

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 6 18:18:10 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=50608

           Summary: Implement @uris and @alternateURIs
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Enhancement
          Priority: P2
         Component: HTML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: brettz9 at yahoo.com


I earlier proposed two new attributes be added to HTML5, @uris and @alternateURIs
for the <a/> element and was told that I would need to gain experience with the feature through implementations first.

Custom protocols or URNs have very limited usefulness to a site which will do nothing for browsers not supporting the protocol when clicked. This proposal allows:

1) specification of a space-separated list of protocols to be tried first when clicking a link (<a
uris="..."/>), and failing that, falling back to 'href' (which will also work fine
in non-supporting browsers).

2) specification of a space-separated list of protocols (on <a alternateURIs="..."/>) 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.


Browser requirements:

1) Attempt space-separated URIs inside @uris before @href and falling back to @href upon a lack of recognition of the protocol (or possibly of its subnamespaces--see below).

2) When right-clicking on links which possessed the @alternateURIs attribute (or possibly also for links possessing the @uris attribute), allow the user to choose which URI they would like to attempt to follow.

3) Allow user control or default styling alteration for URIs on a page which were included inside @alternateURIs to make them aware of the right-click options available to them (and possibly also for links using @uris).


Browser options:

1) The browser might promote temporary attributes to formally encourage experimentation (e.g., @webkit_uris?)

2) An interface could be provided to allow management of registered protocols, including the ability to register sites oneself (e.g., pointing to a URL with wildcard substitution, to say redirect urn:isbn links to Amazon, Google Books, Wikisource/Wikipedia, etc.)


Use cases:

1) the @uris attribute might be of interest when the site aims to allow testing of rarer protocols like xmpp: while also allowing 'href' for fallback (whether as a link or allowing the 'href' or 'onclick' to provide JavaScript to provide an alert informing the user of how they could gain support for the intended protocol).

2) Sites devising their own categorization mechanism could register for a protocol using the HTML5 registerProtocol() method, and then consumers who wished to be neutral in their alignment (or more durable for the future) could supply this protocol in the @uris attribute. This would encourage immediate experimentation with such links, while still allowing fallback behavior to @href (e.g., to a popular implementer). For example, one might make an encyclopedic protocol (pedia:Existentialism) for linking to encyclopedic articles in a generic way (according to user registered preference) but provide a fallback to say the Wikipedia page on Existentialism in the 'href'.

3) The @alternateURIs attribute might be of interest to sites which did not want to reroute the normal functioning of their internal links to other sites but still wished to offer quck alternatives (e.g., if Wikipedia wished links to ISBN numbers to lead by default to their own internal ISBN pages while still allowing easy and immediate right-click forwarding of the link to say a bookstore or to the ISBN URN).


Supportive functionality

1) While this would be another feature request, allowing an additional argument to registerProtocol for allowing sites to register themselves only for a subnamespace of a protocol (e.g., "isbn" for the "urn" protocol) would further enrich experimentation with generic identifiers. Currently, the website accepts a willingness to handle the entire protocol even if they may have only been designed to handle one namespace of the protocol.

2) In line with #1, design a protocol which was similar to URNs in allowing subnamespaces, but which allowed IRIs/URIs to be used to reference a website for namespacing purposes (e.g., xrn://sns1/sns2&ns=http://mysite.example.com). This would allow fully extensible experimentation with custom categorization systems and selective handling of its subnamespaces, without the potential for name conflicts as custom URNs could easily lead to. As with #1, registerProtocol() could ideally request permission to handle only one or some subnamespaces.

Security Concerns

1) For sites allowing user input and using the already unsafe attribute blacklisting approach, the @uris feature in particular could allow users to add links pointing to unapproved sites.


Existing implementations

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

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list