IE6 won't hide dynamically created span elements

[Nicholas Couch]

I have a little form with a couple of dynamically generated list
boxes. When the user makes a selection from the first box, the second
box is refreshed. When they make a selection from the second box, I
concatenate the selections from the two boxes and add the string to a
list at the top of the form, using createElement and appendChild. The
list is actually a bunch of span elements contained within a div. Each
span element includes a small graphic of a red X, which the user can
click to delete that item from the list.

All of this works just fine in Mozilla and Opera, but - wait for it -
the delete functionality fails in IE, throwing an "Object Required"
error on this line:

this.style = document.getElementById(nm).style;

where nm is the ID of the span element I'm trying to hide, by setting
it's display property to "none."

What's really interesting is the fact that I have one or more span
elements in that div when the form first loads, and IE will hide these
HTML-based elements without complaining. It's only the spans that I
generate on the fly that it has a problem hiding.

Must be something wrong with the way I'm creating those dynamic spans,
you say? Maybe so, but IE does display them okay, and the code all
works great in the other two browsers. Now I'm no javascript veteran,
by any means, but this appears to me to be a bug in IE. What I asking
here is whether anybody knows of a workaround for this, or maybe a
better way of accomplishing what I'm trying to do.

Thanks in advance,
Blake Couch
Javascript Noob

 

[john henry bonham]

Nicholas Couch wrote:

this.style = document.getElementById(nm).style;

That should be 'nm' ...

this.style = document.getElementById('nm').style;

I can only guess that's your problem without actually looking at the code.

 

[Fred Oz]

Nicholas Couch wrote:
[snip]

All of this works just fine in Mozilla and Opera, but - wait for it -
the delete functionality fails in IE, throwing an "Object Required"
error on this line:

this.style = document.getElementById(nm).style;

where nm is the ID of the span element I'm trying to hide, by setting
it's display property to "none."

[snip]

You could try putting your elements inside <div> rather than
<span> - I think the effect is the same and you have much more
functionality available from divs. Try something like:

divRef.style.display='none';

where divRef is a reference to the div you want to hide.

I tried the above, it worked fine in Safari and IE 5.2 on
Mac - no guarantee for IE on Windows but I have done a similar
thing for Windows using divs and it works fine.

Cheers, Rob

 

[Richard Cornford]

Nicholas Couch wrote:

Must be something wrong with the way I'm creating those
dynamic spans, you say?
Yes.

Maybe so, but IE does display them okay, and the
code all works great in the other two browsers.

So it is not 100% faulty.

Now I'm no javascript veteran, by any means,

Obviously, as it doesn't take much experience to work out that in order
to debug code people need to be able to see it.

but this appears to me to be a bug in IE.

What, a web browser with a bug?

What I asking here is whether anybody knows of
a workaround for this,

It probably doesn't need a workaround. Cross browser code would probably
suffice.

or maybe a better way
of accomplishing what I'm trying to do.

What you are trying to do (at least claming that you are trying to do)
works successfully in IE browsers.

Richard.

 

[Nicholas Couch]

Nicholas Couch wrote:
[snip]

All of this works just fine in Mozilla and Opera, but - wait for it -
the delete functionality fails in IE, throwing an "Object Required"
error on this line:

this.style = document.getElementById(nm).style;

where nm is the ID of the span element I'm trying to hide, by setting
it's display property to "none."

[snip]

You could try putting your elements inside <div> rather than
<span> - I think the effect is the same and you have much more
functionality available from divs. Try something like:

divRef.style.display='none';

where divRef is a reference to the div you want to hide.

I tried the above, it worked fine in Safari and IE 5.2 on
Mac - no guarantee for IE on Windows but I have done a similar
thing for Windows using divs and it works fine.

Cheers, Rob

Thanks for the suggestion, but I've actually tried all sorts of
combinations of elements - spans inside a div, divs inside a span,
divs inside another div, paragraphs, you name it. The spans are what I
really want to use, for cosmetic reasons.

It always comes back to the same thing: it's the dynamically generated
elements that IE chokes on, no matter what type they are. It's like
those objects are not getting registered somehow, even though they
display okay.

