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