- From: <bugzilla@jessica.w3.org>
- Date: Wed, 08 May 2013 22:01:52 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21977 Bug ID: 21977 Summary: Swap isTypeSupported() parameter order so keySystem is first Classification: Unclassified Product: HTML WG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Encrypted Media Extensions Assignee: adrianba@microsoft.com Reporter: ddorwin@google.com QA Contact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-media@w3.org 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 -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 8 May 2013 22:01:53 UTC