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

Re: [whatwg] Simplified <picture> element draft

From: Yoav Weiss <yoav@yoav.ws>
Date: Tue, 7 Jan 2014 22:28:57 +0100
Message-ID: <CACj=BEiS8ezRaTRdyiRU2oq77gL96pM79SLrQVq6ty0k=Gxagw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: whatwg <whatwg@lists.whatwg.org>
On Tue, Jan 7, 2014 at 6:20 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 1/7/14 12:01 PM, Yoav Weiss wrote:
>> I'd love to get some more details regarding that. I'll start a
>> mozilla.dev.platform thread on the subject, since it's Gecko specific.
> It's actually not entirely Gecko-specific.
> Consider a display:none iframe.  How should viewport-size-related media
> queries be evaluated in such a thing?  The specs don't define it, as far as
> I can tell.  In fact, the specs don't actually define anything useful for
> the viewport of a framed document at all, as far as I can see.  CSS just
> assumes a viewport exists, and HTML doesn't define anything about frames
> setting up a viewport for the document inside them...
> But say they defined it.  How would the viewport of a display:none iframe
> be defined, exactly?
> Last I checked, UAs just end up doing wildly different things in this
> situation.
I agree that iframes complicate things, since the parent document's
external CSS can modify their viewport dimensions, so there's an inherent
race condition there.
But this is an issue that applies to any solution that relies on viewport
dimensions for resource loading.
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" (e.g. all its <head> CSS was
parsed and applied)
Received on Tuesday, 7 January 2014 21:29:21 UTC

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