[Bug 22320] Form's supported property names should perhaps not be enumerable

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22320

--- Comment #26 from Mark S. Miller <erights@gmail.com> ---
(In reply to comment #24)
> (In reply to comment #6)
> > > Not sure what warning I'd put where, exactly.
> > 
> > To the part about the set of supported names on form, about how the
> > enumeration behavior this implies is not necessarily all that final...
> 
> Sorry, I missed that, since the bug wasn't assigned to me.
> 
> I'll add something to the HTML spec saying that the names shouldn't be
> enumerable for now. When WebIDL gives me a more formal way to do this, I'll
> update this (and navigator.plugins, etc) to do it that way.
> 
> As far as the order goes, I don't mind what it is, if you want a different
> order just file a bug for it. As you say, we just need _an_ order.

Hi Ian, because in this thread we've discussed both whether certain own
properties are "enumerable" in the ES sense (enumerated by for/in loops and
Object.keys) and whether certain own properties are enumerated by
getOwnProperties -- which should enumerate all own properties, whether
enumerable or not. I just want to be sure what you're referring to.

There is no problem with these properties being non-enumerable. And I think
Boris and I just established that there's neither a compat nor a spec
conformance conflict with have all own properties be enumerated by
getOwnPropertyNames. And there is an ES spec conformance issue with having
these not be enumerated by getOwnPropertyNames.

As for whether we need "_an_ order", I would certainly prefer one and do not
understand why this would be expensive. But the WebIDL spec doesn't seem to
demand an order.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 9 July 2013 20:46:51 UTC