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

Re: [whatwg] Simplified <picture> element draft

From: Bruno Racineux <bruno@hexanet.net>
Date: Wed, 22 Jan 2014 17:14:22 -0800
To: Adam Barth <w3c@adambarth.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
Message-ID: <CF05A367.7FE85%bruno@hexanet.net>
Cc: Maciej Stachowiak <mjs@apple.com>, whatwg <whatwg@whatwg.org>, Yoav Weiss <yoav@yoav.ws>, Timothy Hatcher <timothy@apple.com>
On 1/22/14 3:54 PM, "Adam Barth" <w3c@adambarth.com> wrote:

>The way we'd likely implement this feature in Blink is in couple
>stages.  In the first stage, we'd implement the portions of the
>specification that don't involve media queries because we'll be able
>to provide developers a high-quality implementation of that part of
>the spec, including preload scanning.  In the second stage, we'd
>implement the parts of the specification that relate to media queries.
> We'll likely wait to implement the second stage until we're able to
>provide a high-quality implementation, which means waiting until we're
>able to parse and process media queries in the preload scanner without
>joining the main thread.
>
>Adam

Meanwhile, is there a way in which all vendors can prevent their
pre-loaders from preloading (and loading at all for that matter) any <img>
that has either: An html5 hidden attribute, or display:none; both inline
or via a css class in the head, which is the current behavior of the
<object> element in Webkit:
https://twitter.com/pornelski/status/405704147678535680

I think it's safe to say that, for the browser to load assets marked as
'display:none;' makes little sense, and overrides a developer's
ability to control when his/her assets are supposed to load.

Browsers loading stuff that's voluntarily set as hidden is a bad
performance predisposition, as well as a waste of bandwidth, especially
when it comes to responsive mobile sites where the context of hidden
*really* means hidden as in: Do *not* load unless actually displayed.

Bruno
Received on Thursday, 23 January 2014 01:14:58 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC