W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

Re: SVGT 1.2: dynamic changes to <handler> elements

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 6 Jan 2006 12:15:54 -0800
Message-Id: <E6993D2D-4D06-4D91-81F7-8578F0B3E899@apple.com>
Cc: www-svg@w3.org
To: Jim Ley <jim@jibbering.com>

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>


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>

document.getElementById("foo").setAttribute("onclick", function()  
{ alert('2'); });

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.

Received on Friday, 6 January 2006 20:16:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:06 UTC