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 15:06:32 +0100
Message-ID: <DUB002-W515D58825D907D88FC046AA5310@phx.gbl>
To: Ben Callahan <ben@heysparkbox.com>, www-style list <www-style@w3.org>
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 (n being the number of nested seamless iframes). I guess the HTML team did expect that nested seamless iframes would not be used in performance sensitive-context, or they didn't really think about it, or they rightfully observed that you could not do better in that case anyway (except by accepting FOUC).

At least, they made sure the situation is never worse than 2^n because the inner layout is done one time to get the iframe's dimension, and one second time to adapt its content to the chosen dimensions. The general case (i.e. you loop until convergence) could have involved infinite relayout in the case of a "position: absolute; bottom:-20px" element because each relayout would increase the height of the iframe by 20px.

The issue is also mitigated by the fact an IFRAME bring to you a kind of staged layout (that means that recomputing the layout of the content of the IFRAME will not possibly affect the layout of any other element of the outer page) and, as I already noted, no layout manager can give you this guarantee in CSS right now.

Even with those considerations, I made a small test with a seamless iframes (whose document contained a tricky bottom-animated position:fixed element) and the CPU of my test laptop was used 100% by Chrome to display the page and its single animation (presumably due to the large number of wasted relayouts). To be fair, my animation used a suprisingly high 20% CPU on Chrome when rendered outside any frame; still you don't expect a seamless iframe to be as costly in this case.


[1] void RenderIFrame::layoutSeamlessly() at https://trac.webkit.org/changeset/118291/trunk/Source/WebCore/rendering/RenderIFrame.cpp 		 	   		  
Received on Tuesday, 18 December 2012 14:07:00 UTC

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