[whatwg] Iframe dimensions

On Mon, 5 Jul 2010, Markus Ernst wrote:
> 
> I found that the dimensions of the iframe element are handled along with 
> those of other embedded content such as img, video and others: 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width
> 
> There is no indication about what a UA should do when dimension 
> attributes are not specified.

That's handled by CSS.


> UAs do seem to handle this case differently for those elements: To an 
> img element, they apply the actual pixel dimensions of the image file, 
> while they seem to apply default dimensions to iframe elements.

Right, because <iframe>s have no intrinsic dimensions (except with 
seamless).


> First, this sounds somehow complicated to me

Yeah, the handling of intrinsic sizes in CSS is non-trivial.


> and second, I don't understand why the dimensions of non-seamless 
> iframes should not get the benefits of author-friendly (and 
> user-friendly) dimension handling.

It would let you examine pages cross-origin, leaking information such as 
whether the user is logged in.

 
> I want to suggest to provide a way to make an iframe behave just like 
> any block element regarding width and height, that means: If no 
> dimensions are specified, use the full available width, and apply the 
> height needed to display the full content.

That's what happens for seamless iframes. We can't do it for cross-origin 
iframes (security) or for undecorated iframes (compatibility).


> Example: http://test.rapid.ch/de/haendler-schweiz/iseki.html (This is 
> under construction.) As a workaround to the height problem, I applied a 
> script that adjusts the iframe height to the available height in the 
> browser window. But of course the user experience would be more 
> consistent if the page could behave like a single page, with only one 
> scrollbar at the right of the browser window.

If you control both pages and can't use seamless, you can use 
postMessage() to negotiate a size. On the long term, I expect we'll make 
seamless work with CORS somehow. I'm waiting until we properly understand 
how CORS is used in the wild before adding it all over the place in HTML.

On Tue, 6 Jul 2010, Markus Ernst wrote:
> 
> My problem is this sentence in the spec for seamless: "This will cause 
> links to open in the parent browsing context."
> 
> In an application like 
> http://test.rapid.ch/de/haendler-schweiz/iseki.html, the external page 
> should be able to re-call itself inside the iframe, for example if a 
> sort link is clicked or a search form submitted.

On Tue, 6 Jul 2010, Ashley Sheridan wrote:
> 
> Could you explicitly call the _self target in links in the frame? I 
> wasn't sure if the target attribute was going or not, but I'd expect 
> target="_self" to override the default seamless action.

Good point. Fixed. You can now work around this by targetting the frame 
explicitly using <base target=_self>. (Or by using target=foo if the 
iframe has name=foo.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 10 August 2010 15:24:09 UTC