W3C home > Mailing lists > Public > www-style@w3.org > December 2012

Re: Media feature based on parent width instead of viewport/device width

From: François REMY <francois.remy.dev@outlook.com>
Date: Tue, 18 Dec 2012 21:57:17 +0100
Message-ID: <DUB120-DS22DDF568DE99535702A560A5310@phx.gbl>
To: "Boris Zbarsky" <bzbarsky@MIT.EDU>, <www-style@w3.org>
Is there any other way to do it? I mean, is is obviously possible to add 
short paths (and there probably are a lot of them hidden in called 
functions, no doubt about it), but in the general case this seems just 
unavoidable to reperform the layout if you want to achieve seamless frame in 
the way it's currently specced (I'm genuinly interested if you think 
otherwise). The main reason I think there's this issue is that elements 
inside the iframe can be sized proportionnally to the height of the iframe 
(vh/position absolute bottom/...), and that size equally depends on the 
height of the document. You can't resolve those cycles in at least a double 
evaluation (reset+accomodate), can you?

My own test included this trick:

<iframe seamless>
        <div style="position: absolute; left: 0px; right: 0px; top: 0px; 
bottom: -100px;"></div>
<!-- results in a 100px high iframe with scrollbars on both sides, and a 
~180px tall div -->

-----Message d'origine----- 
From: Boris Zbarsky
Sent: Tuesday, December 18, 2012 7:31 PM
To: www-style@w3.org
Subject: Re: Media feature based on parent width instead of viewport/device 

On 12/18/12 6:06 AM, François REMY wrote:
> Just to play the role of the devil's advocate, you may be interested in 
> knowing that Google Chrome already has a loop issue in its layout code for 
> seamless iframes [1]. As far as I can see, the layout of the deepest 
> iframe has to be done 2^n times

They'll need to fix that at some point...  Gecko used to have those
sorts of issues with tables and floats in the distant past; turns out
that nesting things like this 10+ levels deep is not uncommon on the web.

Received on Tuesday, 18 December 2012 20:57:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:06 UTC