On Mon, 16 May 2011 17:59:43 +0200, Remy Sharp r...@leftlogic.com wrote:
Hi all,
Since this is *my* code that we're talking specifically about, I'd like
to repeat Glenn's point that this is not sloppy code (the cheeky shit),
and that the /everyman/ developer is going to think that
On 17 May 2011, at 09:04, Philip Jägenstedt wrote:
Or do you mean a spec bug?
I meant a spec bug :)
On Tue, 17 May 2011 10:47:02 +0200, Remy Sharp r...@leftlogic.com wrote:
On 17 May 2011, at 09:04, Philip Jägenstedt wrote:
Or do you mean a spec bug?
I meant a spec bug :)
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12664
Still, I don't think just advocacy is any kind of solution.
On Tue, May 17, 2011 at 5:09 AM, Philip Jägenstedt phil...@opera.comwrote:
To target this specific pattern, one hypothetical solution would be to
special-case the first script that attaches event handlers to a video
element. After it has run, all events that were already fired before the
On Tue, May 17, 2011 at 9:09 PM, Philip Jägenstedt phil...@opera.comwrote:
To target this specific pattern, one hypothetical solution would be to
special-case the first script that attaches event handlers to a video
element. After it has run, all events that were already fired before the
On Wed, May 18, 2011 at 7:09 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
Sure! For certain kinds of events (load, the video events, maybe more),
delay the firing of such events until, say, after DOMContentLoaded has
fired. If you're careful you might be able to make this a strict subset
On Sun, 15 May 2011 19:11:09 +0200, Glenn Maynard gl...@zewt.org wrote:
On Sat, May 14, 2011 at 11:49 AM, Eric Carlson
eric.carl...@apple.comwrote:
It seems to me that the right way to fix the problem is let people
know
it is sloppy code, not to figure out a way to work around it.
The
Hi all,
Since this is *my* code that we're talking specifically about, I'd like to
repeat Glenn's point that this is not sloppy code (the cheeky shit), and that
the /everyman/ developer is going to think that attaching an event is perfectly
legal and will expect it to work.
Now you're right,
On Mon, May 16, 2011 at 3:20 AM, Simon Pieters sim...@opera.com wrote:
The state can have changed before the event has actually fired, since
state changes are sync but the events are queued. So if the script happens
to run in between then func is run twice. See
On Sat, May 14, 2011 at 11:49 AM, Eric Carlson eric.carl...@apple.comwrote:
It seems to me that the right way to fix the problem is let people know
it is sloppy code, not to figure out a way to work around it.
The basic problem is that it isn't sloppy code: it's correct for almost all
On May 13, 2011, at 4:35 AM, Philip Jägenstedt wrote:
I wasn't asking how to work around the problem once you know it exists, I was
wondering if any browser vendors have done anything to make this problem less
likely to happen on pages like http://html5demos.com/video that don't do the
On 05/15/2011 01:24 AM, Ojan Vafai wrote:
It's unfortunate that you need to use an inline event handler instead of one
registered via addEventListener to avoid the race condition. Exposing
something to the platform like jquery's live event handlers (
http://api.jquery.com/live/) could mitigate
On Fri, 13 May 2011 12:25:39 +0200, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, 2011-05-13 at 11:40 +0200, Philip Jägenstedt wrote:
Problem:
video src=video.webm/video
...
script
document.querySelector('video').oncanplay = function() {
/* will it run? */
};
/script
In the above the
On May 13, 2011, at 4:35 , Philip Jägenstedt wrote:
I wasn't asking how to work around the problem once you know it exists, I was
wondering if any browser vendors have done anything to make this problem less
likely to happen on pages like http://html5demos.com/video that don't do the
14 matches
Mail list logo
