Re: [css-device-adapt] Apply @viewport to top-level documents only

  Going back to the beginning, do we know why implementors applied this
  restriction to begin with? Interaction with zooming is a possible
  candidate. Others?


I worked on the implementation in Blink.  Interaction with pinch zooming is the main reason; pinch zoom is applied by the compositor on a separate thread, and iframes are not even guaranteed to turn into objects that the compositor is aware of (composited layers).  Also, the main frame's sizing behavior is managed separately from subframes.

I don't have interest in implementing independently pinch-zoomable iframes: it would involve a significant rewrite that isn't nearly justified.  So if the @viewport spec mandated iframe support, the likely Blink implementation would instead be to use the CSS scale transform codepaths (doing literally the same thing as the workaround Javascript that Francois mentioned).  In such an implementation, the "min-zoom", "max-zoom" and "user-zoom" properties would be meaningless but the remaining @viewport properties could be supported.  It would also have a certain burden in code complexity and testing (given that it wouldn't share the implementation of the top-level) that I'm not sure would be justified by popularity of @viewport iframes among developers.

So I'm pretty lukewarm about this.  I'm wondering if iframe @viewport could possibly be supported by a Javascript polyfill since the implementation I have in mind looks similar anyway?

The javascript solutions halas assumes that the author knows about his content being rendered in an IFRAME. An use case I’ve in mind is the Twitter app on Windows 8 which renders the target of a link into a frame within the app to allow you to return easily to the timeline once you’ve read the article: any website relying on @viewport would possibly break in such an app. Another example is the case of online translators rendering the website being translated in a frameset. 

As pointed by David L. Baron earlier, the <meta viewport> tag was mainly an hack that affected only phones as an opt-out for automatic scaling, and this behavior won’t happen in an IFRAME anyway. The situation is different for @viewport which can be used for fixed-point responsive web design: it is likely to be applied in more cases and those cases will most likely end up leaking into frame scenarii.