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

[Bug 12267] <video> Make video state transitions happen in the same task as firing events

From: <bugzilla@jessica.w3.org>
Date: Fri, 19 Aug 2011 22:32:47 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QuXcN-0007lB-5O@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267

--- Comment #51 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-08-19 22:32:42 UTC ---
(Another example of this kind of thing is cues: when a cue is activated or
deactivated, it queues an event. By the time the event is fired, lots of cues
might have come and gone. The "activeCues" list doesn't change while the script
is running, but the cue in question might no longer be active. I'm pretty sure
we don't want to delay the cues appearing and disappearing until the events
have fired, that would make the cues laggy. We could keep have the list of
activeCues be maintained by the events, but as with other things, I really
think that having the API lie is worse than having the events be delayed —
what if one of these events pauses the video, for example: is currentTime the
time at the time the cue event was queued, or at the time the event fired, or
the time the script called pause()? Here the lie becomes really clear, since
the user can easily compare the actually visible cues to the cues in the
scripts. Once things are paused, it's no longer lag, it's just plain wrong. I
really don't see any way to keep this API sane while making the scripts run in
entirely predictable environments.)

I think this is WONTFIX for the general case.

There may be specific cases that make sense. I recommend bringing the very
specific cases up (either here on in bugs marked as being blocked by this one),
so I can look at them individually.

-- 
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 Friday, 19 August 2011 22:32:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:17 UTC