Re: [whatwg] Simplified <picture> element draft

On Tue, Jan 7, 2014 at 1:53 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 1/7/14 4:28 PM, Yoav Weiss wrote:
>> Since this case is not the majority case, we could bail out of it by
>> delaying the iframe's subresource loading that rely on viewport
>> dimensions until the parent's layout is considered "done"
>
> That seems fairly undesirable, actually, though limiting it only to the
> things that have media queries might be better...

Yoav said "[resources] that rely on viewport dimensions", so yes, it
would only be MQs that query viewport size (or sizes='' attribute that
use vw/vh units).

>> (e.g. all its
>> <head> CSS was parsed and applied)
>
> And all its HTML parsed (including whatever onload scripts it runs) and
> layout on that completed, right?
>
> This seems like it serializes things a lot...

Only to the extent necessary.  If you're relying on viewport
information, you gotta wait for your viewport to get sized.  There's
no way around that, except not relying on viewport information.  The
most common use-cases of <picture> don't use viewport info, and so are
friendly to this stuff.

> But also some of the same constraints apply to the toplevel viewport, not
> just subframes (e.g. its dimensions can change based on what the browser UI
> does, etc).  At some point you just accept that the dimensions you have are
> what you have, even if they might change in the future.

Indeed, and that's also fine.  Small changes in viewport size from
browser UI should only rarely have an impact on which resource is
downloaded, anyway.  (And adding a bit of hysteresis would solve
those, too.)

~TJ

Received on Tuesday, 7 January 2014 22:13:44 UTC