- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 09 Feb 2012 12:22:43 -0500
- 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. -Boris
Received on Thursday, 9 February 2012 17:23:11 UTC