EME: Rendering behavior undefined

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