Ian Hickson wrote:
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.
Interesting point.
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.
OK. I still think that pages would like to know for what content exactly their registered handler will be used ...
I don't think you've yet said exactly what it is you think is missing.
... which is the part that I think is missing. It sounds like we're going in circles here though, since specifying that would mean requiring a certain UI.
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 think it is. Consider this sentence:"Analogously, the registerContentHandler() method allows Web sites to register themselves as handlers for content in a particular MIME type."
To me that sounds like "wants to handle (all) content of that type". I suppose the next sentence is trying to clarify this. But if that's not the meaning, I think the sentence should be clarified, although I can't think of a good wording at the moment.
smime.p7s
Description: S/MIME Cryptographic Signature
