Re: [whatwg] Iframe dimensions
Am 16.11.2010 00:32 schrieb Ian Hickson: On Wed, 11 Aug 2010, Markus Ernst wrote: Am 11.08.2010 00:24 schrieb Ian Hickson: On Mon, 5 Jul 2010, Markus Ernst wrote: [...] 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. A solution at authoring level for cases where the author controls both pages would be quite helpful. I think of a meta element in the embedded document that specifies one or more domains that are allowed to embed it seamlessly in an iframe, such as e.g.:meta name=allow-seamless-embedding name=domain.tld, otherdomain.tld I think that this would be ok from a security POV, and much easier than using CORS. On Wed, 11 Aug 2010, Adam Barth wrote: That feels like re-inventing CORS. Maybe we should make CORS easier to use instead? On Wed, 11 Aug 2010, Anne van Kesteren wrote: What exactly is hard about it? (Though I should note we should carefully study whether using CORS here is safe and sound. For instance, you may want to allow seamless embedding, but not share content.) I'd like to echo Anne's comments. If CORS is hard, then we should change that; if it's not, then we should use it (once we know it's solid). I tried to understand the CORS spec, but with no real knowledge about networking basics this is quite hard. Anyway it is not necessary for authors to understand the spec, as there will be how-tos available of course. From my humble author's POV, CORS is easy enough for tasks like the one I mentioned, if: - it is applicable at the server side with common scripting languages such as PHP - it is applicable at the client side without scripting
Re: [whatwg] Iframe dimensions
On Tue, Nov 16, 2010 at 12:02 AM, Markus Ernst derer...@gmx.ch wrote: From my humble author's POV, CORS is easy enough for tasks like the one I mentioned, if: - it is applicable at the server side with common scripting languages such as PHP It is, very easily. For pages that are already server-side scripts, it's typically just one or two extra lines of code in the script, to set the appropriate headers to be sent with the page. For non-script pages, like videos, you can either pipe them through an easy script that appends the headers, or use .htaccess (or similar for your particular server technology) to add the headers automatically. - it is applicable at the client side without scripting This is not possible, for the simple reason that the whole point of CORS is to protect server resources. If you could deal with CORS purely on the client side, you'd be allowing the page author to determine if they themself are allowed to access a file on another server. That's a pretty obvious inversion of responsibility. ^_^ ~TJ
Re: [whatwg] Iframe dimensions
On 11/16/10 12:56 PM, Tab Atkins Jr. wrote: - it is applicable at the client side without scripting This is not possible, for the simple reason that the whole point of CORS is to protect server resources. If you could deal with CORS purely on the client side, you'd be allowing the page author to determine if they themself are allowed to access a file on another server. That's a pretty obvious inversion of responsibility. ^_^ Well, more precisely there is nothing that needs to be done on the client side for CORS, right? -Boris
Re: [whatwg] Iframe dimensions
On Tue, Nov 16, 2010 at 10:06 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/16/10 12:56 PM, Tab Atkins Jr. wrote: - it is applicable at the client side without scripting This is not possible, for the simple reason that the whole point of CORS is to protect server resources. If you could deal with CORS purely on the client side, you'd be allowing the page author to determine if they themself are allowed to access a file on another server. That's a pretty obvious inversion of responsibility. ^_^ Well, more precisely there is nothing that needs to be done on the client side for CORS, right? Ah, if that's what Markus was getting at, then yes. CORS requires *zero* work on the client side, since it's completely done in the server-browser interaction. The entirety of the client's interaction in the process is the initial request for a resource. ~TJ
Re: [whatwg] Iframe dimensions
Am 16.11.2010 19:12 schrieb Tab Atkins Jr.: On Tue, Nov 16, 2010 at 10:06 AM, Boris Zbarskybzbar...@mit.edu wrote: On 11/16/10 12:56 PM, Tab Atkins Jr. wrote: - it is applicable at the client side without scripting This is not possible, for the simple reason that the whole point of CORS is to protect server resources. If you could deal with CORS purely on the client side, you'd be allowing the page author to determine if they themself are allowed to access a file on another server. That's a pretty obvious inversion of responsibility. ^_^ Well, more precisely there is nothing that needs to be done on the client side for CORS, right? Ah, if that's what Markus was getting at, then yes. CORS requires *zero* work on the client side, since it's completely done in the server-browser interaction. The entirety of the client's interaction in the process is the initial request for a resource. That is great news. Adding a header via a server-side script is indeed easy enough. (As I did not find any HTML attributes or whatever in the CORS spec, I was afraid that the use of XHR would be necessary to call a cross-origin page in an Iframe - which looked like a huge overhead and also an accessibility issue to me.)
Re: [whatwg] Iframe dimensions
On Wed, 11 Aug 2010, Markus Ernst wrote: Am 11.08.2010 00:24 schrieb Ian Hickson: On Mon, 5 Jul 2010, Markus Ernst wrote: [...] 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. A solution at authoring level for cases where the author controls both pages would be quite helpful. I think of a meta element in the embedded document that specifies one or more domains that are allowed to embed it seamlessly in an iframe, such as e.g.: meta name=allow-seamless-embedding name=domain.tld, otherdomain.tld I think that this would be ok from a security POV, and much easier than using CORS. On Wed, 11 Aug 2010, Adam Barth wrote: That feels like re-inventing CORS. Maybe we should make CORS easier to use instead? On Wed, 11 Aug 2010, Anne van Kesteren wrote: What exactly is hard about it? (Though I should note we should carefully study whether using CORS here is safe and sound. For instance, you may want to allow seamless embedding, but not share content.) I'd like to echo Anne's comments. If CORS is hard, then we should change that; if it's not, then we should use it (once we know it's solid). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Iframe dimensions
Am 11.08.2010 00:24 schrieb Ian Hickson: On Mon, 5 Jul 2010, Markus Ernst wrote: [...] 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. A solution at authoring level for cases where the author controls both pages would be quite helpful. I think of a meta element in the embedded document that specifies one or more domains that are allowed to embed it seamlessly in an iframe, such as e.g.: meta name=allow-seamless-embedding name=domain.tld, otherdomain.tld I think that this would be ok from a security POV, and much easier than using CORS. 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.) Great!
Re: [whatwg] Iframe dimensions
On Wed, Aug 11, 2010 at 8:05 AM, Markus Ernst derer...@gmx.ch wrote: Am 11.08.2010 00:24 schrieb Ian Hickson: On Mon, 5 Jul 2010, Markus Ernst wrote: 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. A solution at authoring level for cases where the author controls both pages would be quite helpful. I think of a meta element in the embedded document that specifies one or more domains that are allowed to embed it seamlessly in an iframe, such as e.g.: meta name=allow-seamless-embedding name=domain.tld, otherdomain.tld I think that this would be ok from a security POV, and much easier than using CORS. That feels like re-inventing CORS. Maybe we should make CORS easier to use instead? Adam
Re: [whatwg] Iframe dimensions
On Wed, 11 Aug 2010 19:03:28 +0200, Adam Barth w...@adambarth.com wrote: On Wed, Aug 11, 2010 at 8:05 AM, Markus Ernst derer...@gmx.ch wrote: A solution at authoring level for cases where the author controls both pages would be quite helpful. I think of a meta element in the embedded document that specifies one or more domains that are allowed to embed it seamlessly in an iframe, such as e.g.: meta name=allow-seamless-embedding name=domain.tld, otherdomain.tld I think that this would be ok from a security POV, and much easier than using CORS. That feels like re-inventing CORS. Maybe we should make CORS easier to use instead? What exactly is hard about it? (Though I should note we should carefully study whether using CORS here is safe and sound. For instance, you may want to allow seamless embedding, but not share content.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [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 iframes 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Iframe dimensions
Am 06.07.2010 22:41 schrieb Ashley Sheridan: On Tue, 2010-07-06 at 16:17 -0400, Aryeh Gregor wrote: On Tue, Jul 6, 2010 at 6:49 AM, Markus Ernst derer...@gmx.ch mailto:derer...@gmx.ch 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. Oh. Hmm. That does seem to pose a problem. I can't think of any good solutions off the top of my head. 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. This looks consistent to me. To clarify it, the first list item in the part on @seamless in 4.8.2 could then be extended somehow like: o The user agent must set the seamless browsing context flag to true for that browsing context. This will cause links to open in the parent browsing context, unless they contain a target attribute which explicitly specifies another link target. (I assume, links also refers to form actions here.)
Re: [whatwg] Iframe dimensions
On Tue, Jul 6, 2010 at 4:41 PM, Ashley Sheridan a...@ashleysheridan.co.uk 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. It doesn't. The iframe is considered part of the parent page for the purposes of navigation, so _self refers to the parent page. See the full algorithm: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate Step 3 there does not take into consideration how the browsing context to be navigated was chosen. Anything that tries to navigate the seamless iframe in any way will navigate the first non-seamless ancestor instead. That includes a regular old link, a link with target=_self explicit, navigation by JavaScript, and any other possible way of navigating. This is intended and correct for the use-cases that seamless was designed for. On Wed, Jul 7, 2010 at 10:15 AM, Markus Ernst derer...@gmx.ch wrote: This looks consistent to me. To clarify it, the first list item in the part on @seamless in 4.8.2 could then be extended somehow like: o The user agent must set the seamless browsing context flag to true for that browsing context. This will cause links to open in the parent browsing context, unless they contain a target attribute which explicitly specifies another link target. (I assume, links also refers to form actions here.) That doesn't change the conformance requirements that cause links to open in the parent browsing context links to. The target of that link is the detailed description of what that requirement means -- the bullet point in the iframe section is just an informative (and vague, and inaccurate) summary. You would have to change the navigation algorithm to figure out what triggered the navigation and so on. But I don't think this is desirable for the primary use-case of seamless.
Re: [whatwg] Iframe dimensions
Am 05.07.2010 22:50 schrieb Aryeh Gregor: On Mon, Jul 5, 2010 at 1:13 PM, Markus Ernst derer...@gmx.ch wrote: Some content from an external specialized content provider is included in an existing web site via an iframe. This cannot be seamless, as the links in the iframe must point to the original domain of the included document. But in order to avoid double scroll bars, it would be desirable to have the height of the iframe adjusted to it's content. This use-case is inherently insecure. An iframe's height cannot depend on the contents of a cross-origin page unless that origin explicitly opts in somehow. Thank you and Boris for your examples. I see the security issues. Anyway It would be very helpful in cases like mine, where security and privacy are not affected, to get an easy way to do this opt-in without the need of complex scripting, and independent from @seamless. Embedding content from external providers looks like a quite common case to me, and an easy opt-in mechanism would help both the customers and the providers of embedded content. Am 05.07.2010 22:50 schrieb Aryeh Gregor: On Mon, Jul 5, 2010 at 1:13 PM, Markus Ernst derer...@gmx.ch wrote: - Interpreting the CSS declaration display:block as the author's wish to get the iframe rendered like a block element is nothing but consistent. There has been no reason for authors to apply this declaration so far, but if anyone did, he/she wanted the rendering I suggest. If not (for example if the iframe is floating), he/she also applied dimensions, be it in the HTML or the CSS code. The author might or might not originally have wanted the behavior you said, but in the end, the site doesn't render that way, and changing the rendering like that would make the site look very different from the way it looked before (= the final product that the author was satisfied with and released). Am 06.07.2010 02:35 schrieb Boris Zbarsky: Experience shows this to not be the case. People blindly apply CSS without thinking through the implications as long as the current rendering is right; I will bet money there are pages out there that use display:block on iframes just to get linebreaks before/after and will break if the sizing behavior changes. A BC problem with display:block would only occur if an author applied this declaration _without_ applying dimensions, which looks quite weird to me. I admit I have no statistics about this, and no means to get statistics. But I can hardly imagine that there are many pages like this out there, as the default dimensions that browsers apply to iframes are quite special. But anyway, I do not insist in this solution, it was just an idea that looked consistent to me as an author with little technical backgrownd knowledge.
Re: [whatwg] Iframe dimensions
On Tue, Jul 6, 2010 at 4:40 AM, Markus Ernst derer...@gmx.ch wrote: Thank you and Boris for your examples. I see the security issues. Anyway It would be very helpful in cases like mine, where security and privacy are not affected, to get an easy way to do this opt-in without the need of complex scripting, and independent from @seamless. Embedding content from external providers looks like a quite common case to me, and an easy opt-in mechanism would help both the customers and the providers of embedded content. So what you're saying is that you really do just want seamless= with easy cross-origin opt-in, right? That sounds entirely logical, and I'm not sure why it's not specced already (or at least I don't see it). Could this be easily added to CORS? CORS isn't so easy to set up, of course, but I'm not sure it's practical to do better. An HTML tag would work, for HTML pages (the common case for iframes), but then the UA wouldn't know whether it's allowed to be seamless until it started parsing the response, which might have complications. I don't know why you keep saying independent from @seamless without giving any reason for it. Seamless seems like exactly what you want.
Re: [whatwg] Iframe dimensions
Am 06.07.2010 12:31 schrieb Aryeh Gregor: On Tue, Jul 6, 2010 at 4:40 AM, Markus Ernst derer...@gmx.ch wrote: Thank you and Boris for your examples. I see the security issues. Anyway It would be very helpful in cases like mine, where security and privacy are not affected, to get an easy way to do this opt-in without the need of complex scripting, and independent from @seamless. Embedding content from external providers looks like a quite common case to me, and an easy opt-in mechanism would help both the customers and the providers of embedded content. So what you're saying is that you really do just want seamless= with easy cross-origin opt-in, right? That sounds entirely logical, and I'm not sure why it's not specced already (or at least I don't see it). Could this be easily added to CORS? CORS isn't so easy to set up, of course, but I'm not sure it's practical to do better. An HTML tag would work, for HTML pages (the common case for iframes), but then the UA wouldn't know whether it's allowed to be seamless until it started parsing the response, which might have complications. I don't know why you keep saying independent from @seamless without giving any reason for it. Seamless seems like exactly what you want. 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.
Re: [whatwg] Iframe dimensions
On Tue, Jul 6, 2010 at 6:49 AM, Markus Ernst derer...@gmx.ch 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. Oh. Hmm. That does seem to pose a problem. I can't think of any good solutions off the top of my head.
Re: [whatwg] Iframe dimensions
On Tue, 2010-07-06 at 16:17 -0400, Aryeh Gregor wrote: On Tue, Jul 6, 2010 at 6:49 AM, Markus Ernst derer...@gmx.ch 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. Oh. Hmm. That does seem to pose a problem. I can't think of any good solutions off the top of my head. 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. Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] Iframe dimensions
Hello 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. 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. But there are some special indications in the part about the @seamless attribute: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-seamless quote o In visual media, in a CSS-supporting user agent: the user agent should set the intrinsic width of the iframe to the width that the element would have if it was a non-replaced block-level element with 'width: auto'. o In visual media, in a CSS-supporting user agent: the user agent should set the intrinsic height of the iframe to the height of the bounding box around the content rendered in the iframe at its current width (as given in the previous bullet point), as it would be if the scrolling position was such that the top of the viewport for the content rendered in the iframe was aligned with the origin of that content's canvas. /quote First, this sounds somehow complicated to me, 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. 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. Use case: Some content from an external specialized content provider is included in an existing web site via an iframe. This cannot be seamless, as the links in the iframe must point to the original domain of the included document. But in order to avoid double scroll bars, it would be desirable to have the height of the iframe adjusted to it's content. 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. Possible solutions: - Invent an attribute that makes the iframe element behave like any block element (independent from @seamless) - Respect the CSS display property; display:block would then make an iframe rendered like a block element While I personally would be happy with the second solution, I have no idea if this can be specced in HTML5, as it is CSS. And AFAICS the CSS specs do not cover individual HTML elements. I'd be happy about some comments!
Re: [whatwg] Iframe dimensions
On Mon, Jul 5, 2010 at 10:13 AM, Markus Ernst derer...@gmx.ch wrote: First, this sounds somehow complicated to me, 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. One of the reasons is security: if we automatically sized iframes, an attacker could learn things about documents in other origins. Another reason is compatibility: changing how frames layout would likely break the layout of a large number of web sites. Adam
Re: [whatwg] Iframe dimensions
Am 05.07.2010 19:24 schrieb Adam Barth: On Mon, Jul 5, 2010 at 10:13 AM, Markus Ernst derer...@gmx.ch wrote: First, this sounds somehow complicated to me, 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. One of the reasons is security: if we automatically sized iframes, an attacker could learn things about documents in other origins. I can't imagine how the information about the computed width and height can be abused - would you mind giving an example? A possible workaround to security issues could be an element to be set in the included document, such as a meta tag that contains a comma separated list of domains that are allowed to include the document, and also get informations about dimensions and such. Some kind of: meta name=allow-embedding content=whatwg.org, mozilla.com Also, if this is a potential danger, should the 2 list paragraphs about width and height in the part on @seamless be removed at all? As far as I understand, the effects of @seamless require the iframe source to be from the same origin as the parent document, thus I think that width and height of an iframe should be computed independent from @seamless. Else, the whole page layout is likely to change if the iframe source is navigated from a same-origin document to one from another origin. Another reason is compatibility: changing how frames layout would likely break the layout of a large number of web sites. I don't think the 2 solutions I proposed would do any BC harm: - Inventing a new attribute does not affect legacy browsers (as they will ignore it), nor legacy pages (as they don't have it). - Interpreting the CSS declaration display:block as the author's wish to get the iframe rendered like a block element is nothing but consistent. There has been no reason for authors to apply this declaration so far, but if anyone did, he/she wanted the rendering I suggest. If not (for example if the iframe is floating), he/she also applied dimensions, be it in the HTML or the CSS code.
Re: [whatwg] Iframe dimensions
On Mon, Jul 5, 2010 at 1:13 PM, Markus Ernst derer...@gmx.ch wrote: Some content from an external specialized content provider is included in an existing web site via an iframe. This cannot be seamless, as the links in the iframe must point to the original domain of the included document. But in order to avoid double scroll bars, it would be desirable to have the height of the iframe adjusted to it's content. This use-case is inherently insecure. An iframe's height cannot depend on the contents of a cross-origin page unless that origin explicitly opts in somehow. 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. I can't find it either. If it's really not specced anywhere, that's a bug that should be fixed. On Mon, Jul 5, 2010 at 3:37 PM, Markus Ernst derer...@gmx.ch wrote: I can't imagine how the information about the computed width and height can be abused - would you mind giving an example? For a basic example, suppose that a page on some site is reliably a different height depending on whether you're logged in or not (this is usually true). Then when you visit my site, I could create a hidden iframe with the other site inside, and measure the height from JavaScript. Then I'd know whether you're logged in on that site. There are lots of other conditions that would change the height of a page, and they could leak a large amount of information to arbitrary third-party sites. No site should be able to find out anything about your use of another site, to the extent possible. A possible workaround to security issues could be an element to be set in the included document, such as a meta tag that contains a comma separated list of domains that are allowed to include the document, and also get informations about dimensions and such. Some kind of: meta name=allow-embedding content=whatwg.org, mozilla.com This could be handled by seamless using CORS or whatever, sure. Also, if this is a potential danger, should the 2 list paragraphs about width and height in the part on @seamless be removed at all? As far as I understand, the effects of @seamless require the iframe source to be from the same origin as the parent document, thus I think that width and height of an iframe should be computed independent from @seamless. Else, the whole page layout is likely to change if the iframe source is navigated from a same-origin document to one from another origin. You're correct: if you navigate the iframe to a different origin, the iframe will no longer be seamless, and all the effects of seamless will cease to apply. This means it will change height and width, CSS rules won't apply, etc., etc. The presence of seamless= does definitely change the width and height computations, and many other things. I don't think the 2 solutions I proposed would do any BC harm: - Inventing a new attribute does not affect legacy browsers (as they will ignore it), nor legacy pages (as they don't have it). Yes, this is why the seamless attribute works. - Interpreting the CSS declaration display:block as the author's wish to get the iframe rendered like a block element is nothing but consistent. There has been no reason for authors to apply this declaration so far, but if anyone did, he/she wanted the rendering I suggest. If not (for example if the iframe is floating), he/she also applied dimensions, be it in the HTML or the CSS code. The author might or might not originally have wanted the behavior you said, but in the end, the site doesn't render that way, and changing the rendering like that would make the site look very different from the way it looked before (= the final product that the author was satisfied with and released).
Re: [whatwg] Iframe dimensions
On 7/5/10 12:37 PM, Markus Ernst wrote: I can't imagine how the information about the computed width and height can be abused - would you mind giving an example? Sure. For example, you can often use this to detect whether the user is currently logged into the site in the iframe, which is a privacy leak. Depending on the target site, other things that might be exposed this way are things like the number of credit card transactions the user has performed in the last month, the number of phone calls the user has made in the last month... you get the idea. A possible workaround to security issues could be an element to be set in the included document, such as a meta tag that contains a comma separated list of domains that are allowed to include the document, and also get informations about dimensions and such. Some kind of: meta name=allow-embedding content=whatwg.org, mozilla.com How is this different from allowing opt-in into seamless iframes across origins? Also, if this is a potential danger, should the 2 list paragraphs about width and height in the part on @seamless be removed at all? As far as I understand, the effects of @seamless require the iframe source to be from the same origin as the parent document, thus I think that width and height of an iframe should be computed independent from @seamless. Else, the whole page layout is likely to change if the iframe source is navigated from a same-origin document to one from another origin. Yes, it will. Why is this a problem? There has been no reason for authors to apply this declaration so far, but if anyone did, he/she wanted the rendering I suggest. Experience shows this to not be the case. People blindly apply CSS without thinking through the implications as long as the current rendering is right; I will bet money there are pages out there that use display:block on iframes just to get linebreaks before/after and will break if the sizing behavior changes. -Boris
