Re: MediaStreams and src attributes

A spec related question:

Using creatObejctURL is straightforward since the natural place to 
document is in the document that defines MediaStreams (which is 
developed by this TF).

But if we add something like a "srcStream" (or whatever it would be 
named) property to the media element, would that be documented in the 
MediaStream document (as an extension to the media element), or is it 
something that should go into the html5 document?

Stefan

On 08/22/2012 07:25 PM, Adam Barth wrote:
> Eric Rescorla mentioned to me in Firefox you can directly assign a
> MediaStream to the src property of a media element.  I had assumed
> that meant Firefox was implicitly calling createObjectURL in order to
> serialize the MediaStream into a DOMString that could be represented
> in the src attribute of the media element.  However, according to some
> experiments and to
> <http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0036.html>,
> what's actually going on is that assigning a MediaStream to the src
> property stops that property from reflecting the underlying DOM
> attribute.
>
> The main problem with this approach is that it breaks the semantics of
> the src property.  Previously, the src property of HTMLMediaStream was
> a normal reflection property, like countless other reflection
> properties throughout the DOM, including many commonly used src
> properties on other DOM interfaces.  This is problematic for two
> reasons:
>
> 1) Breaking the reflection semantics of the src property just for
> HTMLMediaElement is inconsistent with how the rest of the DOM works.
> It's unclear why HTMLMediaElement should have a special, magical src
> property that works different from the src properties of
> HTMLImageElement, HTMLScriptElement, HTMLIFrameElement, etc, etc, etc.
>   For example, Anne van Kesteren has argued (in a slightly different
> context) "the more we tear down what little consistency is left, the
> harder it will be for people to learn and fully grasp what exactly it
> is we have here." [1]
>
> 2) In working with web developers, I've often found that many people
> do not have a clear conceptual model of the difference between
> reflection properties and DOM attributes.  They use the two
> interchangeably and don't really conceptualize them as separate
> concepts.  I take that to be a success of the reflection mechanism: it
> works so seamlessly that folks don't need to worry about it.  Breaking
> the reflection semantics in this case will confuse and frustrate these
> developers because they won't understand why assigning to the src
> property works but setting the src attribute does not.
>
> If you agree with me that we shouldn't break the reflection semantics
> of the src attribute, there appear to be at least two alternatives:
>
> A) Instead of breaking the src property, we can introduce a new
> property, for example "stream", with the type MediaStream.  Rather
> than assigning to the src property, developers would instead assign to
> the stream property, which would not have reflection semantics.
>
> B) We can serialize the MediaStream into a DOMString so that it can be
> reflected into the src attribute.  As discussed previously, we
> wouldn't want this serialization to be implicit because we want to
> help developers avoid resource leaks.  The natural approach here is to
> use createObjectURL to explicitly serialize the MediaStream into a
> URL, which can then be assigned to the src property and reflected into
> the src attribute.
>
> Adam
>
> [1] http://annevankesteren.nl/2011/02/web-platform-consistency
>

Received on Thursday, 23 August 2012 07:25:40 UTC