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.
smime.p7s
Description: S/MIME Cryptographic Signature
