This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The current draft has isTypeSupported(type, keySystem). The parameter order was carried over from the overloading of canPlayType(), where the first parameter was already defined, in v0.1b. On one hand, the order makes sense: * The noun in the method name is "Type", which is the first parameter. * The first parameter is the same as MSE's isTypeSupported() method [1] However, it seems much more likely applications would want to query |keySystem| without |type| than vice versa^. The examples [2] show how querying just the |keySystem| strangely requires passing null as the first parameter: MediaKeys.isTypeSupported(null, "com.example.somesystem") If we don't need to support querying just |type|, we could require at least one parameter, simplifying implementations, and support the above query as: MediaKeys.isTypeSupported("com.example.somesystem") The check a combination, an application would call: MediaKeys.isTypeSupported("com.example.somesystem", mimeType) ^ Would applications ever want to query just |type| to determine if the UA supports encrypted content of that type without checking the key system? It seems applications would want to find supported key system(s) then check supported types for those key system(s). [1] https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#widl-MediaSource-isTypeSupported-boolean-DOMString-type [2] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-istypesupported
> ^ Would applications ever want to query just |type| to determine if the UA > supports encrypted content of that type without checking the key system? It > seems applications would want to find supported key system(s) then check > supported types for those key system(s). Wouldn't the MSE version of isTypeSupported work fine for this? Or do you anticipate that the UA will support the video format but just not the encrypted version? It seems to me that the UA will not send a needkey if it does not recognize the format. I think your reasoning is sound - I would be fine with this change.
(In reply to comment #1) > > ^ Would applications ever want to query just |type| to determine if the UA > > supports encrypted content of that type without checking the key system? It > > seems applications would want to find supported key system(s) then check > > supported types for those key system(s). > > Wouldn't the MSE version of isTypeSupported work fine for this? Or do you > anticipate that the UA will support the video format but just not the > encrypted version? It seems to me that the UA will not send a needkey if it > does not recognize the format. Yes, we should allow UAs to support formats via .src or MSE without supporting decryption of such formats. isTypeSupported() is likely to be called before media is provided, so relying on needkey will not work.
As agreed in the May 21st telecon, I will make this change.
As discussed in the May 21st telecon, the parameters have been swapped: https://dvcs.w3.org/hg/html-media/rev/85fbfad2339e