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

On Thu, Feb 9, 2012 at 9:22 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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?

If we added 'port' to iframe and if we managed to change all of the
documentation to point devs toward iframe.port for messaging, then it
would be ok if contentWindow remained as it is now. I would expect
that the Web would quickly direct developers who have problems using
contentWindow towards using port.

We already have some emerging libraries for postMessage communications, eg
https://github.com/kriskowal/q-comm
My suggestion just help devs attach the right thing to these
libraries: they need a 'port'.

>
> 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.

Extending the API on iframe would make fallback easy even though it
lacks elegance:
  if (iframe.port) {
     // modern browser
  } else {
    // we still deal with contentWindow carefully for old timers
  }

jjb

Received on Thursday, 9 February 2012 17:43:46 UTC