On Fri, Oct 4, 2013 at 2:17 PM, Sylvain Galineau <galineau@adobe.com> wrote: > > 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?
Received on Friday, 4 October 2013 22:02:56 UTC