RE: MediaStreams and src attributes

> From: Adam Barth [mailto:w3c@adambarth.com]
> 
> 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.

+1

Agree with everything here. Note that the current spec [1] does not define the direct-assignment in the way that implementors have chosen. I'd strongly recommend that existing implementations of this approach be updated to adhere to the current draft spec.

[1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html

Received on Wednesday, 22 August 2012 18:49:03 UTC