- From: Mihai Sucan <mihai.sucan@gmail.com>
- Date: Sun, 05 Aug 2007 23:42:21 +0300
- To: public-html <public-html@w3.org>
Hello!
I have reviewed the 3.14.9. "Media elements" section [1] and I have a few
corrections and suggestions to make.
1. Looking at the 3.14.9.2. "Location of the media resource" section [2]
one can read:
"*The src content attribute* on media elements gives the address of the
video to show."
I think the topic is wrong and confusing. This "error" is repeated in the
entire spec.
I have read 1.4. "Terminology" section [8] and I still think this should
be changed. The section does a good job in explaining what a "content
attribute" is, but when reading the spec, it's still confusing.
I would suggest using "markup attribute" or "element attribute" instead of
"content attribute".
2. In the same section, the same paragraph, another error:
"The src content attribute on media elements gives the address of the
*video* to show."
This is not the video element. It's the general media element definition.
3. "To pick a media resource for a media element, a user agent must
*follow the following* steps:"
Suggested correction:
"To pick a media resource for a media element, a user agent must implement
the following steps:"
4. The above error is repeated in the 3.14.9.4. "Loading the media
resource" section [3].
See step 14.
"DNS errors and HTTP 4xx and 5xx errors (and equivalents in other
protocols) must cause the user agent to *follow the following* steps."
Suggested correction:
"DNS errors and HTTP 4xx and 5xx errors (and equivalents in other
protocols) must cause the user agent to follow the steps provided below."
5. In the same section (3.14.9.4), at the same step (14), there's another
editorial error:
"If the media data can be downloaded but is in an unsupported format, or
can otherwise not be properly rendered *at all*"
There's a logical error. The media cannot be properly rendered, or the
media cannot be rendered at all.
Suggested correction:
Remove "at all".
6. In the same place, but in the next paragraph, two mistakes:
"The server returning a file of the wrong kind (e.g. one that that turns
out to not be pure audio when the media element is *a audio* element), or
the file using unsupported codecs for all the data, must cause the user
agent to *follow the following steps*."
Suggested corrections:
a audio = an audio
follow the following steps = follow the steps provided below
7. The next two cases which have substeps also contain the error "follow
the following steps".
8. "Should we fire a 'warning' event? Set the 'error' flag to
'MEDIA_ERR_SUBOPTIMAL' or something?"
Yes, the UA should fire a 'warning' event, such that the Web application
can take the required steps.
No, do not set any flag to 'error' because such cases are not pure errors.
They are just warnings.
9. I was thinking of a warning event for a slow connection (e.g. the media
data requires a faster network connection than the available one).
Watching Brightcove videos you are immediately alerted if the network
connection is slow. This could determine the Web application to provide a
media resource which requires less bandwidth.
10. In the 3.14.9.7. "Playing the media resource" section [5] there's an
editorial error:
"A media element is said to have stopped due to errors when the element's
networkState attribute is LOADED_METADATA or greater, and the user agent
*has encounters* a non-fatal error during the processing of the media
data, and due to that error, is not able to play the content at the
current playback position."
Suggested correction: "has encountered".
11. In the same section, there's a syntax error in the spec.
"When the pause() method is invoked, the user agent must run the following
steps:
...
If the second step above changed the value of paused, the user agent must
first fire a simple event called timeupdate at the element, and then fire
a simple event called *title="event-pause">pause* at the element."
Obviously, title="event-pause"> does not belong there.
12. In the same section, in the first step listed when the play() and the
pause() methods are invoked:
"If the media element's networkState attribute has the value EMPTY, then
the user agent must *sychronously* invoke the load() method. If that
raises an exception, that exception must be reraised by the play() method."
Suggested correction: synchronously.
13. There's a typo in the first paragraph, second phrase, of the
3.14.9.10. "User interface" section [6].
"This user interface should include features to begin playback, pause
playback, seek to an arbitrary position in the content (if the content
supports arbitrary seeking), change the volume, and *showe* the media
content in manners more suitable to the user (e.g. full-screen video or in
an independent resizable window)."
Suggested correction: "show".
14. The DOM event "volumechange" should not be fired when a media element
is muted/unmuted.
Currently the spec says this:
"Whenever either the muted or volume attributes are changed, after any
running scripts have finished executing, the user agent must fire a simple
event called volumechange at the media element."
Actually, the volume itself does not change when the media is
muted/unmuted.
The UA should fire a simple event called "mutetoggle" when the media is
muted/unmuted.
15. In the 3.14.9.11. "Time range" section [7] I suggest:
a) add the DOM method duration(index) which returns the duration in
seconds of the index-th range in the object.
Suggested definition:
"The duration(index) method must return the duration of the indexth range
represented by the object, in seconds by calculating end(index) -
start(index)."
b) add the DOM attribute totalDuration, which returns the sum of all range
durations.
Suggested definition:
"The totalDuration DOM attribute returns the sum of the duration of all
ranges represented by the object, in seconds."
A use case: IIANM, some video players show the total duration of buffered
video. Thus, totalDuration would be a much faster way to check the total
buffered time.
16. I suggest adding the "playing" DOM attribute which tells if the media
element is actively playing.
There's a serious need for such a simple attribute. Use case: I recently
(as in few months ago) worked with SVG animations. Looks like the SVG DOM
does not define a simple way to check if an animation is running on a
given element. I wanted to start an animation from JS only if it's not
already playing. The hack I used was this:
elem.isPlaying = false;
elem.addEventListener('beginEvent', function () { this.isPlaying = true;
}, false);
elem.addEventListener('endEvent', function () { this.isPlaying = false; },
false);
Obviously, this whole "boring" example is just to emphasize the real need
for a "playing" DOM attribute.
(I did check the spec, including the SMIL spec. I couldn't find anything.)
Checking if(!elem.paused) is not enough to be sure the video is playing,
since the definition of "actively playing" is more complex, in the spec.
Suggested definition, in the 3.14.9.7. "Playing the media resource"
section [5]:
Use case: given a web site like YouTube, the user clicks a video from the
playlist while a video is already playing. The site can check if the video
is playing or not, and ask the user for a confirmation. Of course this can
be done with the current spec, however, it's just like with the SVG spec -
it's lacking something as simple as a check if media is playing.
"The playing DOM attribute represents whether the media element is
actively playing or not. The attribute must initially be false."
17. The spec is missing the definition of a scriptable way to abort the
loading of the media element.
I recommend adding a new method called abortLoad(). Suggested definition:
"When the abortLoad() method is invoked on the media element, the user
agent must follow these steps:
1. If the element's begun flag is false, or if the networkState equals
EMPTY or LOADED, then raise the INVALID_STATE_ERR exception and abort
these steps. In other words, raise the mentioned exception if the media
resource is not loading.
2. If the element's begun flag is true, set it to false.
3. The error attribute must be set to a new MediaError object whose code
attribute is set to MEDIA_ERR_ABORTED.
4. Fire a progress event called abort at the media element.
5. Set the networkState to EMPTY.
Note: Now the currentSrc DOM attribute must return the empty string.
6. If the readyState is not DATA_UNAVAILABLE, then set it to that state.
7. The media element's autoplaying flag must be set to false.
8. If the paused attribute is false, it must be set to true.
9. If the playing attribute is true, it must be set to false.
10. If seeking is true, it must be set to false.
11. The current playback position must be set to 0.
12. The currentLoop DOM must be set to 0.
13. The user agent must synchronously fire a simple event called emptied
at the media element."
The need: In many cases users want to stop videos from downloading, not
only playing.
This brings me to something related...
18. If my understanding of the spec is correct, there's no way to stop
media elements from loading when the document is loaded.
(or no obvious way?)
In the 3.14.9.4. "Loading the media resource" section [3] we can read:
"If a media element whose networkState has the value EMPTY is inserted
into a document, user agents must implicitly invoke the load() method on
the media element as soon as all other scripts have finished executing.
Any exceptions raised must be ignored."
The networkState has the value EMPTY as default. This means that media
resources are automatically loaded on document load.
I suggest that autoplay also controls "autoload". That means if autoplay
is false, then the media is not loaded when the document is loaded, only
when play() is called. If autoplay is true, then the media is loaded and
played automatically when the document is loaded, just like now.
If this is the behaviour defined in the current spec, then, please try to
make it clear that media elements do not load on document load, unless
autoplay is set to true.
19. The spec does not define a way to stop media playback.
Currently, pause() is different from what stop() is in media players.
I agree stop() can be implemented by Web applications *but* this is a
simple native function that should be available by default (compare with
cue points, which are great, but seem rather complex for a first
definition of the media element).
Suggested definition:
"When the stop() method is invoked on the media element, the user agent
must follow these steps:
1. If the playing attribute is false, or if the networkState is EMPTY,
then raise the INVALID_STATE_ERR exception and abort these steps.
2. Fire a simple event called stop at the media element.
3. The media element's autoplaying flag must be set to false.
4. If the paused attribute is false, it must be set to true.
5. If the playing attribute is true, it must be set to false.
6. If seeking is true, it must be set to false.
7. The current playback position must be set to 0.
8. The currentLoop DOM must be set to 0."
20. The spec does not define what happens if the src attribute changes
(the markup attribute and the DOM attribute).
Does the media element stop playing and loads the new media data? Or
nothing happens until you call load() again?
I suggest adding a section labelled "Changing the media resource", maybe
before the 3.14.9.8. "Seeking" section [10].
"3.14.9.8. Changing the media resource
If the src DOM attribute or if the src markup attribute is updated for the
media element, then the user agent must run the steps below:
1. If the new src value is the same as the old one, abort these steps.
2. Synchronously invoke the load() method. If that raises an exception,
that exception must be reraised such that the script which changed the src
attribute receives the exception.
3. If the previous media resource was actively playing, or if the media
resource was about to play once enough data would have downloaded
(autoplay set to true), then the new media resource must start playing
once the networkState reaches CAN_PLAY_THROUGH."
That's about all for now.
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#media
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#location
[3]
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#loading
[4]
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#offsets
[5]
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#playing
[6]
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#user-interface
[7]
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#time-range
[8]
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-terminology.html#terminology
[9]
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#src6
[10]
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#seeking
--
http://www.robodesign.ro
Received on Sunday, 5 August 2007 20:42:34 UTC