- From: <bugzilla@jessica.w3.org>
- Date: Wed, 08 May 2013 22:01:52 +0000
- To: public-html-media@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 on the CC list for the bug.
Received on Wednesday, 8 May 2013 22:01:54 UTC