W3C home > Mailing lists > Public > www-style@w3.org > February 2015

Re: [css-device-adaptation] Progress?

From: Yoav Weiss <yoav@yoav.ws>
Date: Thu, 26 Feb 2015 23:52:13 +0100
Message-ID: <CACj=BEifpdZDMYHpVxr2unHizvxWxbu4OmExTska-56DtHZnAg@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Rune Lillesveen <rune@opera.com>, Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>, Florian Rivoal <florian@rivoal.net>, Matt Rakow <marakow@microsoft.com>, David Bokan <bokan@chromium.org>, "www-style@w3.org" <www-style@w3.org>
On Thu, Feb 26, 2015 at 10:58 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Feb 26, 2015, at 12:00 PM, Yoav Weiss <yoav@yoav.ws> wrote:
> On Thu, Feb 26, 2015 at 7:55 PM, Brad Kemper <brad.kemper@gmail.com>
> wrote:
>> I still don't see the problem of just not loading the images until after
>> the CSS has been parsed and cascaded.
> Waiting until all the page's CSS would be downloaded, parsed and cascaded
> before starting to download images would cause prohibitive page load time
> as well as visual speed regressions. That's not how browsers load images
> today, and we've went through great lengths to make sure that they won't
> have to start doing that when responsive images were introduced.
> Hmm. I guess I can see this point, then, if there is no optimization to
> prescan the stylesheets for an @viewport mentions as one of the first steps
> of parsing. Or do UAs not even wait for CSS downloading before downloading
> images?

No, they don't. CSS usually has higher priority, but depending on the UA
and the prioritization scheme, some images start to download in parallel to

Making sure @viewport can only be one of the very first rules of the
stylesheets would enable prescanning of these stylesheets as they download,
and is likely to reduce the number of "collisions" or redundant image
downloads, in case authors do place @viewport in an external style.

> If the page is zoomable, wouldn't it download the size for 100% zoom level
> anyway, rather than the smaller one you'd get if the actual viewport is
> bigger than the initial viewport, so that when the user does zoom in, they
> see full resolution? (I hope I am using those terms correctly. I mean when
> the page is zoomed out to fit on the screen.)

As far as I understand, you're referring to magnifying glass type zoom (so
"pinch zoom"), which doesn't impact layout. At least currently, such zoom
has no impact on which image resource is being downloaded, and doesn't
trigger further downloads.
For the art-direction case (so <picture>), it shouldn't. For variable width
images (so srcset/sizes), it's debatable.

> If so, how does  @viewport affect which images are downloaded? Or is this
> specifically about when user zoom is disabled?

@viewport changes the actual viewport, which impacts which image resources
should be downloaded. As far as I understand it, nothing to do with
(magnifying glass type) zoom.

> At that point, you would know which images to fetch. If you are
>> pre-loading based on viewpoint assumptions, then just stop once the
>>  assumptions prove false.
>> PS: the length of the vw, vh, etc. units don't need to be resolved until
>> after the cascade stage either.
> That is far from being true. `vw` units are used in `sizes` in order to
> determine the image density regardless of the external CSS downloaded.
> So, they don't use the initial viewport for that?

They do now. But once @viewport is supported, they should switch to the
actual viewport, or they risk resulting in redundant downloads.

> They can also be used in Media Queries inside `media` attributes.
> Hmmm. For media attributes on linked style sheets or @media, I would think
> you'd have to use the initial viewport to avoid circular dependencies.
True for styles, not for <picture>/<source>. So again, can result in
redundant downloads.
Received on Thursday, 26 February 2015 22:52:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:51 UTC