W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: xframe or iframe type='cross-domain'

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 09 Feb 2012 12:22:43 -0500
Message-ID: <4F3400E3.6000306@mit.edu>
To: public-webapps@w3.org
On 2/9/12 12:04 PM, John J Barton wrote:
> As far as I can tell, a cross-domain iframe contentWindow has only one
> valid property, postMessage(). By no stretch of anyone's imagination
> is the object a "window". Calling this thing we get a "contentWindow"
> is a mean lie to developers; it forces us into "Exception-oriented
> programming" where we try every recipe on the Web looking for
> something that does not emit errors.

So here's the thing.  If the element is called <iframe> it needs to have 
a contentWindow property.  The thing that cross-domain iframes return 
could be returned from some other property, but what should 
contentWindow then return for cross-domain iframes?

Of course using a different element name solves that problem.

>    1. create a spec-only base class element with the current properties
> of iframe, except no "contentWindow" or "contentDocument"
>    2. inherit iframe from the spec-only base class, add contentWindow
> and contentDocument
>    3. inherit a new element (eg xframe) or element type (eg iframe
> type='cross-domain'), add property "port"

It'd have to be a new element if it has a different API.

The benefit is a cleaner API and not having to define what happens when 
the type changes.

The drawback is that your fallback behavior in UAs without support for 
the new feature is quite different.  Is that a problem?  Developer 
feedback definitely needed there.

Received on Thursday, 9 February 2012 17:23:11 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC