- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 6 Jan 2006 12:15:54 -0800
- To: Jim Ley <jim@jibbering.com>
- Cc: www-svg@w3.org
On Jan 6, 2006, at 12:02 PM, Jim Ley wrote:
>
>
> "Maciej Stachowiak" <mjs@apple.com> wrote in message
> news:53D8B252-770E-415E-92D0-D0AEEB943A02@apple.com...
>> So the failure is due to a totally independent IE bug, not
>> because IE
>> doesn't update handlers for DOM changes, as far as I can tell.
>
> There is no specification which states what happens when you
> el.setAttribute("onclick") not DOM 1 HTML or DOM 2 HTML both which
> talk
> about setting el.onclick.
>
> It is not a bug, simply because it differs to the assumption other
> implementations have made about unspecified things.
Try this in IE:
<span id="foo" onclick="alert('1')">click</span>
<script>
alert(document.getElementById("foo").getAttribute("onclick"));
</script>
It will display a function object, not a string. That is a bug and
violates the DOM spec. IE has a general bug of this nature, where it
expects types for certain values to getAttribute and setAttribute to
be something other than strings.
Try this in IE:
<span id="foo" onclick="alert('1')">click</span>
<script>
document.getElementById("foo").setAttribute("onclick", function()
{ alert('2'); });
</script>
It will alert 2 when you click (at least that's how it works in Mac
IE, I expect Win IE would be the same). Excepting an attribute to
have a value of a function rather than a string is a bug and violates
the DOM spec.
It's true that whether DOM changes should affect the set of handlers
is unspecified, but there is in fact a single de facto behavior,
though it can be hard to test due to IE's attribute handling bugs.
Regards,
Maciej
Received on Friday, 6 January 2006 20:16:07 UTC