A DOM use case that can't be emulated with direct proxies

Mark S. Miller erights at google.com
Fri Dec 14 11:07:31 PST 2012


On Fri, Dec 14, 2012 at 10:19 AM, Brendan Eich <brendan at mozilla.com> wrote:
> David Bruant wrote:
>>
>> Le 14/12/2012 08:25, Brendan Eich a écrit :
>>>
>>> window.location can be set by assignment to navigate to a new URL.
>>
>> location is [Unforgeable, PutForward], so it should be reflected as a
>> non-configurable getter+setter according to WebIDL.
>
>
> That would be correct -- and nice, I agree.
>
>
>>> Yet it appears in Chrome, Firefox, Opera, and Safari to be a writable
>>> data property.
>>
>> oh, web browsers and standards...
>> There is indeed a pretty violent mismatch between WebIDL and reality, I
>> guess. Specifically because of the behavior you're describing (assigning
>> window.location having a behavior), location ought to be an accessor.
>> What was the rationale that motivated all these browsers to go for data
>> property? Is it still time to change this behavior?
>
>
> Let's not make the standards-are-prior-to-implementations mistake. All this
> came from Netscape 2, JS1. It got cloned by IE and other browsers. It
> mutated and was not standardized until a decade later, in HTML5 and then
> DOM4 -- and WebIDL is an even later (still not REC, it's in CR if I recall
> correctly) standard.
>
> Nevertheless, since ES5-standard reflection is new, I doubt anyone cares
> that location appears to be a data property. It should be an accessor. But
> it needs to be non-configurable, so we still have a problem -- or do we?

AFAICT, a non-configurable accessor fits all the constraints.


>
> /be
>



--
    Cheers,
    --MarkM


More information about the es-discuss mailing list