On Sun, Jan 15, 2012 at 1:23 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 1/12/12 9:22 AM, Boris Zbarsky wrote: > >> On 1/12/12 5:16 AM, Simon Pieters wrote: >> >>> Note that it >>> removes the root element when the script element is executed, not at >>> DOMContentLoaded. >>> >> >> Ah, I missed that. I guess the HTML5 parsing algorithm means that now >> the elements are parsed into the other document, eh? That's actually >> pretty cute. I wonder whether we can get the mobify folks to switch to >> this.... >> > > Thinking back on this, this still has the issue of not preventing preloads. > > Again, preventing preloads on a per-load basis is a hard problem if you > want to have sane parallelism. Preventing _all_ loads for a document based > on some declarative thing near the start of the document, on the other > hand, should not be too bad. Even this scheme doesn't work with a model like SPDY push or other bundling techniques or with more aggressive preloading that initiates loads before the main resource is loaded. It seems like there are two use cases: 1.) Monitoring/modifying/preventing network activity for a given resource load 2.) Monitoring/modifying/preventing DOM modifications that occur as the result of a resource load For (1) I can't think of any web-facing needs. For extensions, I believe this is better addressed by APIs that target the network layer more directly - for example proxy auto config scripts, or things like http://code.google.com/chrome/extensions/trunk/webRequest.html. For (2) I think this would be better addressed by using next-generation mutation events to observe (and potentially react) to the changes that occur when an <img> is loaded, for example. I struggle to think of good web-facing use cases for this, though. In any event I think that beforeload as it exists today is a bad API for the web and hope that we can stop exposing it to the web in WebKit (although I suspect it'll stick around for extension contexts, which is more acceptable in my view). - James > If that plus a beforeprocess event addresses the majority of the > web-facing use cases, we should consider adding that. > > -Boris >
