W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2012

MediaStreams and src attributes

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 22 Aug 2012 10:25:37 -0700
Message-ID: <CAJE5ia9j-TevwDa_a9b62EjwOSkjnX3yQFsh2Rdq=--qpai4BA@mail.gmail.com>
To: public-media-capture@w3.org
Cc: "Robert O'Callahan" <robert@ocallahan.org>, Anant Narayanan <anant@mozilla.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.

Adam

[1] http://annevankesteren.nl/2011/02/web-platform-consistency
Received on Wednesday, 22 August 2012 17:26:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:01 GMT