W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

[Bug 12547] <video> MEDIA CONTROLLER requires readyState for grouped multitrack

From: <bugzilla@jessica.w3.org>
Date: Wed, 02 Nov 2011 22:55:07 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RLji7-0001Sa-5I@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12547

Jer Noble <jer.noble@apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |jer.noble@apple.com
         Resolution|WONTFIX                     |

--- Comment #6 from Jer Noble <jer.noble@apple.com> 2011-11-02 22:55:05 UTC ---
(In reply to comment #2)
> Both cases are somewhat advanced uses of the API, and I really think it
> wouldn't be much to ask in such a situation that the minimum of the readyStates
> be calculated by scripts.

In implementing this spec for WebKit, I have become convinced that the
implementation of a readyState accessor is so incredibly trivial that even if
the only benefit were to keep script authors from having to calculate the
minimum readyState of the slaved media elements, it would still be worth
adding.

But as there is no accessor in MediaController for the current slaved media
elements, even doing this calculation script-side has the potential for errors.

> 2. When attaching controls to an already playing media element and need to
bring them up to speed.

Note that, currently, attaching a playing media element to a media group does
not trigger "reporting the controller state", and thus in this situation the
minimum slaved element readyState and the controller readyState are not the
same.

As such, I'd like to reopen this bug for consideration.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 2 November 2011 22:55:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 2 November 2011 22:55:39 GMT