On Fri, 11 May 2012, Simon Pieters wrote:
I'm still a bit skeptical about the utility of media source. Maybe it
should be dropped from the spec.
It is not appropriate for choosing between low resolution and high
resolution, because the environment can change (e.g. the user might
On Thu, 10 May 2012 23:03:15 +0200, Paul Adenot
padenot+wha...@mozilla.com wrote:
Currently implementing the media attribute of the source element in
Gecko, we are unsure about what the specification requires us to do
there.
Hixie has already replied, I just want to note that this is
On Fri, 11 May 2012 11:54:19 +0200, Philip Jägenstedt phil...@opera.com
wrote:
On Thu, 10 May 2012 23:03:15 +0200, Paul Adenot
padenot+wha...@mozilla.com wrote:
Currently implementing the media attribute of the source element in
Gecko, we are unsure about what the specification requires
On Fri, 11 May 2012 11:24:20 +0100, Simon Pieters sim...@opera.com wrote:
It is not appropriate for choosing between low resolution and high
resolution, because the environment can change (e.g. the user might
fullscreen the video after it has begun loading, and want high
resolution).
Currently implementing the media attribute of the source element in
Gecko, we are unsure about what the specification requires us to do there.
Considering this example :
video
source src=lowres.webm media=max-width:500px
source src=highres.webm
/video
what is the expected behavior of a
On Thu, 10 May 2012, Paul Adenot wrote:
The spec [1] says :
Dynamically modifying a source element and its attribute when the
element is already inserted in a video or audio element will have no
effect. To change what is playing, just use the src attribute on the
media element
As far as I can tell, the behaviour here is strictly and
unambiguously defined, leaving only one possible interpretation, so
it's not clear to me how to make it less ambiguous. Could you
elaborate on what interpretations of the spec you think are possible?
We have two possible
On Thu, 10 May 2012, Paul Adenot wrote:
As far as I can tell, the behaviour here is strictly and unambiguously
defined, leaving only one possible interpretation, so it's not clear
to me how to make it less ambiguous. Could you elaborate on what
interpretations of the spec you think
On Fri, 23 Mar 2007, Anne van Kesteren wrote:
I don't really like this element. The name is confusing especially with
an attribute named src=. It also introduces yet another void element,
can't we just reuse param? The value= attribute of param would
point to a resource and the type=
On Fri, 23 Mar 2007, Nicholas Shanks wrote:
How about:
playlistol
liaudio src=foo type=...Audio fallback/audio/li
livideo src=bar type=...Video fallback/video/li
/ol/playlist
User agents that don't support playlist, audio and video just get an ordered
list of fallback
I don't really like this element. The name is confusing especially with an
attribute named src=. It also introduces yet another void element, can't
we just reuse param? The value= attribute of param would point to a
resource and the type= attribute (which has been dropped) would be added
On 3/23/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
I don't really like this element. The name is confusing especially with an
attribute named src=. It also introduces yet another void element, can't
we just reuse param? The value= attribute of param would point to a
resource and the type=
On 23 Mar 2007, at 20:47, Maciej Stachowiak wrote:
I agree the repetition of source/src is a little weird.
and name the new element something like alt
I don't like abbreviations such as alt and src.
The use case is uncommon enough that alternate wouldn't be too much
of a burden to type and
Maciej Stachowiak wrote:
So to be sure I understand your proposal, you're suggesting that instead of
source type=audio/mpeg src=mysong.mp3
You'd say:
param type=audio/mpeg value=mysong.mp3
Why not call the element content instead of source? That way the src
and type attributes make more
On Fri, 23 Mar 2007 19:07:05 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
In this case, the browser shouldn't strip and normalizes the newlines
from the value attribute before passing to the plugin. (FF and IE
handle this nicely. They may do this only for the tcl plugin though.).
Per the
On Mar 23, 2007, at 2:26 PM, Nicholas Shanks wrote:
On 23 Mar 2007, at 20:47, Maciej Stachowiak wrote:
I agree the repetition of source/src is a little weird.
and name the new element something like alt
I don't like abbreviations such as alt and src.
The use case is uncommon enough that
On Fri, 23 Mar 2007 13:36:15 +0100, Anne van Kesteren [EMAIL PROTECTED]
wrote:
I don't really like this element. The name is confusing especially with
an attribute named src=. It also introduces yet another void element,
can't we just reuse param? The value= attribute of param would
On 3/23/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Fri, 23 Mar 2007 19:07:05 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
In this case, the browser shouldn't strip and normalizes the newlines
from the value attribute before passing to the plugin. (FF and IE
handle this nicely. They may
18 matches
Mail list logo