Thanks again,
BC

 

[Nicholas Couch]

Richard -

I didn't post my code because it's pretty clear that IE, not my code, is
the problem. I'm pretty sure that I am indeed using cross-browser DOM1
code, and as I already said, it all works great in at least two other
browsers. What I was hoping to find was a response from someone who has
run up against the same bug in IE and found a workaround, but since you
seem to be so keen on seeing the code, here it is:

function positionChange()
{
var b = document.form1.baseSelect;
var posSel = document.form1.positionSelect;
var base = b.options[b.selectedIndex].text
var p = posSel.options[posSel.selectedIndex].text
var v = posSel.options[posSel.selectedIndex].value;
var newElem = "span";
// here's where we create a new element under the "prefs" element
// first we get a reference to prefs
var pr = new getObj("prefs");
// then we create a new element
var newel = document.createElement(newElem);
// finally, append the new element to the prefs element
pr.obj.appendChild(newel);
// ???
newel.setAttribute("ID", "pref" + v);
newel.setAttribute("style", "display:block;");
// create an anchor element for the new element
var an = document.createElement("a");
// append the anchor to the new element
newel.appendChild(an);
an.setAttribute("href", "javascript:drop_pref(\"pref" + v + "\")");
an.setAttribute("title", "delete");
// create a new IMG element to go with the anchor
var newimg = document.createElement("img");
// append the image to the anchor
an.appendChild(newimg);
newimg.setAttribute("src", "/common/images/delete_small.gif");
newimg.setAttribute("border", "0");
newimg.setAttribute("alt", "delete");
// create a TextNode element for the new element and append it
var txt = document.createTextNode(" " + base + " - " + p);
newel.appendChild(txt);
// create a line break and append that
var br = document.createElement("br");
newel.appendChild(br);
}

function drop_pref(id)
{
var x = new getObj(id);
// alert("display = " + x.style.display);
x.style.display = 'none';
}

function getObj(nm)
{
if (document.getElementById)
{
this.obj = document.getElementById(nm);
this.style = document.getElementById(nm).style;
}
else if (document.layers)
{
this.obj = document.layers(nm);
this.style = document.layers(nm);
// "old" Netscape
}
else if (document.all)
{
this.obj = document.all(nm);
this.style = document.all(nm).style;
// old IE
}
}

I appreciate any insight you can give on this problem.

Thanks,
BC

 

[Richard Cornford]

Richard -

I didn't post my code because it's pretty clear that IE,
not my code, is the problem.

And as you cannot change IE you therefor could not solve your problem by
changing your code.

I'm pretty sure that I am indeed using cross-browser
DOM1 code,

DOM 1 code is not necessarily cross-browser (even cross-DOM 1 supporting
browsers).

and as I already said, it all works great in at least two
other browsers. What I was hoping to find was a response
from someone who has run up against the same bug in IE
and found a workaround,

Without being able to see the code it is not possible to know which
bug/feature of IE you have run up against (all browsers have bugs and
features, usually lot of them).

but since you seem to be so keen on seeing the code, here
it is:

newel.setAttribute("ID", "pref" + v);

^^
Code == quick and painless answer!

When creating elements dynamically, instead of using setAttribute,to set
HTMLElement properties listed in the HTML DOM it is advisable to set the
corresponding object properties directly. In this case the - id -
property of the new span element:-

newel.id = ("pref" + v);

- the resulting code works with all HTML DOM browsers.

If you insist on using setAttribute then it is necessary to use
attribute names in the form that IE understands them, thus exactly the
same mixed case strings as are found as named properties of IE's
attributes collection. In this case IE will act on the setting of an
"id" attribute if that attribute name is _all_ lowercase_. (But it is
easier to set the properties directly.)

newel.appendChild(an);
an.setAttribute("href",
"javascript:drop_pref(\"pref" + v + "\")");

<snip>

