- From: <bugzilla@jessica.w3.org>
- Date: Fri, 19 Aug 2011 22:32:47 +0000
- To: public-html-bugzilla@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