- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 06 May 2011 11:06:39 -0400
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- CC: Cameron McCormack <cam@mcc.id.au>, public-script-coord@w3.org
On 5/5/11 8:52 PM, Boris Zbarsky wrote:
>> Well, the [OverrideBuiltins] behavior sounds like the normal native JS
>> behavior.
>
> Yes. However the normal native JS behavior is too restrictive for what's
> needed here.
One other important note. Consider this testcase, with line numbers:
1: var nodelist = document.getElementsByTagName("div");
2: nodelist.myExpando = "1";
3: alert(nodelist.myExpando);
4: document.getElementById("somebox").innerHTML =
5: someStringFromMyCMS;
6: alert(nodelist.myExpando);
What will the alerts show? Well, it depends. Some possibilities:
1a) If there is a div with id myExpando in the document at line 1,
then the first alert shows that div, no matter whether
[OverrideBuiltins] is set.
1b) If there is no such div, the first alert shows "1".
2a) If [OverrideBuiltins] the second alert could show "1" or a div
element or undefined, depending on what HTML was removed an
what HTML was added.
2b) If not [OverrideBuiltins] then at least in cases where the first
alert showed "1" so will the second alert.
All of which is to say that this API is terrible to start with. But
it's here and we're stuck with it. For webidl's purposes, we should try
to make it as sane as possible for authors, which is why it doesn't use
[OverrideBuiltins] in browsers right now... (Of course not having
[OverrideBuiltins] also has weird proto chain stuff going on, but let's
ignore that for the moment; I'm more interested in own property handling.)
-Boris
Received on Friday, 6 May 2011 15:07:12 UTC