Javascript pseudo-protocol HREFs are known troublemakers and should
never be used in cross browser code. Instead, at this point you should
assign a harmless - href - property (as it will never be acted upon '#'
would do) and assign a navigation-cancelling onclick handler to the -
onclick - property of the A element. Then you no longer need an ID
attribute anyway as such an onclick handler can eliminate its containing
span from the document with:-

this.parentNode.parentNode.removeChild(this.parentNode);

As could a similar event handler on <BUTTON> or <INPUT type="image">
elements in the same context.

Richard.

 

[Nicholas Couch]

Well, Richard, you're absolutely right - I should have included my code
in my first post. Changing the setAttribute calls to setting properties
directly solved the problem. On the other hand, if IE didn't treat
setAttribute in a non-standard way, I wouldn't have had this problem in
the first place. I read in Danny Goodman's book that appendChild,
setAttribute and the like are DOM1 _and_ supported by IE as of version
5. If I had read closer, I would have seen his discussion of the way IE
handles setAttribute. It supports those calls alright, but in its own
peculiar way.

One thing still puzzles me. When I try to set the display style of my
new span with

newel.style = "display:block;";

IE throws a "member not found" error. At first I simply commented this
line, and all was well. Then I changed it to read

newel.style.display = "block";

and that worked too, so I kept it. Now presumably the problem I was
having before had to do with IE not finding the span object in its
collection, or perhaps more precisely, not finding the style attribute
of the span object. So does IE create the necessary style attribute if I
fail to specify it myself, but not create it if I specify it in a way
that doesn't conform to its interpretation of setAttribute? More
importantly, does anybody care?

Thanks,
BC

 

[Richard Cornford]

Well, Richard, you're absolutely right - I should
have included my code in my first post.

Yes you should, you would have had fixed code at least 4 hours sooner.
As should all the other individuals posting questions to this group who
don't know enough to appreciate that there are 50-odd ways of screwing
most things up and that it is impossible to tell which actually applies
without seeing the code and its context. (While we can all guess, and
even guess correctly sometimes, it is frustrating to be being
continually asked to guess when code is all that is needed for
certantly.)

... . I read in Danny Goodman's book ...

<snip>

Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.

One thing still puzzles me. When I try to set the display
style of my new span with

newel.style = "display:block;";

