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