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

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 26 Apr 2011 08:39:27 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QEdnr-00022c-5C@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267

--- Comment #18 from Philip Jägenstedt <philipj@opera.com> 2011-04-26 08:39:26 UTC ---
(In reply to comment #16)
> I really really think that trying to hide the fact that, when programming
> time-based media and time-based behavior, you are "standing on a moving
> conveyor", would be a mistake.  Highlight in the spec. that clients of the API
> should expect that things may be changing under their feet, sure.  As I said,
> you can't stop the world while the scripts think (e.g. freeze the video), and
> snapshotting the world is just telling you a truth about the past, not the
> present.

Is there any use case for observing these changes while the script is running?
Firefox already does some kind of snapshotting, is there anything (reasonable)
you cannot do in Firefox that works in e.g. Opera or Safari?

> If you snapshot, you have to buffer all the actions a script takes
> until all the scripts stop running, for example, so that they don't affect the
> snapshot.  Now what do you do if the actions can't all be applied?  It's too
> late to give an error response. Ugh.

It's perfectly possible to have some commands actually change the state of the
snapshot, as long as it's well defined.

However, it seems to me that we already have exactly this situation. The script
is never really in sync with reality, no matter how often it looks at
readyState/currentTime, the state could always have changed by the time the
script issues a command. Now what do you do if the action can't be applied?

-- 
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 Tuesday, 26 April 2011 08:39:28 UTC

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