[thelist] Workaround for setAttribute bug in IE7?

Matt Warden mwarden at gmail.com
Thu Dec 14 13:23:33 CST 2006


On 12/14/06, Lee kowalkowski <lee.kowalkowski at googlemail.com> wrote:
> I'm not deliberately overlooking your point.  It's more like:  Who
> would expect location.href=url to load a new document when
> location.assign(url) is a better match for the behaviour?  I just
> think setAttribute is a poor example of the same argument, because
> setAttribute is merely an encapsulated assignment.

Absolutely correct. The side effect of location.href changes is much
more severe and even more ridiculous. setAttribute was the topic, so
that's what I was sticking with. But there are a lot of similar
questionable decisions in JavaScript implementations, like using
selectbox.selectedIndex = 3 to change the currently selected element.

> I also think you're focusing too much on distinguishment between an
> attribute and a property; they're essentially synonyms for "variable".
>  With a good JavaScript binding to the HTML DOM, the assignment
> operator is sufficiently overloaded to ensure there isn't any actual
> difference (huh, in *most* cases).

If we were talking about a tree that existed wholly in the JavaScript
world, I could perhaps agree. But we are talking about a tree that
represents a document. Take a look at other OO DOM implementatons. Do
they allow this? See: http://php.net/dom-domelement-setattribute

An attribute and a property are the same thing. I totally agree. I was
using the terms to make sure that I conveyed that I'm talking about a
element attribute in the document rather than an object property in
JavaScript. You're saying they are the same thing, and of course in
this case they are. I'm just saying that's a bad idea, as (I would
assume) the authors of other implementations of DOM agree. It is a
mixing of semantics. If you operate on something (like, say, a
document), it should be a method. (Let alone that good programming
practice strongly suggests that even when getting and setting object
properties one use accessors and mutators.)

In your other email:

> In IE, input.foo = "bar" *is* a DOM manipulation, unless
> document.expando == false, in which case IE actually throws an
> exception when you try to do input.foo = "bar" *OR*
> input.setAttribute("foo", "bar").
...
>   document.expando = false;
>   ... // some DOM manipulation that doesn't appear to work
>   document.expando = true;

I must admit that I thought this was a joke. Expando? Sounds like half
of a super hero's name (Captain Expando?). Thanks to a fruitful google
search, it seems I'm just out of the loop:

http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/expando.asp

Utterly weird. So, input.foo = "bar" literally creates an attribute
*in the document* called foo? Then why doesn't selectbox.selectedIndex
= 3 create an attribute in the document called selectedIndex?
(rhetorical) There still seems to be a subset of object properties on
node objects that don't map to an attribute in the DOM. I'm trying to
get straight in my head when an object property wouldn't map, but I'm
failing to find any kind of reasonable answer.

Thanks for the tip on expando. Hadn't run across that before.

-- 
Matt Warden
Cleveland, OH, USA
http://mattwarden.com


This email proudly and graciously contributes to entropy.



More information about the thelist mailing list