On Aug 27, 2012, at 5:02 PM, Ian Hickson <i...@hixie.ch> wrote: >> With JavaScript, it's certainly possible for a page author to play() or >> pause() a slaved media element directly, but that author could just as >> easily remove the media element from the media group / media controller. >> >>> [...] >>> >>> That only works if there's JavaScript doing the removing. The idea >>> here is that this should all work even without any JS, just with UA >>> UI. >> >> With just the UA UI, the behavior would be exactly the same [...] > > If you remove the element from the media controller, the media > controller's timeline changes.
So? In the general case (alternative audio, sign-language) the timelines will be exactly the same. If there's an edge case where a change in the timeline is a problem, a page author could hide the slaved media element (e.g. "display:none" or "element.muted = true") instead. > It'll be quite common for there to be videos that are not currently > playing, e.g. sign-language tracks. I think you're making an incorrect distinction. The author may not want the sign-language track to *display*. Pausing the video is one mechanism which achieves that (sort of). Hiding it is another. Removing the video from the MediaController and pausing it is a third. The side effects of this particular mechanism are causing a lot of confusion. We gave a session at WWDC about the MediaController and collected a lot of developer feedback at the labs, and the general theme was that the API didn't make sense. Here's a good example of the kinds of bug reports we're seeing: "MediaController play() doesn't work" <https://bugs.webkit.org/show_bug.cgi?id=94786>. > If we change anything here, I think it > would be the currently required UI behaviour which requires all the videos > to start playing when the user overrides the JS-provided controls and just > uses the UA controls. This change would break the UI controls in the basic case of <video controls mediagroup="foo">. -Jer