The reason that I specifically stated that the properties that should be
defined directly on the element instead of using setAttribute are the
HTML attribute-corresponding properties defined in the _HTML_ DOM
specification was that other attributes are handled differently. The -
style - property of a DOM element (that implements the
ElementCSSInlineStyle interface) refers to an object implementing the
CSSStyleDeclaration interface from the W3C CSS DOM specification. Where
it is defined as a read-only property (the - style - property of the
element, not the CSSStyleDeclaration interface's properties).

The ElementCSSInlineStyle interface is formalisation of behaviour
originating in IE 4 and well supported in modern browsers. When an
element is created it already has a - style - property that refers to an
object, so it is best to set the properties of that object to the
desired values (or to set the - className - property of the element
itself, to have it acquire as set of style properties defined in CSS
elsewhere).

IE throws a "member not found" error. At first I simply commented
this line, and all was well. Then I changed it to read

newel.style.display = "block";

and that worked too, so I kept it.

Yes that works, but it is a bit illogical to create a SPAN element (the
semantically neutral inline element intended for little more than the
application of CSS) and then give it a "block" display property, when
you could create a DIV element (the semantically neutral block element)
and just let its display property default to "block" as normal.

Now presumably the problem I was having before
had to do with IE not finding the span object in its
collection, or perhaps more precisely, not finding

the style attribute of the span object. So does
IE create the necessary style attribute if I fail
to specify it myself,

Any created element (at least on modern browsers) will have a - style -
property from the moment of its creation, that represents the current
state of its inline style, as an object with named properties.

but not create it if I specify it in a way that doesn't
conform to its interpretation of setAttribute? More
importantly, does anybody care?

It is normal to set the properties related to inline style on the object
provided not through the use of setAttribute('style' ,' ... ');

Richard.

 

[Nicholas Couch]

<snip>

Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.

<snip>

Virtually any book in the computing field is likely to be out of date
shortly after publication. I have the second edition of "Dynamic HTML,
the Definitive Reference," published in 2002. I gather you would not
consider it definitive, but is it really that out of date only two years
later? What would be a better resource for a confessed javascript noob?

BC

 

[Michael Winter]

[snip]

Virtually any book in the computing field is likely to be out of date
shortly after publication. I have the second edition of "Dynamic HTML,
the Definitive Reference," published in 2002. I gather you would not
consider it definitive, but is it really that out of date only two years
later? What would be a better resource for a confessed javascript noob?

It's not that Javascript books are out-of-date, but that they're simply
bad in the first place. As Richard tends to point out in discussions such
as this, the majority of book and Web authors don't understand the
complexities of scripting[1], and the Web is worse-off for it. As such,
there tends to be few resources that can be recommended, aside from a few
choice articles on topics like the evils of browser detection.

Personally, I can do little more than recommend reading the FAQ and it
links, and continuing to read and ask questions in this group. It's not
quite the self-enabling answer you were probably looking for, but I don't
think there's much that can be about that with the current state of things.

Mike

<URL:http://jibbering.com/faq/>


[1] I'd like to point out that I don't claim to, either. It's why I
participate in this, and other, authoring groups. It's amazing to realise
just how clueless one can be.

 

[Grant Wagner]

As Richard tends to point out in discussions such
as this, the majority of book and Web authors don't understand the
complexities of scripting[1], and the Web is worse-off for it.

[1] I'd like to point out that I don't claim to, either. It's why I
participate in this, and other, authoring groups. It's amazing to realise
just how clueless one can be.

The complexities of scripting are also the reason I hear "JavaScript sucks" so
much. And I don't just hear it from developers, I also hear it from end-users
who fail to understand it is not the technology that "sucks", but the
particular style of scripting on the sites they are visiting. This badly
written script is caused by the exact thing you mentioned, Web authors not
understanding the complexities of the environment they are developing for.

When they are approached and informed that something they have authored is not
working on some combination of OS, browser, firewall and/or popup-blocking
software, their first reaction is... you guessed it... "JavaScript sucks".
Well, their first reaction might be "Windows sucks" or "IE sucks", or "Mac
sucks" or "Mozilla sucks", but ultimately it comes down to blaming something
other than their inability to understand that they do not control the
environment in which their code is running, and as a result, extra care must be
taken to ensure that when (not if) the code fails, it does so in a way that
will not leave the visitor's browser crippled.

As you said, I am still learning as well. I am lucky enough to do most of my
work for an Intranet where I support only(!) Netscape 4.78, IE 5.5+, recent
Gecko-based browsers and Opera 7. And I have the option of insisting that the
user upgrade to a more recent Gecko variation or Opera 7 if they are running an
older version which does not support some functionality which does not work
properly.

And even with this "controlled" environment, Windows XP Service Pack 2 revealed
some weakly written client-side JavaScript which caused problems and had to be
fixed.

When people tell me writing client-side JavaScript isn't "real" programming, I
just smile and resort to "if you say so". Then wait for them to have their
first experience with "why doesn't formName.submit(); work in Mozilla!".

 

[Richard Cornford]

But very essential in any effort to become non-clueless.

When people tell me writing client-side JavaScript isn't
"real" programming, I just smile and resort to "if you say
so". ...

<snip>

Earlier today I noticed a job advert:-

<URL: http://www.cwjobs.co.uk/JS/JobDetails.asp?JobID=12451782 >
(That is unlikely to be a stable URL)

Containing the line: "You will need a solid experience of Web
Development generating HTML, Javascript, CSS and Graphics, ideally with
some programming.". Obviously written by someone who actually believes
they can hire someone to write javascript who doesn't necessarily know
anything about programming. I can imagine the outcome :-(

Richard.

 

[Nicholas Couch]

I'd like to explore this a little further, and get a little more
specific. The Goodman book to which I referred earlier is primarily a
reference, covering DHTML, CSS, DOM, etc. It is not a tutorial per se.
Would I be wrong to trust it as a reference? Is the information
presented therein likely to be inaccurate, or as Richard suggested,
out of date? Can anyone give me an example of an instance where the
book is wrong?

I'm quite serious about this. As I've already noted, I've not done a
whole lot of Javascript programming previously (I've been programming
in other languages for well over 20 years), but it looks like I may
well be doing a lot of it in the foreseeable future. I don't want to
get off on the wrong foot by relying on a lousy reference book.

BC

 

[Nicholas Couch]

[snip]

Or maybe it is this book: Dynamic HTML: The Definitive Reference, 2nd
Edition A Comprehensive Resource for HTML, CSS, DOM & JavaScript. This
contains a lot of reference information. I thought about buying it, but
if I recall right, it has a very broad coverage and contains a little
less coverage on the core javascript language than the book below.

[snip]

Yes, that's the one I refer to in message 12 in this thread. I bought
it precisely because I wanted a resource with broad coverage, and
because I read several strong recommendations for it, on this
newsgroup and elsewhere. Plus I already have a couple of books devoted
primarily to javascript, including the O'Reilly/Flanagan book.

The important thing, from my point of view, is to know whether or not
I can rely
on these or any other books as I try to increase my level of expertise
in javascript programming. When regular and authoritative participants
in this newsgroup tell me, essentially, that so-and-so's books are no
good and that no Javascript books can be trusted, I'd like to know
with specificity why that is so. It seems to me that when there's so
much importance placed on conforming to a certain posting orthodoxy in
this group, there ought to be just as much emphasis placed on
substantiating one's opinion of the work of others in the field - in
the interest of the common good, of course....

BC

 

[Richard Cornford]

Yes, that's the one I refer to in message 12 in this thread.
I bought it precisely because I wanted a resource with
broad coverage, and because I read several strong
recommendations for it, on this newsgroup and elsewhere.

I have never seen a recommendation of any Danny Goodman book posted to
this newsgroup in the last couple of years, strong or otherwise. At
least by anyone worth paying any attention to, which is important as the
only limitation on posting a recommendation of anything is having access
to a new server or the internet (so not really a qualification in
javascript in itself).

Plus I already have a couple of books devoted
primarily to javascript, including the O'Reilly/Flanagan book.

The important thing, from my point of view, is to know
whether or not I can rely on these or any other books
as I try to increase my level of expertise in javascript
programming.

Reference material published in books only needs to reproduce (often
re-worded) the original sources (ECMA, W3C, Microsoft, Netscape, ect.)
accurately in order to be useful. They can tell you what is out there,
and what you can expect it to do where it is implemented. As will the
original sources.

Any book written in 2002 is going to have problems saying useful things
about browser implementations. At the start of 2002 Netscape 7 and Opera
7 did not exist, Mozilla has changed considerably over the intervening
years (along with all the Gecko browsers) and books rarely even mention
browsers such as IceBrowser (called IceStorm at the time) and NetFront.
Unsurprisingly as most books take the "both browsers" attitude prevalent
around the turn of the century, possibly making concessions for extreme
changes made between Netscape 4 and 6.

That is in fact the main problem with Danny Goodman's code. He tends to
take the attitude that the browser executing his code will be one of a
known set of browsers and never considers the consequences of a script
encountering a browser outside of that set (that and applying some
really clumsy techniques to dealing with even that limited set of
browsers).

In reality reference material for the object models is not a major issue
in browser scripting, though it would be nice if some of the minor
browsers published more specifics about their implementations). The real
problem is in script design; designing for the consequences of failure
of a browser to support a particular feature. It is that aspect of
scripting that takes the effort to learn, and also the aspect most
poorly addressed in existing javascript books.

When regular and authoritative participants in this newsgroup
tell me, essentially, that so-and-so's books are no good and
that no Javascript books can be trusted, I'd like to know
with specificity why that is so. It seems to me that when
there's so much importance placed on conforming to a certain
posting orthodoxy in this group, there ought to be just as
much emphasis placed on substantiating one's opinion of the
work of others in the field - in the interest of the common
good, of course....

The section of the FAQ on javascript books says just about all that
needs saying on the subject. None of the regulars on this group are
willing to endorse any book other than David Flanagan's and even that
was following a debate on the subject and the expression of misgivings.

Of the last two newly published javascript books I have looked at, one
was written apparently without an appreciation that javascript is quite
unlike Java, and so was filled with clear factual errors (that would
mostly have been true of Java), and the second (featuring "advanced" in
the title) expounded methods so poor that their use would be somewhere
between stupid and disastrous.

Richard.

 

[Nicholas Couch]

I have never seen a recommendation of any Danny Goodman book posted to
this newsgroup in the last couple of years, strong or otherwise. At
least by anyone worth paying any attention to, which is important as

Well, that's part of the problem, isn't it? How is one to judge, unless
one regularly spends time reading the group? I spent a few hours the other
day, before I made my original post, searching via Google Groups, looking
for posts that might give me a clue as to a solution to the problem I was
experiencing. I saw many posts by yourself, Andrew Thompson, Michael
Winter, Martin Honnen, Randy Webb, Fred Oz, Lasse Reichstein Nielsen,
Thomas 'PointedEars' Lahn, Grant Wagner, and a host of others. During that
brief period I became aware that there are certain regular participants in
the group who are considered purveyors of bad advice, but I wasn't looking
for any depth of understanding of your particular subculture on the
internet. I was looking for a solution to a very specific programming
problem. In the process I ran across at least two or three recommendations
for Goodman's DHTML book, which I considered valuable in the absence of
any recommendations to the contrary. I don't recall how old those posts
were, and they may not even have been from this group, now that I think
about it, but anything is better than nothing, usually.

The section of the FAQ on javascript books says just about all that
needs saying on the subject. None of the regulars on this group are
willing to endorse any book other than David Flanagan's and even that
was following a debate on the subject and the expression of misgivings.

I have to disagree, with that "just about all that needs saying" bit. It
may be enough for the regular participants here, because you know each
other's judgement, presumably, but as an outsider there are lots of
alternative conclusions I could draw from the fact that there's only one
book in existence you can all agree on, even grudgingly, as valuable.
Nothing personal, Richard, but there are a lot of cranks on usenet.

At any rate, I appreciate your taking the time to respond here in more
detail, and I appreciate the efforts of everyone else who posted on this
thread. I certainly know a whole lot more than I did before I started
this, and that's what it's all about.

BC

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Sun, 19 Sep 2004 10:01:49, seen in

Yes, that's the one I refer to in message 12 in this thread.

The articles in a thread are not globally numbered.

They may arrive in different servers in different orders; they are
differently displayed by different newsreaders; readers need show no
number. So it is not sound to refer to them by a sequence number.

The Message-ID, in the header, provides a reference which should be
perpetually unique over all newsgroups; "My message, Date: 17 Sep 2004
20:41:13 GMT", is good enough for the present purpose.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Tue,
21 Sep 2004 08:30:35, seen in Andrew Thompson

On Mon, 20 Sep 2004 11:45:43 +0100, Dr John Stockton wrote:

(Usenet posts)

As an aside, I often provide links to the Google archives
that take the form http://google.com/groups?th=2123446#9
(a totally false URL), in preferecne to using the single,
much longer 'selm; parameter.

But those with off-line news readers do not have immediate access to web
services; but, if it is a good newsreader, it will have retained earlier
articles in the thread, and one can find them given date & time or
Message-ID.

 

[Michael Winter]

[snip]

Excuse me for being dense (shrugs, or not, as you wish)
but is the 'Message-ID' equivalent to the 'selm' parameter
as used by Google. (I suspect that is what it is, but am
unsure)

Yes, it is.

My last post in this thread (to Nicholas Couch, Friday 21:37 GMT) as the
following Google URL:

<URL:http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=opsehqdvfxx13kvk@atlantis>

If you check the headers of that post, you'll see:

Message-ID: <opsehqdvfxx13kvk@atlantis>

URL-encoded, it's the same as the selm parameter (though it is missing the
angle brackets).

Mike