W3C home > Mailing lists > Public > public-html-media@w3.org > June 2016

[media-source] Steps that fire events at media elements duplicate those in HTML5.1

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Thu, 16 Jun 2016 10:09:01 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-160625254-1466071740-sysbot+gh@w3.org>
tidoust has just created a new issue for 
https://github.com/w3c/media-source:

== Steps that fire events at media elements duplicate those in HTML5.1
 ==
HTML5.1 specifies the events (e.g. `loadedmetadata`, `loadeddata`, 
`canplay`, `canplaythrough`)  that are to fire when the `readyState` 
of a media element changes, see algorithm below the definitions of the
 ready states in section 
[4.7.14.7](http://www.w3.org/TR/html51/semantics-embedded-content.html#ready-states)

The Media Source Extensions spec describes conditions that cause the 
`readyState` of a media element to change. Per HTML5.1, such changes 
imply firing relevant events at the media element.

The problem is that the Media Source Extensions spec also asks 
implementations to fire these events. I assume that the goal is to 
make it clear that changing the `readyState` of the media element also
 implies firing the events, but the use of normative steps effectively
 duplicates HTML5.1 and the spec does not say that these steps are 
intended to replace those in HTML5.1. In other words, an 
implementation that fires the `loadedmetadata` event twice would just 
follow the specs. Also, duplicating is error-prone, and for instance I
 note that the Media Source Extensions spec remains silent on the 
`timeupdate` and `waiting` events that get fired when the state 
changes from `HAVE_FUTURE_DATA` to `HAVE_CURRENT_DATA` or less (which 
can happen at the end of the Initialization Segment Received algorithm
 for example).

I suggest to leave events up to HTML5.1. This would mean dropping the 
steps that require events to fire, perhaps replacing them with 
informative notes such as "Per HTML5.1, changing `readyState` may 
trigger events on the media element" or something equivalent.

Sections and steps incriminated:
* [2.4.4 SourceBuffer 
Monitoring](http://w3c.github.io/media-source/#buffer-monitoring)
* [3.5.8 Initialization Segment 
Received](http://w3c.github.io/media-source/#sourcebuffer-init-segment-received),
 step 6.3
* [3.5.12 Coded Frame 
Processing](http://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing),
 steps 2.2, 3.2, 4.2

Or is there a good reason why these steps need to be in the spec?

Note that, while this touches on normative steps, I don't think it 
needs to block publication as CR: the update would not change the 
expected behavior, but merely clarifies the intent and helps avoid 
misinterpretations.

Please view or discuss this issue at 
https://github.com/w3c/media-source/issues/98 using your GitHub 
account
Received on Thursday, 16 June 2016 10:09:04 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 16 June 2016 10:09:04 UTC