[whatwg] Registering protocol handlers
cbiesinger at web.de
Mon Apr 24 14:27:17 PDT 2006
Ian Hickson wrote:
> So, like, the address in the following HTML:
> ...would be invalid? Or not? That changed when the IRI spec came out. I'm
> not sure you can guarentee that a URI will always be invalid.
I see your point, and it makes sense. What I meant, kind of, was whether
a failure calling nsIIOService::newURI, in Mozilla code, should cause an
exception to be thrown here, but that is clearly not wording the spec
can use :-)
But the solution you picked is fine.
>> Anyway, I wonder if it's worth mentioning that malformed URIs should
>> never cause an exception to be thrown? (other than lack of %s of course)
> I think that would be a very dangerous option. But in any case, consider
> the case for a download today -- you can set the default to always be a
> particular app when you download a file, so how do you change the default?
> IMHO it would be in the same place.
Mmm, good point. OK.
>> 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?
> Clearly people will, if you did. :-)
> I've changed it to:
> User agents may, within the constraints described in this
> seciton, do whatever they like [...]
Thank you, that sounds much better (except for the typo :) but that
seems to be in the email only, not in the spec).
> 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.
> I don't see how we can require a certain UI. User Interface is how
> browsers differentiate from each other.
>> Let me ask you: Does a spec with this many unspecified details satisfy
> Yes, I wouldn't have written it otherwise. :-)
> 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
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)
> Specs don't say how, e.g., <select> elements should work, other than the
> fact that they should offer certain options. Whether it's control-click or
> command-click or whether it's a drop down or a list or whether it's a
> pop-up, is all up to the UA. You can't require a particular UI, because
> some applications (e.g. EmacsSpeak) have radically different UIs than
> others (e.g. Opera on a cell phone).
Sure. I didn't mean that you should suggest a particular UI, although it
may have sounded like I did. But, because it can't specify the UI, the
spec leaves out important information IMO.
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 happy with registerContentHandler at all.
> I'm not sure how to address your issues. What text would you like to see
> be added to the spec?
Well. What I would _like_ is not something you will like, I suspect...
What I would like is the specification of registerContentHandler to be
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4762 bytes
Desc: S/MIME Cryptographic Signature
More information about the whatwg