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

xframe or iframe type='cross-domain'

From: John J Barton <johnjbarton@johnjbarton.com>
Date: Thu, 9 Feb 2012 09:04:33 -0800
Message-ID: <CAFAtnWysW3t_7Q=6QDMKFWv5-F1rLQyV3F_v7twRwN4TDJw52w@mail.gmail.com>
To: public-webapps@w3.org
I've been working with cross-domain iframes. This technology has a lot
of potential, but the current API is very difficult to use. Just
search the web for cross-domain iframe info and you can read how many
developers are confused.

I believe a simple change could make a huge difference. My suggestions
are related to http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html

The current model for a cross-domain iframe is "it's just a restricted
same-domain iframe". So both iframes have a contentWindow property as
their key API anchor. Sounds consistent and economical. But it's not,
because developer code written to process contentWindow references
cannot work with cross-domain iframe contentWindow objects.

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.

On the other hand, there is an important Web API focused on
postMessage() as outlined in the spec above. Generally (though not
exclusively) the spec refers to objects with postMessage() as "ports".

Thus my proposal:
  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"
  4. Access to xframe.contentWindow would result  in "undefined"
(yay!, no funky errors)
  5. Access to iframe.port would result in 'undefined': developers now
have a simple test.
  6. xframe.port would have "postMessage". I believe the port could in
fact be a MessagePort.

I know that some may view this suggestion as trivial. I would just ask
you to talk to web app developers who have tried or considered using
cross-domain iframe messaging.

Received on Thursday, 9 February 2012 17:05:09 UTC

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