On 7/31/14, 2:47 PM, Jason Orendorff wrote:
Please pass along to the WebIDL editor(s) that this can be done
by specifying that [[PreventExtensions]] returns false.
Excellent. https://www.w3.org/Bugs/Public/show_bug.cgi?id=26490
If "location" is exempt from shadowing, then it can be exempt fr
On Thu, Jul 31, 2014 at 1:24 PM, Boris Zbarsky wrote:
> On 7/31/14, 9:43 AM, Jason Orendorff wrote:
>> Right Thing: I think [[PreventExtensions]] on these objects should
>> always return false.
>
> The Web IDL spec requires this already, fwiw: [...]
>
> If there is an actual hook it can hook into
On 7/31/14, 9:43 AM, Jason Orendorff wrote:
On Thu, Jul 31, 2014 at 1:23 AM, Boris Zbarsky wrote:
Requiring a single namespace, such that adding an input and then removing it
would make a previous property with the same name as the input go away,
would actually be fairly annoying performance-wi
2014-07-31 15:26 GMT+02:00 Jason Orendorff :
> There's not a rule that says flat-out, "If Desc.[[Configurable]] is
> false and [[DefineOwnProperty]](P, Desc) returns true, that counts as
> 'observing' the property P as a non-configurable property on the
> target." but if you take that as read, wha
2014-07-31 15:43 GMT+02:00 Jason Orendorff :
> Right Thing: I think [[PreventExtensions]] on these objects should
> always return false. I think [[DefineProperty]] on these objects
> should return false if Desc.[[Configurable]] is false or if it's
> missing and would default to false. That'll caus
On Thu, Jul 31, 2014 at 1:23 AM, Boris Zbarsky wrote:
> Requiring a single namespace, such that adding an input and then removing it
> would make a previous property with the same name as the input go away,
> would actually be fairly annoying performance-wise, I suspect.
Really? There are web pag
On Thu, Jul 31, 2014 at 1:23 AM, Boris Zbarsky wrote:
> And the Web IDL spec has yet another approach to this whole thing: It simply
> coerces "configurable" to true in its custom [[DefineOwnProperty]] for these
> sorts of objects (but keeps effectively separate namespaces).
Interesting. This app
On 7/31/14, 1:53 AM, Tom Van Cutsem wrote:
If I understand correctly, the form DOM element's named input properties
'shadow' the actual JS properties defined on the DOM object.
That certainly seems to be what some UAs do, yes.
This seems bad. I'm not a DOM expert, but is it essential that the
Hi Boris,
It seems you're right (reproduced on Chrome and Safari). These examples
clearly violate all the invariants related to non-configurable properties.
If I understand correctly, the form DOM element's named input properties
'shadow' the actual JS properties defined on the DOM object. Even i
I was trying to determine what browsers do with named properties on
elements, and I'm getting some rather strange results.
Consider https://bugzilla.mozilla.org/attachment.cgi?id=8463423 and
https://bugzilla.mozilla.org/attachment.cgi?id=8463432
Is it just me, or do Chrome and IE violate the
10 matches
Mail list logo
