W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Detailed review of 3.14.9. Media elements

From: Mihai Sucan <mihai.sucan@gmail.com>
Date: Sun, 05 Aug 2007 23:42:21 +0300
To: public-html <public-html@w3.org>
Message-ID: <op.twls4v17mcpsjgr0b0dp@localhost.localdomain>

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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:48 UTC