- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 17 May 2011 10:04:31 +0200
On Mon, 16 May 2011 17:59:43 +0200, Remy Sharp <remy at 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 attaching an > event is perfectly legal and will expect it to work. > > Now you're right, whoever pointed out the 7am alarm example, if you > attach the event too late, then you'll miss the boat. However, it's a > chicken an egg situation. You don't have the DOM so you can't attach > the event handler, and if you do have the DOM, the damn event has fired > already. > > What's the fix? Well, the work arounds are certainly viable, again from > an everyman developer point of view: > > 1) Attach higher up, on the window object and listen for the > canplay/loadedmetadata/etc and check the event.target > 2) Attach an inline event handler (not nice, but will do) > > The fix? Since ultimately we have exactly the same potential "bug" with > image load events, is to update the specification and make it clear: > that depending on the speed of the connection and decoding, the > following "xyz" events can fire **before** your script runs. Therefore, > here's a couple of work arounds - or just be aware. If we fail to come up with a better solution, then warning about the issue in big, bold, red letters is the least the spec should do, yes. > Any objections? At the same time, does someone want to raise this as a > bug? I already did: https://github.com/remy/html5demos/issues/12 Or do you mean a spec bug? -- Philip J?genstedt Core Developer Opera Software
Received on Tuesday, 17 May 2011 01:04:31 UTC