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

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

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 13 Jan 2012 13:12:30 +0200
Message-ID: <CAJQvAuc8BmMDcBCiJfyD5ErMvQCmUgQsm3-fv3kVQ62hsXcASA@mail.gmail.com>
On Fri, Jan 13, 2012 at 4:23 AM, Roman Rudenko <roman at mobify.com> wrote:
> This might not work as nicely in Firefox, which, according to Boris,
> does not maintain separation between main and speculative parser.

Firefox doesn't support preventing HTTP GETs when the page
imperatively rewrites its declarative parts. In principle, Firefox may
preload all declarative resources that a page points to before any
script on the page gets a chance to run. Declarative language allows
browsers to optimize stuff for the whole Web. I think we shouldn't
pessimize any of those optimizations for the whole Web in order to
cater to the tiny, tiny part of the Web that wants to rewrite
declarative HTML on the client side in the name of responsive design.

If you don't want browsers to initiate HTTP GETs for scripts, images,
video poster frames, style sheets, etc. (maybe in the future
iframes!), don't put the URLs of those things into the HTML source you
send to the browser in the first place. That is, if you don't want the
browser to fetch foo.jpg, don't say <img src="foo.jpg"> in the source
you send to the browser. If you need a placeholder, use <img
data-transformable-src="foo.jpg">.

Note that if you do
<script>document.write("<plaintext
style='display:none;'>");</script><img src="foo.jpg">
Firefox will still most likely start fetching foo.jpg (by design).

That said, please do include the images, etc., you want fetched in the
source. If you do want foo.jpg fetched, saying <img src="foo.jpg"> in
the HTML source is a latency win over letting a script cause the
fetch.

To the extent the problem is that you don't know what you want fetched
before probing the client characteristics, I think adding JS APIs is
not the right solution. The right solutions are:
 1) If cruft is optional, don't give the cruft to anyone. If there's a
bunch of inessential scripts that you don't want mobile browsers to
load, don't give them do desktop browsers, either.
 2) Making the client probing declarative. If there is a true, broad
and persistent (longer than, say, 2 years) need to load different
images based on client characteristics, we should introduce a
declarative way to pick the desired image. Something along the lines
of
<picture>
<source condition="that the browser can evaluate without JS" src="img1.jpg">
<source condition="that the browser can evaluate without JS" src="img2.jpg">
<img src="img3.jpg">
</picture>

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
Received on Friday, 13 January 2012 03:12:30 UTC

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