[whatwg] Registering protocol handlers

[Christian Biesinger]

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)
> 
> Added.

Thanks.

> 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.

Yeah, indeed.

>> Let me ask you: Does a spec with this many unspecified details satisfy 
>> you?
> 
> 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 
> 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)

> 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 
removed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4762 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20060424/b15d1a57/attachment-0001.bin>