W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2010

[whatwg] Iframe dimensions

From: Markus Ernst <derernst@gmx.ch>
Date: Tue, 16 Nov 2010 09:02:43 +0100
Message-ID: <4CE23AA3.6050300@gmx.ch>
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
Received on Tuesday, 16 November 2010 00:02:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:28 UTC