[whatwg] 'hidden' as resources control

Yoav Weiss yoav at yoav.ws
Mon Jan 27 00:03:49 PST 2014

On Mon, Jan 27, 2014 at 4:20 AM, Bruno Racineux <bruno at hexanet.net> wrote:

> On 1/26/14 3:39 PM, "Qebui Nehebkau" <qebui.nehebkau+whatwg at gmail.com>
> wrote:
> >On Sat, Jan 25, 2014 at 4:13 AM, Bruno Racineux <bruno at hexanet.net>
> wrote:
> >> What exactly do you find misguided, can you be more specific?
> >
> >Basically, - and I'm trying not to over-elaborate here, since my
> >opinion isn't really very important - I just mean that I don't think
> >there should be any guarantees about how (or whether) browsers will
> >preload, nor any specific means of controlling this, because the way
> >resources get loaded is not really any of the author's business.
> I couldn't disagree more. It is my business to know how the browser loads
> assets in order to better assist the best performance for my users.

Preloaders have been a great source of competitive innovation for browsers.
Specifying it would at least partly prevent that.
What is it exactly that you think needs specifying?

> Don't want to over-elaborate either but I'll leave you with a relevant
> quote:
> "The good news is all of these optimizations are done automatically on our
> behalf and often lead to hundreds of milliseconds of saved network
> latency. Having said that, *it is important to understand how and why
> these optimizations work under the hood*, because we *can* assist the
> browser and help it do an even better job at accelerating our
> applications."
> Ilya Grigorik - High Performance Browser Networking
> http://chimera.labs.oreilly.com/books/1230000000545/ch10.html#BROWSER_OPTIM
> There is a balance between putting DOM loading on auto-pilot, blindly
> assuming the preloader is your friend and can do no wrong, and the reality
> that the preloader can't ultimately do the best job on its own. It needs
> to be assisted with resource priority attributes (or preferably css) for
> better control. Without them, the preloader is no more than a 'seen-first
> priority' faster loader, with a priority agnostic performance shortfall.
> >the argument that preloaders
> >can't consider CSS isn't compelling to me, because a browser's choice
> >to preload an image or not isn't important enough (or, I think it
> >shouldn't be) to justify entrenching in a specification.
> If not for specifications, we certainly need 'preload opt-out' tools to
> better manage loading priorities. Whether it be 'postpone', 'lazyload' or
> said implications of 'hidden', and some documentation as to what to expect
> from preloaders.
+1 for documentation (I'm trying to do my part on that front [1])

Can you please sum up what is the required use-case you think 'hidden'
should handle that 'postpone' and 'lazyload'  cannot?


[1] http://calendar.perfplanet.com/2013/big-bad-preloader/

More information about the whatwg mailing list