[whatwg] Simplified <picture> element draft

Tue Jan 7 14:25:32 PST 2014

On Tue, Jan 7, 2014 at 11:13 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Tue, Jan 7, 2014 at 1:53 PM, Boris Zbarsky <bzbarsky at 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.
>

One addition - Waiting for the parent document's onload seems a little too
careful to me. At least some of the onus can also be on authors embedding
the iframe (e.g. authors can declare the iframe's dimensions relatively
early in the parent document's CSS, or at least avoid modifying its
dimensions later on).

>
> > 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
>