On Sat, 8 Aug 2009, Adam Barth wrote:
> On Fri, Aug 7, 2009 at 5:51 PM, Ian Hickson wrote:
> > How should I address this for HTML5?
>
> We talked over several option in #whatwg. Here's something that might
> make sense. The approach below is designed to allow for robust
> implementation and to i
On Fri, Aug 7, 2009 at 5:51 PM, Ian Hickson wrote:
> How should I address this for HTML5?
We talked over several option in #whatwg. Here's something that might
make sense. The approach below is designed to allow for robust
implementation and to isolated the "magical" properties in the window
obj
On Thu, 16 Jul 2009, Maciej Stachowiak wrote:
> On Jul 16, 2009, at 8:04 PM, Ian Hickson wrote:
> > On Thu, 16 Jul 2009, Maciej Stachowiak wrote:
> > > >
> > > > HTML5 just says that new History, Location, etc, objects are
> > > > created for each (inner) Window object. Is this not accurate? What
On Jul 16, 2009, at 8:04 PM, Ian Hickson wrote:
On Thu, 16 Jul 2009, Maciej Stachowiak wrote:
HTML5 just says that new History, Location, etc, objects are created
for each (inner) Window object. Is this not accurate? What do
browsers
do?
Creating new ones on navigation is indeed correct,
On Thu, 16 Jul 2009, Maciej Stachowiak wrote:
> >
> > HTML5 just says that new History, Location, etc, objects are created
> > for each (inner) Window object. Is this not accurate? What do browsers
> > do?
>
> Creating new ones on navigation is indeed correct, but a separate issue
> from makin
On Jul 16, 2009, at 5:58 PM, Ian Hickson wrote:
On Thu, 16 Jul 2009, Maciej Stachowiak wrote:
On Jul 16, 2009, at 3:08 PM, Jonas Sicking wrote:
I definitely agree you definitely don't want the inner windows
prototype values if it's a cross-origin window. What you should
get is
less clear
On Thu, 16 Jul 2009, Maciej Stachowiak wrote:
> On Jul 16, 2009, at 3:08 PM, Jonas Sicking wrote:
> >
> > I definitely agree you definitely don't want the inner windows
> > prototype values if it's a cross-origin window. What you should get is
> > less clear to me.
> >
> > If you should get the
On Jul 16, 2009, at 3:08 PM, Jonas Sicking wrote:
I definitely agree you definitely don't want the inner windows
prototype values if it's a cross-origin window. What you should get is
less clear to me.
If you should get the outer windows prototype or some sort of blank
prototype. Personally i
On Thu, Jul 16, 2009 at 3:08 PM, Jonas Sicking wrote:
> On Thu, Jul 16, 2009 at 2:59 PM, Maciej Stachowiak wrote:
>> One thing to note: any object or method that is exposed cross-origin should
>> specifically *not* have this behavior. Instead, it should create a separate
>> interface object in ever
On Thu, Jul 16, 2009 at 2:58 PM, Jonas Sicking wrote:
> There's currently a bug in 3.5 which is why functions are failing. It
> is fixed in the upcoming 3.5.1 release.
>
> The only other non-"PASS" thing I see in firefox is .content, which
> basically is the same as .top and so is working as expect
On Thu, Jul 16, 2009 at 2:59 PM, Maciej Stachowiak wrote:
>
> On Jul 16, 2009, at 10:45 AM, Adam Barth wrote:
>
>> When a browser creates an instance of a DOM object defined by an
>> WebIDL interface, the browser must choose where to connect it's
>> prototype chain. For example, consider this case
On Jul 16, 2009, at 10:45 AM, Adam Barth wrote:
When a browser creates an instance of a DOM object defined by an
WebIDL interface, the browser must choose where to connect it's
prototype chain. For example, consider this case (where frames[0] is
a same-origin child frame):
var doc = frames[0]
On Thu, Jul 16, 2009 at 2:44 PM, Jonas Sicking wrote:
> On Thu, Jul 16, 2009 at 1:52 PM, Adam Barth wrote:
>> On Thu, Jul 16, 2009 at 1:13 PM, Jonas Sicking wrote:
>>> On Thu, Jul 16, 2009 at 10:45 AM, Adam Barth wrote:
When a browser creates an instance of a DOM object defined by an
WebI
On Thu, Jul 16, 2009 at 1:52 PM, Adam Barth wrote:
> On Thu, Jul 16, 2009 at 1:13 PM, Jonas Sicking wrote:
>> On Thu, Jul 16, 2009 at 10:45 AM, Adam Barth wrote:
>>> When a browser creates an instance of a DOM object defined by an
>>> WebIDL interface, the browser must choose where to connect it's
On Thu, Jul 16, 2009 at 10:45 AM, Adam Barth
wrote:
When a browser creates an instance of a DOM object defined by an
WebIDL interface, the browser must choose where to connect it's
prototype chain.
Hopefully, we can spec the behavior non-DOM objects, like
Array.prototype.push, and primitives
On Thu, Jul 16, 2009 at 1:13 PM, Jonas Sicking wrote:
> On Thu, Jul 16, 2009 at 10:45 AM, Adam Barth wrote:
>> When a browser creates an instance of a DOM object defined by an
>> WebIDL interface, the browser must choose where to connect it's
>> prototype chain. For example, consider this case (wh
On Thu, Jul 16, 2009 at 10:45 AM, Adam Barth wrote:
> When a browser creates an instance of a DOM object defined by an
> WebIDL interface, the browser must choose where to connect it's
> prototype chain. For example, consider this case (where frames[0] is
> a same-origin child frame):
>
> var doc
When a browser creates an instance of a DOM object defined by an
WebIDL interface, the browser must choose where to connect it's
prototype chain. For example, consider this case (where frames[0] is
a same-origin child frame):
var doc = frames[0].document;
1) To which global object's prototypes o
18 matches
Mail list logo
