Re: Detailed review of 3.14.9. Media elements

(By the way, in general, I recommend not bothering to report editorial 
mistakes at this point. Let's worry about making the actual rules correct 
and unambiguous before we worry about the spelling and grammar!)

On Sun, 5 Aug 2007, Mihai Sucan wrote:
>
> 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".

It's not a markup attribute (you can add it to the DOM dynamically).

The term "element attribute" ends up being really confusing, especially 
when you have attributes named element, and elements named attribute, and 
other such weirdnesses, as we've ended up with in XBL. I'd like the term 
to be consistent through the specs I edit.

I'm leaving it as is for now, but I think the issue has been mentioned 
before and will likely be addressed separately again later.


> 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.

Fixed.


> 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:"

I've tried to fix this throughout the spec.


> 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".

Fixed (removed 'properly').


> 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

Fixed.



> 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.

I'd like implementation experience feedback on this issue.


> 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.

The user agent can do this itself, though.


> 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."

Fixed.


> 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.

Fixed.


> 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.

Fixed.


> 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".

Fixed.


> 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.

Having two events seems like overkill for this.


> 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)."

This seems like a convience method that isn't hugely helpful. What's the 
use case, and why wouldn't start(index)-end(index) be acceptable?


> 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.

That seems like a strange value to show the user. I think we should wait 
to see if there is any demand for this feature from authors.


> 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."

I actually agree with this, but there has been some pushback before. What 
do people think? Should we add this feature? It would be easy.


> 17. The spec is missing the definition of a scriptable way to abort the 
> loading of the media element.

Just remove the <source> elements and src="" attribute, and call load() 
again.


> The need: In many cases users want to stop videos from downloading, not 
> only playing.

If the _user_ wants to do this, he can do this through the user agent, we 
don't need an API for it. (The spec already supports this, though, by 
allowing the user agent to limit bandwidth to zero.)


> 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?)

Sure, the user agent can download the file as fast as it likes, including 
zero bytes per second. This is documented in the load() method definition.


> 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.

If you don't want it to autoload, just don't set the source yet.


> 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).

What's the use case?


> 20. The spec does not define what happens if the src attribute changes 
> (the markup attribute and the DOM attribute).

Fixed.


> Does the media element stop playing and loads the new media data? Or 
> nothing happens until you call load() again?

The latter.


Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 19 October 2007 01:50:49 UTC