- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Wed, 18 May 2011 07:09:21 +1200
On Tue, May 17, 2011 at 9:09 PM, Philip J?genstedt <philipj at opera.com>wrote:
> 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
> script are fired again. However, this seems awfully messy if the script also
> observes readyState or networkState. It might also interfere with browsers
> that use scripts behind the scenes to implement the native controls.
>
> Although a kludge, another solution might be to block events from being
> fired until x more bytes of the document have been parsed or it has finished
> loading.
>
> Any other bad ideas?
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 of
the behaviors currently allowed by the spec ... i.e. you're pretending that
your frame, image and video loads simply didn't complete until after
DOMContentLoaded fired in the outer page. That would mean it's compatible
with properly-written legacy content ... if there is any.
Of course I have no idea whether that approach is actually feasible :-). It
obviously isn't compatible with what browsers currently do, so authors
wouldn't want to rely on it for a long time if ever.
Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
Received on Tuesday, 17 May 2011 12:09:21 UTC