- From: <bugzilla@jessica.w3.org>
- Date: Tue, 26 Apr 2011 08:39:27 +0000
- To: public-html-bugzilla@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