[whatwg] Registering protocol handlers

[Ian Hickson]

On Mon, 24 Apr 2006, Christian Biesinger wrote:
> > > 
> > > I do suspect that this will lead to inconsistent UI. Some files will 
> > > go to the registered URL, some to the pre-existing handler (local 
> > > app or something). The user may have no idea why.
> > 
> > The same could be said today for clicking on a link. I'm all for 
> > making this better, but I don't see what the spec can do to help.
> 
> No, I disagree (about the "today" part). When you click the link, and it 
> links to a certain MIME type, you are always able to open that in your 
> preferred application, no?

The UI feels inconsistent to the user, though, because files that the user 
would assume to be equivalent have different MIME types. e.g. clicking on 
a file whose type is registered with Windows Media Player vs a type 
registered with QuickTime.


> > I think for this case the university should either offer a "private" 
> > URI that can be forwarded to the remote site (much like how Google 
> > Calendar has a "private URI" for your ICS file), or the user should 
> > download the file, go to the other site, and upload it.
> 
> Hmm... maybe... this requires special action on all sites that provide 
> content of this type though.

True. If this features is popular, sites will adapt, though, much like 
sites today have "Add To Bloglines" links.


> > This is not a UI spec -- this is a spec that is to ensure one thing 
> > and one thing only, namely that the same basic feature can be offered 
> > for any browser without having to browser-sniff.
> 
> I'm not even sure you can avoid that. If a page doesn't like how a 
> particular browser filled in the holes of the spec, it may well want to 
> avoid offering this feature to it. (All hypothetical, I know... but 
> there's just no browser that implements this yet or a page that uses it 
> yet)

But this doesn't affect the spec -- it would be up to the UA to change the 
way it implemented the UI so that page authors like it.

The spec is just there to make sure that if the page _does_ use the 
feature, it can do so in a way that will lead to predictable _server side_ 
results, independent of the user agent used.


> But, because it can't specify the UI, the spec leaves out important 
> information IMO.

I don't think you've yet said exactly what it is you think is missing.


> Now... maybe if you look at it like "Pages can tell the UA that they can 
> handle a type" instead of "Page wants to handle all content of a certain 
> type, or at least know what it can't handle" it's not so bad... But does 
> this suffice for pages? I have no idea.

I'm not sure what you're saying here. The API is just a way to say "I can 
handle this type", it's not a way of saying "I want to handle all content 
of this type". Is the spec misleading about this? Let me know if I can 
reword something to reduce the confusion here.


> > I'm not sure how to address your issues. What text would you like to 
> > see be added to the spec?
> 
> What I would like is the specification of registerContentHandler to be 
> removed.

It's not clear to me how removing the feature would help us address the 
request from Ben and others (i.e. how, without this feature, you would 
allow sites to let the UA know that they can support a content type).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'