W3C home > Mailing lists > Public > public-html-a11y@w3.org > October 2011

[Bug 13358] <video> also fire a 'change' event at VideoTrackList, AudioTrackList, and TextTrackList objects when their list of tracks changes

From: <bugzilla@jessica.w3.org>
Date: Thu, 13 Oct 2011 19:54:18 +0000
To: public-html-a11y@w3.org
Message-Id: <E1RERMA-0003Md-T8@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13358

--- Comment #19 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-10-13 19:54:15 UTC ---
(In reply to comment #16)
> 
> Nevertheless, the use-case was included in the original bug, so whilst this
> could be tracked as a separate issue it is not "new" and should be dealt with
> as an LC1 issue too.

Yes, if you file a bug on the topic in comment 14, please don't hesitate to
mark it as an LC1 bug.


> I do have a mild concern about the proposed approach: we should consider what
> happens with extremely long-running streams (live streams) which may consist of
> a lot of different material spliced together, where the available tracks in
> each segment are completely different. The current approach implies an
> ever-growing track list and I wonder if we really should delete the "dead" ones
> in some way.

There's also an ever-growing buffer (which the user agent might eventually
start discarding data from), an ever growing "current time", etc. Are we
actually expecting this to be a practical problem?

I'd rather not solve issues that never become real problems. They add
complexity to the implementations, the test suites, the spec, etc that is not
justified.

We can always add a solution to this later if it becomes a real problem.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 13 October 2011 19:54:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:47 GMT