- From: Mounir Lamouri <notifications@github.com>
- Date: Tue, 06 Mar 2018 05:34:49 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/218/370782559@github.com>
> The S&P questionnaire link in the original review request seems to be a 404, could you clarify on this? https://github.com/WICG/media-capabilities/blob/master/security-privacy-questionnaire.md I believe the link is working. Maybe GH had troubles when you tried? > Web Audio and channels As mentioned in the spec, `channels` is still a placeholder and we do not currently use it in Chrome's implementation. I have filed https://github.com/WICG/media-capabilities/issues/73 to make it clearer. > The content mime type would most likely require additional parsing from each application that uses this - would it make sense to provide this in structured data to make it easier to use? I'm not entirely sure what you meant by this. Specifically, what you mean by "additional parsing from each application". I would expect web applications to copy-paste the type in their code or read it directly from a manifest of some sort. > A normative definition of what defines a screen change (or a reference back to a normative definition) would be helpful. As mentioned below, only part 2 of the spec is something we are launching in Chrome. Part 3 is more draft-y and most of it was or will be merged into a CSS spec. This will likely be the case with the change event if it ever happens. > Minor question 1: The explainer example code seems to suggest that the screen color depth is a string (the spec is missing a definition for this though) - is there any particular reason for this decision? Color depth changes we had were merged into the appropriate CSS spec. I believe 3.3 is a leftover from a removel. I've filed https://github.com/WICG/media-capabilities/issues/74 > Minor question 2: The explainer touches on HDCP - but that isn't on the spec. Wouldn't the approach in the explainer break when a user launches the content on a HDCP capable screen, starts playback, then drag it into a non-HDCP capable screen? HDCP was split into another specification with a brief explainer in the directory. It will be an extension of EME. Your point about EME and screen changes is correct though I believe CDM might deal with this. The screen change event would be another way but the intent of this event is larger and could be fired when the screen size has changed. > Since it is unclear exactly what from the spec is shipping - would you mind sharing the CL that relates to the I2S? That's a very good point. Part 2 is the one that is shipping in Chrome: https://wicg.github.io/media-capabilities/#decoding-encoding-capabilities -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/218#issuecomment-370782559
Received on Tuesday, 6 March 2018 13:35:11 UTC