Re: EME: Rendering behavior undefined

The second paragraph mainly. The first one is actually unnecessary (and
slightly incorrect) since HTML5 defines such behavior:

http://www.w3.org/TR/2dcontext/#drawing-images-to-the-canvas
"If the image argument is an HTMLImageElement object that is not fully
decodable (...) then the implementation must return without drawing
anything."

I guess it's "may", because it's up to each CDM to decide. Some CDMs may
allow drawing its content to Canvas.

Reading the minutes of the last meeting, it seems that there is consensus
that dealing with rendering is outside the scope of the EME spec, BUT they
don't want to remove that section unless it is actually handled somewhere
else (I hope I'm reading this correctly).

Dealing with layering, transforms and so on is quite a bit more complex and
very likely outside the scope of HTML (certainly EME). Problem is that the
general fallback logic used in all other W3C standards can not be applied
here (unsupported instructions are ignored and fall back to the behavior
defined in the last supported version of the standard).
DOMImplementation.hasFeature might be a way to go, but it's dubious as
well, since it would change depending on the content of the document and
the EME element currently in use.

So far, the only correct way seems to be defining an exception to each and
every standard saying something along the lines of "If ANY descendent does
not support the feature (for example 2D transforms), then the instruction
is ignored on any parent". And provide a way to check for such cases with
something like Node.allowsFeature(transform|opacity|alpha|...).

--hans


On Wed, Jan 15, 2014 at 11:21 AM, Henri Sivonen <hsivonen@hsivonen.fi>wrote:

> On Wed, Jan 15, 2014 at 12:07 AM, Hans Schmucker
> <hansschmucker@gmail.com> wrote:
> > So now, the first order of business is making sure that the EME spec does
> > not say anything about it, unlike what it currently does in the
> introduction
> > and 2.3.
>
> Hmm. The draft has two sections 2.3. I take it that you mean the
> latter one of them.
>
> Do you object only to "Where media rendering is not performed by the
> UA, for example in the case of a hardware protected media pipeline,
> then the full set of HTML rendering capabilities, for example CSS
> Transforms, may not be available. One likely restriction is that video
> media may be constrained to appear only in rectangular regions with
> sides parallel to the edges of the window and with normal
> orientation."?
>
> Or do you also object to: "Media data processed by a CDM may not be
> available through Javascript APIs in the usual way (for example using
> the CanvasRenderingContext2D drawImage() method and the AudioContext
> MediaElementAudioSourceNode). This specification does not define
> conditions for such non-availability of media data, however, if media
> data is not available to Javascript APIs then these APIs may behave as
> if no media data was present at all."?
>
> Question to the editors: Why is the last part I quoted saying "may" in
> the last sentence instead of "must" and why is it marked
> non-normative?
>
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/
>