- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Tue, 14 Jan 2014 13:56:34 -0800
- To: Hans Schmucker <hansschmucker@gmail.com>
- Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
> 6. It is inaccessible to any other web apis. No CSS filters, > SVG Filters, transformations, zoom controls and so on affect it I am not sure this will be true for all combinations of content, CDM implementation and UA. More generally, I would think that, independently of EME, not all UAs will implement all "CSS filters, SVG Filters, transformations, zoom controls" for all types of content and/or objects. If so, isn't the question of determining the capabilities supported by a UA for a given content broader than EME? Does such a mechanism exist in HTML 5 (loosely speaking)? Thanks, -- Pierre On Fri, Jan 10, 2014 at 6:18 AM, Hans Schmucker <hansschmucker@gmail.com> wrote: > Reading through the current specification, it is pretty obvious that > rendering the decrypted content may have different results if any of these > change: surrounding web content, CDC module or user agent. This pretty much > eliminates the need for any standard at all, since the result is entirely > unpredictable, unless you control all three variables. Any combination of > these would have to be tested and certified individually. > > The current text only explains what is likely to happen (2.3), based on > experience from previous plugin-APIs, but it does not define an expected > behavior, not even one that is in line with what we think is most likely to > happen. EME is a practical standard, driven by a specific need, but that > doesn't have to mean that it's a bad one. > > I suggest that we define a rendering behavior and do make it normative. > Some ideas: > > 1. EME-protected content rendering happens in a separate frame, which > overlays any HTML, SVG or other content that the user-agent may be able to > process. However, a user-agent may display its own controls above the > EME-protected content. > > 2. EME-protected content is not clipped, except against the primary viewport > (not, for example, that of an iframe). The area of the EME-protected element > is defined as the rectangle (as the defined by the HTML box model) occupied > by the element. > > 3. The Coordinates that define the EME-protected rendering area are derived > from the VIDEO element. However the transformation is not applied on a > visual basis, meaning that for example an SVG offset filter would not play > into the calculation. The result is identical to the result of > getBoundingClientRect. > > 4. EME-protected content is not transparent. The user-agent must fill the > area with solid black first. > > 5. Rendering happens in content-order. Where two EME-protected elements > overlap, the last element will be shown. > > 6. It is inaccessible to any other web apis. No CSS filters, SVG Filters, > transformations, zoom controls and so on affect it > > 7. Even if the user-agent is tasked with rendering the image, the behavior > remains unchanged. > > Of course, that's not up to spec-standards yet. Just ideas to fix an issue > that, in my opinion, tremendously diminishes the value of the standard. Any > comments? > > --hans
Received on Tuesday, 14 January 2014 21:57:22 UTC