W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Violations of internal method invariants?

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 31 Jul 2014 02:23:00 -0400
Message-ID: <53D9E0C4.40600@mit.edu>
To: Tom Van Cutsem <tomvc.be@gmail.com>
CC: es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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 form
> elements have two distinct namespaces (the namespace for named input
> elements and for regular JS properties), or is this just a side-effect
> of how they happen to be implemented?

That's an interesting question.

Gecko has totally different behavior here (we don't allow the form's 
named inputs to shadow own properties of the form if someone managed to 
define those, but will throw if you try to define a property for whose 
name we already have a named input.

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).

I believe that the one shared feature between Gecko, the spec, and the 
IE/Chrome implementation is that if you set a property "foo" on the 
form, then add an input with name="foo", then remove the input, the 
value you set initially will still be there.  Actually, the same is true 
in Safari, as long as you don't observe "form.foo" while the input is in 
the form.

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.

In any case, I would be very interested in figuring out what sane 
(sane-enough?) behavior UAs are willing to converge on here so we can 
actually spec it....  If anyone has suggestions for what that behavior 
should be, I'd love to hear them.  Since every UA except Gecko certainly 
needs to change _something_ here no matter what, seems like we might as 
well all change in the same direction.

-Boris
Received on Thursday, 31 July 2014 06:23:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC