W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2012

[whatwg] should we add beforeload/afterload events to the web platform?

From: Roman Rudenko <roman@mobify.com>
Date: Thu, 12 Jan 2012 11:19:02 -0800
Message-ID: <CAOtd2HX6pnqWPXNpJe2=7gSYncOUXXrhAcLVwT20tT9aZHzTNw@mail.gmail.com>
On Jan 12 10:32, Boris Zbarsky wrote:
> Yes, but does mobify use the beforeload handler after the initial page
> load?  They're generating new content and document.writing it back into
> the document, and that new content needs to perform loads, so I would
> think they aren't so much.

At the moment, we are capturing raw page HTML by containing it within
<style> with nonstandard type or <textarea> elements. If we know that
a page is well-behaved and has no textareas in head or styles in body,
we can document.write an opening <textarea> to capture what's in
<head>, and capture page body with a similarly written <style>. Once
we capture raw HTML text, we rename resource-loading attributes (src,
href), allowing us to build and process DOM representation without any
external requests firing.

Beforeload comes in when our assumptions are violated. If the page has
a <style>...</style> within body and we don't take preventive
measures, our capturing method will allow everything after </style> to
leak into DOM. So, we use beforeload (along with some other tricks) to
block resources that elude capture. We don't need beforeload after
that, as we control all HTML we return into the page.

Now that Henri Sivonen showed us that <plaintext> can be used for
capturing, we could get away with not using beforeload at all.
However, it may be useful for folks who use smaller, more controlled
transformations. For example, @media-controlled mobile view of a page
originally designed for desktop will typically include all desktop
assets. beforeload can fix that, as desktop resource loads could be
cancelled or even replaced with mobile-specific ones without complete
HTML reconstruction.

-- 
Roman Rudenko
Received on Thursday, 12 January 2012 11:19:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:10 UTC