Re: [whatwg] Some media element details
Ian Hickson wrote: On Mon, 6 Oct 2008, Bonner, Matt wrote: the original proposal said: var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY you appear to be proposing: var playing = !video.paused video.readyState = HTMLMediaElement.CAN_PLAY which only leaves the video.ended state in question. It's redundant -- the readyState can never be HAVE_FUTURE if there is no future (as is the case if the playback has ended). Okay, makes sense. thanks, Matt -- Matt Bonner Hewlett-Packard Company smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Some media element details
The pause button should switch to Replay when playback has ended. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bonner, Matt Sent: Tuesday, October 07, 2008 1:51 AM To: Ian Hickson Cc: [EMAIL PROTECTED]; Antti Koivisto Subject: Re: [whatwg] Some media element details If video.ended is true, what happens to video.readyState ? Because if the video ends, I think most page authors would want buttons like pause to be disabled. No? Matt -- Matt Bonner Hewlett-Packard Company
Re: [whatwg] Some media element details
Ok I totally lost this thread, sorry. Ian Hickson wrote: On Fri, 23 May 2008, Bonner, Matt (IPG) wrote: Knowing if the playback is progressing is necessary for implementing basic playback UIs with JS. It is clumsy and not very obvious that you need to do var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY to get this information. What's the use case? Wouldn't you want something like that to know, for example, whether to display a play or a pause button? We have that -- the paused attribute. When it's true, show play, and when it's paused, show false. You don't want to show play when the reason you aren't playing is that you're buffered or seeking for instance. The client is trying to play. It can't. Well I said for example, so let's pick another example. Wouldn't you need the state described to figure out whether enabling the pause/fast-forward/rewind buttons makes sense? Why would you disable the pause button when playing? Or when seeking? The pause button's disable state, as far as I can tell, need only be related to whether there is any media at all and whether the media playback is paused, not whether it is actively playing. Similarly for fast-forward. You can fast-forward from the paused state and from the playing state. It doesn't matter whether the media is actually playing or not. the original proposal said: var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY you appear to be proposing: var playing = !video.paused video.readyState = HTMLMediaElement.CAN_PLAY which only leaves the video.ended state in question. If video.ended is true, what happens to video.readyState ? Because if the video ends, I think most page authors would want buttons like pause to be disabled. No? Matt -- Matt Bonner Hewlett-Packard Company smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Some media element details
The _function_ performed by the play/pause button is reciprocally correlated; OTOH, its _interactivity_ (whether enabled) can be related to playback state. Not that I like this overprotective design. HTH, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, June 12, 2008 2:36 AM To: Antti Koivisto Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Some media element details The state of a play/pause button is definitely not correlated to the playback state. It's correlated to the paused boolean.
Re: [whatwg] Some media element details
On Fri, 16 May 2008, Antti Koivisto wrote:
[It would be nice to have a read-only attribute (called playing for
example) that would be true when the element is actively playing.
Knowing if the playback is progressing is necessary for implementing
basic playback UIs with JS. It is clumsy and not very obvious that you
need to do var playing = !video.paused !video.ended
video.readyState = HTMLMediaElement.CAN_PLAY to get this information.]
For example a simple playing state indicator:
function updatePlayState() {
var playIndicator = document.getElementById(playIndicator);
var playing = !video.paused !video.ended video.readyState =
HTMLMediaElement.CAN_PLAY;
playIndicator.className = playing ? playing : stopped;
}
video.addEventListener(play, updatePlayState);
video.addEventListener(pause, updatePlayState);
video.addEventListener(ended, updatePlayState);
video.addEventListener(waiting, updatePlayState);
I don't think I've ever seen a video player that shows this indicator.
Could you show me an example of a video player UI that does this?
Knowing whether media is playing or not is needed for other common UI elements
too, for example to activate/deactivate time display timer,
I don't think the visibility of the time display timer in a typical video
UI is actually directly correlated to the playback state. Again, could you
show an example of this?
to do play/pause button etc.
The state of a play/pause button is definitely not correlated to the
playback state. It's correlated to the paused boolean.
A direct way to get this information (along with an associated event)
would be good for API usability I think:
function updatePlayState() {
var playIndicator = document.getElementById(playIndicator);
playIndicator.className = video.activelyPlaying ? playing :
stopped;
}
video.addEventListener(playstatechanged, updatePlayState);
Of course it is sort of syntactical sugar...
It's syntactical sugar for something which, in practice, I don't think
anyone would actually use.
If you know of any examples of video players that actually would (if
reimplemented in HTML) make use of this, though, that would be a different
matter.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some media element details
On Fri, 16 May 2008, James Justin Harrell wrote: The current HTMLMediaElement interface is inconsistent and is designed in such a way that making changes to it will be extremely difficult. The network state is given by the networkState attribute, and is one of: EMPTY, LOADING, LOADED_METADATA, LOADED_FIRST_FRAME, LOADED The ready state is given by the readyState attribute, and is one of: DATA_UNAVAILABLE, CAN_SHOW_CURRENT_FRAME, CAN_PLAY, CAN_PLAY_THROUGH Although adding states for either of these would not be fun, it could be done. But the playback state is different. The consistent and upgradeable design would be to have a playbackState attribute that is one of: PAUSED, PLAYING But because there are currently only two states, we instead have a single boolean attribute. Boolean attributes are great when you're sure there will always be only two states, but they're terrible if there's a chance you'll want to add additional states. It isn't difficult to imagine all kinds of additional playback states. For example, what if there was great demand for forward-seeking and backward-seeking states? (e.g. the states that are usually associated with those and buttons) How could those states be added? This is already supported, and is independent of the pause state. (You could easily imagine a UI where you could pause while fast-forwarding.) The media error state is also inconsistent, and this time for no apparent reason, although it would at least be easy to update. A more consistent design would be to have an errorState attribute that is one of: NO_ERROR, ABORTED, NETWORK_ERROR, DECODING_ERROR We want to be able to include much more information, hence the use of an object for now. And why are the error state names prefixed with MEDIA_ERR when the names for the other states are not prefixed? e.g. LOADING instead of MEDIA_NET_LOADING. The other state constants are prefixed (LOAD and CAN_ respectively) except for the zero state (which doesn't have a constant at all for errors). On Fri, 16 May 2008, Maciej Stachowiak wrote: But because there are currently only two states, we instead have a single boolean attribute. Boolean attributes are great when you're sure there will always be only two states, but they're terrible if there's a chance you'll want to add additional states. I'm not sure adding states is all that safe. Any code that does a switch on the state would now fall through to an untested code path. Indeed, we're unlikely to ever add states, we're more likely to add orthogonal attributes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some media element details
On Fri, 23 May 2008, Bonner, Matt (IPG) wrote: Knowing if the playback is progressing is necessary for implementing basic playback UIs with JS. It is clumsy and not very obvious that you need to do var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY to get this information. What's the use case? Wouldn't you want something like that to know, for example, whether to display a play or a pause button? We have that -- the paused attribute. When it's true, show play, and when it's paused, show false. You don't want to show play when the reason you aren't playing is that you're buffered or seeking for instance. The client is trying to play. It can't. Well I said for example, so let's pick another example. Wouldn't you need the state described to figure out whether enabling the pause/fast-forward/rewind buttons makes sense? Why would you disable the pause button when playing? Or when seeking? The pause button's disable state, as far as I can tell, need only be related to whether there is any media at all and whether the media playback is paused, not whether it is actively playing. Similarly for fast-forward. You can fast-forward from the paused state and from the playing state. It doesn't matter whether the media is actually playing or not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some media element details
Ian wrote: Knowing if the playback is progressing is necessary for implementing basic playback UIs with JS. It is clumsy and not very obvious that you need to do var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY to get this information. What's the use case? Wouldn't you want something like that to know, for example, whether to display a play or a pause button? We have that -- the paused attribute. When it's true, show play, and when it's paused, show false. You don't want to show play when the reason you aren't playing is that you're buffered or seeking for instance. The client is trying to play. It can't. Well I said for example, so let's pick another example. Wouldn't you need the state described to figure out whether enabling the pause/fast-forward/rewind buttons makes sense? Matt -- Matt Bonner Hewlett-Packard Company -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Friday, May 16, 2008 3:20 PM To: Bonner, Matt (IPG) Cc: [EMAIL PROTECTED]; Antti Koivisto Subject: Re: [whatwg] Some media element details On Fri, 16 May 2008, Bonner, Matt (IPG) wrote: On Mon, 14 Jan 2008, Ian Hickson wrote: On Mon, 14 Jan 2008, Antti Koivisto wrote: It would be nice to have a read-only attribute (called playing for example) that would be true when the element is actively playing. Knowing if the playback is progressing is necessary for implementing basic playback UIs with JS. It is clumsy and not very obvious that you need to do var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY to get this information. What's the use case? Wouldn't you want something like that to know, for example, whether to display a play or a pause button? We have that -- the paused attribute. When it's true, show play, and when it's paused, show false. You don't want to show play when the reason you aren't playing is that you're buffered or seeking for instance. The client is trying to play. It can't. -- Ian Hickson U+1047E )\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Some media element details
On Mon, 14 Jan 2008, Ian Hickson wrote: On Mon, 14 Jan 2008, Antti Koivisto wrote: It would be nice to have a read-only attribute (called playing for example) that would be true when the element is actively playing. Knowing if the playback is progressing is necessary for implementing basic playback UIs with JS. It is clumsy and not very obvious that you need to do var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY to get this information. What's the use case? Wouldn't you want something like that to know, for example, whether to display a play or a pause button? Matt -- Matt Bonner Hewlett-Packard Company smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Some media element details
On Fri, 16 May 2008, Bonner, Matt (IPG) wrote: On Mon, 14 Jan 2008, Ian Hickson wrote: On Mon, 14 Jan 2008, Antti Koivisto wrote: It would be nice to have a read-only attribute (called playing for example) that would be true when the element is actively playing. Knowing if the playback is progressing is necessary for implementing basic playback UIs with JS. It is clumsy and not very obvious that you need to do var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY to get this information. What's the use case? Wouldn't you want something like that to know, for example, whether to display a play or a pause button? We have that -- the paused attribute. When it's true, show play, and when it's paused, show false. You don't want to show play when the reason you aren't playing is that you're buffered or seeking for instance. The client is trying to play. It can't. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some media element details
On 14.5.2008, at 23:37, Ian Hickson wrote:
It would be nice to have a read-only attribute (called playing for
example) that would be true when the element is actively playing.
Knowing if the playback is progressing is necessary for implementing
basic playback UIs with JS. It is clumsy and not very obvious that
you
need to do var playing = !video.paused !video.ended
video.readyState = HTMLMediaElement.CAN_PLAY to get this
information.
What's the use case?
For example a simple playing state indicator:
function updatePlayState() {
var playIndicator = document.getElementById(playIndicator);
var playing = !video.paused !video.ended video.readyState =
HTMLMediaElement.CAN_PLAY;
playIndicator.className = playing ? playing : stopped;
}
video.addEventListener(play, updatePlayState);
video.addEventListener(pause, updatePlayState);
video.addEventListener(ended, updatePlayState);
video.addEventListener(waiting, updatePlayState);
Knowing whether media is playing or not is needed for other common UI
elements too, for example to activate/deactivate time display timer,
to do play/pause button etc. A direct way to get this information
(along with an associated event) would be good for API usability I
think:
function updatePlayState() {
var playIndicator = document.getElementById(playIndicator);
playIndicator.className = video.activelyPlaying ? playing :
stopped;
}
video.addEventListener(playstatechanged, updatePlayState);
Of course it is sort of syntactical sugar...
It might also be good to explicitly state that exceptions are
ignored.
Which exceptions?
Yeah, after the change to check for EMPTY networkState there are no
longer any exceptions to could occur with the current algorithm.
antti
Re: [whatwg] Some media element details
The current HTMLMediaElement interface is inconsistent and is designed in such
a way that making changes to it will be extremely difficult.
The network state is given by the networkState attribute, and is one of:
EMPTY, LOADING, LOADED_METADATA, LOADED_FIRST_FRAME, LOADED
The ready state is given by the readyState attribute, and is one of:
DATA_UNAVAILABLE, CAN_SHOW_CURRENT_FRAME, CAN_PLAY, CAN_PLAY_THROUGH
Although adding states for either of these would not be fun, it could be done.
But the playback state is different.
The consistent and upgradeable design would be to have a playbackState
attribute that is one of:
PAUSED, PLAYING
But because there are currently only two states, we instead have a single
boolean attribute. Boolean attributes are great when you're sure there will
always be only two states, but they're terrible if there's a chance you'll want
to add additional states.
It isn't difficult to imagine all kinds of additional playback states. For
example, what if there was great demand for forward-seeking and
backward-seeking states? (e.g. the states that are usually associated with
those and buttons) How could those states be added?
The media error state is also inconsistent, and this time for no apparent
reason, although it would at least be easy to update. A more consistent design
would be to have an errorState attribute that is one of:
NO_ERROR, ABORTED, NETWORK_ERROR, DECODING_ERROR
And why are the error state names prefixed with MEDIA_ERR when the names for
the other states are not prefixed? e.g. LOADING instead of MEDIA_NET_LOADING.
If NO_ERROR was given a value of 0, testing for an error with this design
wouldn't be any more difficult.
if( videoElement.error ) {...}
if( videoElement.errorState ) {...}
- Original Message
Wouldn't you want something like that to know, for example, whether to
display a play or a pause button?
We have that -- the paused attribute. When it's true, show play, and
when it's paused, show false. You don't want to show play when the reason
you aren't playing is that you're buffered or seeking for instance. The
client is trying to play. It can't.
Re: [whatwg] Some media element details
On May 16, 2008, at 9:29 PM, James Justin Harrell wrote:
The current HTMLMediaElement interface is inconsistent and is
designed in such a way that making changes to it will be extremely
difficult.
The network state is given by the networkState attribute, and is
one of:
EMPTY, LOADING, LOADED_METADATA, LOADED_FIRST_FRAME, LOADED
The ready state is given by the readyState attribute, and is one of:
DATA_UNAVAILABLE, CAN_SHOW_CURRENT_FRAME, CAN_PLAY, CAN_PLAY_THROUGH
Although adding states for either of these would not be fun, it
could be done. But the playback state is different.
The consistent and upgradeable design would be to have a
playbackState attribute that is one of:
PAUSED, PLAYING
But because there are currently only two states, we instead have a
single boolean attribute. Boolean attributes are great when you're
sure there will always be only two states, but they're terrible if
there's a chance you'll want to add additional states.
I'm not sure adding states is all that safe. Any code that does a
switch on the state would now fall through to an untested code path.
It isn't difficult to imagine all kinds of additional playback
states. For example, what if there was great demand for forward-
seeking and backward-seeking states? (e.g. the states that are
usually associated with those and buttons) How could those
states be added?
Then you would treat the video as playing, and the playback rate as
different than 1.0.
The media error state is also inconsistent, and this time for no
apparent reason, although it would at least be easy to update. A
more consistent design would be to have an errorState attribute
that is one of:
NO_ERROR, ABORTED, NETWORK_ERROR, DECODING_ERROR
The type of error is not a state. There is no state transition that
will move you from one to the other. An error is something that
happened. There could however be a type of error that you reached.
- Maciej
And why are the error state names prefixed with MEDIA_ERR when the
names for the other states are not prefixed? e.g. LOADING instead of
MEDIA_NET_LOADING.
If NO_ERROR was given a value of 0, testing for an error with this
design wouldn't be any more difficult.
if( videoElement.error ) {...}
if( videoElement.errorState ) {...}
- Original Message
Wouldn't you want something like that to know, for example, whether
to
display a play or a pause button?
We have that -- the paused attribute. When it's true, show play, and
when it's paused, show false. You don't want to show play when the
reason
you aren't playing is that you're buffered or seeking for instance.
The
client is trying to play. It can't.
Re: [whatwg] Some media element details
On Mon, 14 Jan 2008, Antti Koivisto wrote: Some comments about the media elements: 3.14.9.4. Loading the media resource The user agent must then set the begun flag to true and fire a progress event called begin at the media element. The progress event draft calls this event loadstart (and occasionally start, that spec is not very consistent). No matter which name is chosen, it would be nice if it was same everywhere. Fixed. 3.14.9.7. Playing the media resource It is not entirely clear from descriptions of play() and pause() if the timeupdate, ratechange, play and paused events should all be fired asynchronously, though I assume that is the idea. Fixed. It would be nice to have a read-only attribute (called playing for example) that would be true when the element is actively playing. Knowing if the playback is progressing is necessary for implementing basic playback UIs with JS. It is clumsy and not very obvious that you need to do var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY to get this information. What's the use case? When a media element is removed from a Document, the user agent must act as if the pause() method had been invoked. Calling pause() will invoke load() in case the network state is EMPTY. This seems like wrong thing to do on remove. The above should be modified to invoke pause() only if the network state is greater than EMPTY. Fixed. It might also be good to explicitly state that exceptions are ignored. Which exceptions? 3.14.9.8. Seeking 3. If currentLoop is equal to the value of playCount, let... Should be equal to the value of playCount - 1. Fixed. As soon as the user agent has established whether or not the media data for the new playback position is available, and, if it is, decoded enough data to play back that position, the seeking DOM attribute must be set to false. There is no event of any kind associated with seeking attribute becoming false which makes it difficult to react to changes in seeking state. It might be a good idea to fire a timeupdate here. I've added 'seeking' and 'seeked' events. ... notwithstanding the looping attributes (i.e. the effective start and effective end, etc, don't affect the seeking attribute). Should be don't affect the seekable attribute. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
