- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 7 Jan 2013 20:26:29 +0000 (UTC)
- To: Bobby Holley <bobbyholley@gmail.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Matt Wobensmith <mwobensmith@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, Adam Barth <w3c@adambarth.com>, Johnny Stenback <jst@mozilla.com>
On Tue, 20 Nov 2012, Bobby Holley wrote: > On Tue, Nov 20, 2012 at 9:46 AM, Ian Hickson <ian@hixie.ch> wrote: > > > > In thinking about this further last night, it struck me that while the > > proposed proxy mechanism was IMHO overly complex, there might be a > > simpler mechanism that still gets all the compatibility needs, and > > works for Mozilla, and isn't quite so crazy. I'm not a huge fan of > > this, but I'd be interested in what Adam thinks of it. > > > > Right now, as specced, each Document gets a Location object, but they > > all act the same: they all work on the active document and they all do > > security checks based on the active document, not the Location's > > Document. > > > > But what if, instead, we had one Location per Document, and it worked > > on that Document (not the active document), with the security policy > > being like Window, specific to its Document's effective origin, but > > instead of ever getting references to it, you only got references to a > > proxy that acted on the active document's Location? > > Wouldn't this effectively mean having a LocationProxy, just like > WindowProxy? Yes. It differs from the original proposal in that there's multiple underlying objects and they're just proxied, not just one object that has its prototype and properties changed when the history is traversed. > I'm certainly all for it, and think that it makes things much more sane, > though I don't understand why this wouldn't "propagate the magic" that > Adam doesn't want to propagate. I might be misunderstanding you though. > Can you clarify? I agree that it does seem to be still more complicated than is apparently necessary, at least for implementations where determining the calling script's effective script origin is relatively easy. My understanding is that WebKit, old Gecko, and new IE do what the spec says currently, and old IE, Opera, and new Gecko do the proxying model. For authors, I don't really see the value of the proxying model. The current spec model is slightly simpler for authors, but only slightly, because you still can't access your own shims when the page is navigated to another origin. For implementors, I'm not really comfortable picking one side or the other here. I'm even less comfortable picking what's easy for Chrome over what's easy for Gecko. Browsers seem to be changing in both directions, and right now seem to be exactly equally split. So, I dunno. If it's a bust for authors, a tie for browsers, I guess the next level is spec writers, and, well, not changing anything is easier than changing something, so I guess that argues for not changing it? I've left the spec as-is for now, but I don't have a good argument one way or the other. Sorry for this unsatisfying answer. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 7 January 2013 20:26:52 UTC