Clear all optgroups and options from a select list

[Brian D]

I have a multiple select list that is created dynamically based on a
previous selection on an asp page. The first thing I do is to clear
the curent option list by

document.form1. itemcross.lengt h = 0;

The only problem is that it leaves the optgroups. How do I also get
rid of the optgroups?

Thanks
BrianD

[darwinist]

Re: Clear all optgroups and options from a select list

Brian D wrote:

I have a multiple select list that is created dynamically based on a
previous selection on an asp page. The first thing I do is to clear
the curent option list by
>
document.form1. itemcross.lengt h = 0;
>
The only problem is that it leaves the optgroups. How do I also get
rid of the optgroups?
>
Thanks
BrianD

You need an id for the object or a reference to it:

<script>
// delete an object by reference
function del(element){el ement.parentNod e.removeChild(e lement);}
// Get a reference to an object by id:
function $(id){return document.getEle mentById(id);}
// Delete an object by id:
function $del(id){x=$(id ); del(x);}
</script>

hope this helps

---

http://darwinist.googlepages.com/htmldesktop.html

(lots of working examples)

[RobG]

Re: Clear all optgroups and options from a select list


Brian D wrote:

I have a multiple select list that is created dynamically based on a
previous selection on an asp page. The first thing I do is to clear
the curent option list by
>
document.form1. itemcross.lengt h = 0;
>
The only problem is that it leaves the optgroups. How do I also get
rid of the optgroups?

The usual way:

var sel = document.form1. itemcross;
while (sel.firstChild ) {
sel.removeChild (sel.firstChild );
}


--
Rob

[RobG]

Re: Clear all optgroups and options from a select list


darwinist wrote:

Brian D wrote:

I have a multiple select list that is created dynamically based on a
previous selection on an asp page. The first thing I do is to clear
the curent option list by

document.form1. itemcross.lengt h = 0;

The only problem is that it leaves the optgroups. How do I also get
rid of the optgroups?

Thanks
BrianD

>
You need an id for the object or a reference to it:

The OP has already indicated how he's doing that, and may be using
either an ID or a NAME attribute.

<script>

Please don't recommend using invalid HTML. Do it in your own library
if you wish, but don't encourage it here.

// delete an object by reference
function del(element){el ement.parentNod e.removeChild(e lement);}

The OP is attempting to remove the child nodes, not the element itself.


--
Rob

[darwinist]

Re: Clear all optgroups and options from a select list


RobG wrote:

darwinist wrote:
>

Brian D wrote:

I have a multiple select list that is created dynamically based on a
previous selection on an asp page. The first thing I do is to clear
the curent option list by
>
document.form1. itemcross.lengt h = 0;
>
The only problem is that it leaves the optgroups. How do I also get
rid of the optgroups?
>
Thanks
BrianD

You need an id for the object or a reference to it:

>
The OP has already indicated how he's doing that, and may be using
either an ID or a NAME attribute.
>
>

<script>

>
Please don't recommend using invalid HTML. Do it in your own library
if you wish, but don't encourage it here.
>
>

// delete an object by reference
function del(element){el ement.parentNod e.removeChild(e lement);}

>
The OP is attempting to remove the child nodes, not the element itself.

Isn't an optgroup an element that you can remove like any other?

http://www.w3schools.com/tags/tag_optgroup.asp

>
--
Rob

[RobG]

Re: Clear all optgroups and options from a select list

darwinist wrote:

RobG wrote:

>darwinist wrote:
>>

>>Brian D wrote:
>>>I have a multiple select list that is created dynamically based on a
>>>previous selection on an asp page. The first thing I do is to clear
>>>the curent option list by
>>>>
>>>document.for m1.itemcross.le ngth = 0;
>>>>
>>>The only problem is that it leaves the optgroups. How do I also get
>>>rid of the optgroups?

[...]

>>You need an id for the object or a reference to it:

>The OP has already indicated how he's doing that, and may be using
>either an ID or a NAME attribute.

[...]

>> // delete an object by reference
>> function del(element){el ement.parentNod e.removeChild(e lement);}

>The OP is attempting to remove the child nodes, not the element itself.

>
Isn't an optgroup an element that you can remove like any other?

Yes. Your response was essentially to give every option an ID, then
remove them one by one using getElementById. That is not a reasonable
method given the question.


--
Rob

[darwinist]

Re: Clear all optgroups and options from a select list

RobG wrote:

darwinist wrote:

RobG wrote:

darwinist wrote:
>
>Brian D wrote:
>>I have a multiple select list that is created dynamically based on a
>>previous selection on an asp page. The first thing I do is to clear
>>the curent option list by
>>>
>>document.form 1.itemcross.len gth = 0;
>>>
>>The only problem is that it leaves the optgroups. How do I also get
>>rid of the optgroups?

>
[...]
>

>You need an id for the object or a reference to it:
The OP has already indicated how he's doing that, and may be using
either an ID or a NAME attribute.

>
[...]
>

> // delete an object by reference
> function del(element){el ement.parentNod e.removeChild(e lement);}
The OP is attempting to remove the child nodes, not the element itself.

Isn't an optgroup an element that you can remove like any other?

>
Yes. Your response was essentially to give every option an ID, then
remove them one by one using getElementById. That is not a reasonable
method given the question.

I said "or a reference to it", and gave commented, working examples of
how to deal with both. What's your problem?

Javascript's native methods use a lot of codespace for common things
that don't take much time. This rigid structure is important to the
integrity of the platform but when you are putting it to any actual
purpose you need short, clear, purpose-specific functions that reflect
what your application, not the language, is doing.

For example:

http://darwinist.googlepages.com/htmldesktop.html

Feel free to criticise or contribute.

>
--
Rob

[RobG]

Re: Clear all optgroups and options from a select list

darwinist wrote:

RobG wrote:

darwinist wrote:

RobG wrote:
>darwinist wrote:
>>
>>Brian D wrote:
>>>I have a multiple select list that is created dynamically based on a
>>>previous selection on an asp page. The first thing I do is to clear
>>>the curent option list by
>>>>
>>>document.for m1.itemcross.le ngth = 0;
>>>>
>>>The only problem is that it leaves the optgroups. How do I also get
>>>rid of the optgroups?

[...]

>>You need an id for the object or a reference to it:
>The OP has already indicated how he's doing that, and may be using
>either an ID or a NAME attribute.

[...]

>> // delete an object by reference
>> function del(element){el ement.parentNod e.removeChild(e lement);}
>The OP is attempting to remove the child nodes, not the element itself.
>
Isn't an optgroup an element that you can remove like any other?

Yes. Your response was essentially to give every option an ID, then
remove them one by one using getElementById. That is not a reasonable
method given the question.

>
I said "or a reference to it", and gave commented, working examples of
how to deal with both. What's your problem?

The OP already had a reference to the select element and just wanted to
remove all the child nodes. To use your proposed solution, the OP
would have looped through all the child nodes, then called the 'del'
function which used the child node to reference back to the parent node
to delete itself.

That may have lead to a few characters less in the for loop, but also
an extra unnecessary function object plus an extra couple of loop-ups
for parent and child nodes. So appart from obfuscation, you also make
the whole process less efficient.

The function I posted was perhaps 3 lines of code and could (had the OP
wanted) be wrapped in a separate 'deleteAllChild Nodes' function. I
think it actually required fewer keystrokes, not that it matters.

Incidentally, the fastest way I've seen to delete all the child nodes
of an element is to replace it with a shallow clone of itself.
Unfortunately, a few scarce browsers don't like doing that with all
elements so it's not useful on the web. But for an intranet... ;-)

Javascript's native methods use a lot of codespace for common things
that don't take much time. This rigid structure is important to the
integrity of the platform but when you are putting it to any actual
purpose you need short, clear, purpose-specific functions that reflect
what your application, not the language, is doing.

I don't see how adding an ID to every element you want to delete makes
life easier. It also suggests managing all those IDs and some
algorithm to work out which ones are of interest.

Creating single-line functions purely for the sake of reducing the
number of keystrokes for a programmer to type a method will not lead to
any great advantage in reducing software development times (that
discussion is being hosted in another thread I think). If it did, such
widely used environments as VB wouldn't have names that approach the
length of short sentences (please don't assume I think VB is some
paragon of programming excellence - it's just an example) and brevity
would be a fundamental principle of coding standards everywhere. It
isn't - clarity is.

If you've ever tried to maintain some one else's code (say C or C++)
you'd know why.


--
Rob

[Richard Cornford]

Re: Clear all optgroups and options from a select list

darwinist wrote:

RobG wrote:

>darwinist wrote:

>>>darwinist wrote:

<snip>

>>>>You need an id for the object or a reference to it:

<snip>

>>Isn't an optgroup an element that you can remove like
>>any other?

>>
>Yes. Your response was essentially to give every option
>an ID, then remove them one by one using getElementById.
>That is not a reasonable method given the question.

>
I said "or a reference to it", and gave commented, working
examples of how to deal with both. What's your problem?

The example you gave was an example that required each optgroup element
to have and ID, that would be the wrong thing to do.

<snip>

For example:

http://darwinist.googlepages.com/htmldesktop.html

>
Feel free to criticise

You have never actually said what this thing is supposed to be for. It
looks like it is indented to be the bases for an in-browser windowing
system for web-applications. It doesn't look capable enough for any
actual example of such, but I suppose could be extended for specific
applications. However, as it is only really suited for Mozilla/Gecko
browsers as it stands I don't see it being of much practical benefit in
a world where IE support is normally expected (and sometimes
sufficient).

or contribute.

You don't appear to be someone who takes advice, so anything approaching
collaboration is out of the question.

Richard.

[darwinist]

Re: Clear all optgroups and options from a select list

RobG wrote:

darwinist wrote:

RobG wrote:

darwinist wrote:
RobG wrote:
darwinist wrote:
>
>Brian D wrote:
>>I have a multiple select list that is created dynamically based on a
>>previous selection on an asp page. The first thing I do is to clear
>>the curent option list by
>>>
>>document.form 1.itemcross.len gth = 0;
>>>
>>The only problem is that it leaves the optgroups. How do I also get
>>rid of the optgroups?
>
[...]
>
>You need an id for the object or a reference to it:
The OP has already indicated how he's doing that, and may be using
either an ID or a NAME attribute.
>
[...]
>
> // delete an object by reference
> function del(element){el ement.parentNod e.removeChild(e lement);}
The OP is attempting to remove the child nodes, not the element itself.

Isn't an optgroup an element that you can remove like any other?
>
Yes. Your response was essentially to give every option an ID, then
remove them one by one using getElementById. That is not a reasonable
method given the question.

I said "or a reference to it", and gave commented, working examples of
how to deal with both. What's your problem?

>
The OP already had a reference to the select element and just wanted to
remove all the child nodes. To use your proposed solution, the OP
would have looped through all the child nodes, then called the 'del'
function which used the child node to reference back to the parent node
to delete itself.
>
That may have lead to a few characters less in the for loop, but also
an extra unnecessary function object plus an extra couple of loop-ups
for parent and child nodes. So appart from obfuscation, you also make
the whole process less efficient.
>
The function I posted was perhaps 3 lines of code and could (had the OP
wanted) be wrapped in a separate 'deleteAllChild Nodes' function. I
think it actually required fewer keystrokes, not that it matters.

You're right to empty an object it's more efficient to have a function
that does just that, instead of a generic delete one and another loop
for every object you want to empty.

Incidentally, the fastest way I've seen to delete all the child nodes
of an element is to replace it with a shallow clone of itself.
Unfortunately, a few scarce browsers don't like doing that with all
elements so it's not useful on the web. But for an intranet... ;-)
>
>

Javascript's native methods use a lot of codespace for common things
that don't take much time. This rigid structure is important to the
integrity of the platform but when you are putting it to any actual
purpose you need short, clear, purpose-specific functions that reflect
what your application, not the language, is doing.

>
I don't see how adding an ID to every element you want to delete makes
life easier. It also suggests managing all those IDs and some
algorithm to work out which ones are of interest.

That was an argument for short single-word functions that have meaning
in the contenxt of a partiuclar application. The overuse of the ID tag
is just my ignorance of javascript and not related in any way.

Creating single-line functions purely for the sake of reducing the
number of keystrokes for a programmer to type a method will not lead to
any great advantage in reducing software development times (that
discussion is being hosted in another thread I think). If it did, such
widely used environments as VB wouldn't have names that approach the
length of short sentences (please don't assume I think VB is some
paragon of programming excellence - it's just an example) and brevity
would be a fundamental principle of coding standards everywhere. It
isn't - clarity is.

Brevity is not neutral with regards to clarity. Mashing a lot of words
together with hungarian notation isn't necessarily more clear than
single word sentences, but it is more precise for a framework or
toolkit. Using lots of convoluted code structures and peforming too
many operations in a single statement is also not clear, although it
may be brief.

Complete words, individual words, are what we read best, and how we
think.

If you've ever tried to maintain some one else's code (say C or C++)
you'd know why.

Funny you should mention it I've been doing precisely that for the last
few months.

>
--
Rob

[darwinist]

Re: Clear all optgroups and options from a select list

Richard Cornford wrote:

darwinist wrote:

RobG wrote:

darwinist wrote:
>>darwinist wrote:

<snip>

>>>You need an id for the object or a reference to it:

<snip>

>Isn't an optgroup an element that you can remove like
>any other?
>
Yes. Your response was essentially to give every option
an ID, then remove them one by one using getElementById.
That is not a reasonable method given the question.

I said "or a reference to it", and gave commented, working
examples of how to deal with both. What's your problem?

>
The example you gave was an example that required each optgroup element
to have and ID, that would be the wrong thing to do.

It did not require an ID, it required either an id or a reference,
(which was the first thing i said to the OP). The first actual example
I gave was:

// delete an object by reference
function del(element){el ement.parentNod e.removeChild(e lement);}


In case no id was present or necessary.

<snip>

For example:

http://darwinist.googlepages.com/htmldesktop.html

Feel free to criticise

>
You have never actually said what this thing is supposed to be for.

It's to demonstrate all you need to know to start making your own
web-based desktop system, or any subset thereof (a windowed-based
application, for example). It's far from perfect but it includes all
basic functionality required, plus an "immediate" box, and a manual.

It
looks like it is indented to be the bases for an in-browser windowing
system for web-applications. It doesn't look capable enough for any
actual example of such,

Under Help->Examples there are several working examples for making
windows, making objects draggable, a hello world program, etc.

Also the windowing system itself works, as does the desktop.

but I suppose could be extended for specific
applications. However, as it is only really suited for Mozilla/Gecko
browsers as it stands

There isn't any browser-specific code, and although it's not coded to
an apparently well-known ie bug, it's fairly lightweight and quite
responsive in either major browser.

I don't see it being of much practical benefit in
a world where IE support is normally expected (and sometimes
sufficient).

It's meant as a free codebase. I've seen nothing really that does all
desktop-environment stuff in a short, free, clear fashion. Most is
heavy or proprietary, or both, and most try to reinvent the wheel.

or contribute.

>
You don't appear to be someone who takes advice, so anything approaching
collaboration is out of the question.

I appreciate your advice, even if you don't like what I do with it. I
happen to consider that what "works" is very important. Javsacript
specs are what browsers should implement, but actual browser support is
what programmers need to worry about.

It seems that moving windows around by reference rather than ID would
be a speed improvement and probably slightly less code, so you can
rest-assured my application will reflect this when I next have a play
with it.

I don't respond to authority though. Never have, never will (unless
you're paying me).

Richard.

[RobG]

Re: Clear all optgroups and options from a select list

darwinist wrote:

RobG wrote:

[...]

Creating single-line functions purely for the sake of reducing the
number of keystrokes for a programmer to type a method will not lead to
any great advantage in reducing software development times (that
discussion is being hosted in another thread I think). If it did, such
widely used environments as VB wouldn't have names that approach the
length of short sentences (please don't assume I think VB is some
paragon of programming excellence - it's just an example) and brevity
would be a fundamental principle of coding standards everywhere. It
isn't - clarity is.

>
Brevity is not neutral with regards to clarity.

I did not say that brevity and clarity are mutually exclusive, but that
brevity does not infer clarity - e.g. jargon is great shorthand for
those 'in the know', but is greatly disliked for its ability to
confound.

Mashing a lot of words
together with hungarian notation isn't necessarily more clear than
single word sentences,

Yes, verbosity is just as bad - but I'm not promoting that either.

You may note that single word sentences only ever make sense in the
context of surrounding text. A programmer seeing your $make() function
would first need to look at the source to see what it does, only to
find that it is a simple wrapper for document.create Element.

If in fact $make() was say 100 lines of code, you then either need to
provide precise documentation to say what it does and doesn't do or
assume the programmer will know exactly that from reading the code.

The rub is that if the programmer can infer precisely what the code
does just by reading it, they likely have their own library or can
write a project-specific one that better suits their requirements. If
the programmer isn't that knowledgeable, they will likely misuse the
library (e.g. a recent post which asked 'why do I get this error on
line 1502 of prototype.js').

but it is more precise for a framework or
toolkit. Using lots of convoluted code structures and peforming too
many operations in a single statement is also not clear, although it
may be brief.

That is not an argument either way - obfuscated code is obfuscated
code, brevity (a weapon employed by obfuscation tools) is just as
obfuscatory as verbosity and 'tight' code.

Which is clearer:

dom_deleteEleme nt();

or

$del();


I think most JavaScript programmers could say with reasonable certainty
what the first function does, but would be guessing about the second.
Very few would guess that the second *only* deletes DOM elements.

For the sake of a few extra characters for a programmer to type, the
code becomes much clearer. If code bulk is a serious problem, use a
minifier before sending code to the client.

The bottom line is that code for a project can nearly always be better
optimised for bulk by writing concise, project-specific code than
including 2,000 line libraries to save a few characters in function
calls.

Complete words, individual words, are what we read best, and how we
think.

I think you are crossing over into literary comprehension, which is a
field well outside the scope of this news group.

I don't think in sentences of one word, nor can I conceive that single
words (and occasionally abbreviated single words) are always sufficient
to describe the functionality of everything. What does $del() imply?
It means something to you because you have the context of the library
that you wrote it to fit into. As noted above, single work sentences
*only* make sense when taken in context with surrounding text.

Hello.


--
Rob

[darwinist]

Re: Clear all optgroups and options from a select list

RobG wrote:

darwinist wrote:

RobG wrote:

[...]

Creating single-line functions purely for the sake of reducing the
number of keystrokes for a programmer to type a method will not lead to
any great advantage in reducing software development times (that
discussion is being hosted in another thread I think). If it did, such
widely used environments as VB wouldn't have names that approach the
length of short sentences (please don't assume I think VB is some
paragon of programming excellence - it's just an example) and brevity
would be a fundamental principle of coding standards everywhere. It
isn't - clarity is.

Brevity is not neutral with regards to clarity.

>
I did not say that brevity and clarity are mutually exclusive, but that
brevity does not infer clarity - e.g. jargon is great shorthand for
those 'in the know', but is greatly disliked for its ability to
confound.
>
>

Mashing a lot of words
together with hungarian notation isn't necessarily more clear than
single word sentences,

>
Yes, verbosity is just as bad - but I'm not promoting that either.
>
You may note that single word sentences only ever make sense in the
context of surrounding text. A programmer seeing your $make() function
would first need to look at the source to see what it does, only to
find that it is a simple wrapper for document.create Element.
>
If in fact $make() was say 100 lines of code, you then either need to
provide precise documentation to say what it does and doesn't do or
assume the programmer will know exactly that from reading the code.
>
The rub is that if the programmer can infer precisely what the code
does just by reading it, they likely have their own library or can
write a project-specific one that better suits their requirements. If
the programmer isn't that knowledgeable, they will likely misuse the
library (e.g. a recent post which asked 'why do I get this error on
line 1502 of prototype.js').
>
>

but it is more precise for a framework or
toolkit. Using lots of convoluted code structures and peforming too
many operations in a single statement is also not clear, although it
may be brief.

>
That is not an argument either way - obfuscated code is obfuscated
code, brevity (a weapon employed by obfuscation tools) is just as
obfuscatory as verbosity and 'tight' code.
>
Which is clearer:
>
dom_deleteEleme nt();
>
or
>
$del();
>
>
I think most JavaScript programmers could say with reasonable certainty
what the first function does, but would be guessing about the second.
Very few would guess that the second *only* deletes DOM elements.

They don't need to "guess". Function names are one part of their
description, but not the only one. Comments and context, for example
are two others. If they take arguments then they are another.

For the sake of a few extra characters for a programmer to type, the
code becomes much clearer. If code bulk is a serious problem, use a
minifier before sending code to the client.
>
The bottom line is that code for a project can nearly always be better
optimised for bulk by writing concise, project-specific code than
including 2,000 line libraries to save a few characters in function
calls.

I agree, but that doesn't mean you can't write concise project specific
code, that happens to include a library of common actions, with short
and simple names, even if some of them are just wrappers to more
verbose, platform-specific method calls.

My point is that separating the application from the language,
conceptually, is a good thing.

>

Complete words, individual words, are what we read best, and how we
think.

>
I think you are crossing over into literary comprehension, which is a
field well outside the scope of this news group.
>
I don't think in sentences of one word, nor can I conceive that single
words (and occasionally abbreviated single words) are always sufficient
to describe the functionality of everything.

Sorry I meant single word "functions" (or as few words as practicable).
Of course sentences need at least a verb and a noun, almost always.

What does $del() imply?
It means something to you because you have the context of the library
that you wrote it to fit into. As noted above, single work sentences
*only* make sense when taken in context with surrounding text.
>
Hello.
>
>
--
Rob

[Brian D]

Re: Clear all optgroups and options from a select list


RobG wrote:

>
The usual way:
>
var sel = document.form1. itemcross;
while (sel.firstChild ) {
sel.removeChild (sel.firstChild );
}

RobG. Thanks! It was exactly what I needed!
-Brian

[Richard Cornford]

Re: Clear all optgroups and options from a select list

darwinist wrote:

Richard Cornford wrote:

<snip>

>The example you gave was an example that required each
>optgroup element to have and ID, that would be the
>wrong thing to do.

<snip>

So you did, sorry. Weren't we discussing the clarity/readability of
javascript source code recently?

<snip>

>>For example:
>>http://darwinist.googlepages.com/htmldesktop.html
>>>
>>Feel free to criticise

>>
>You have never actually said what this thing is supposed to
>be for.

>
It's to demonstrate all you need to know to start making
your own web-based desktop system, or any subset thereof
(a windowed-based application, for example).

Now there is a frightening notion. I didn't look at your actual code too
much, I just verified that it did have the serious memory leak I was
expecting on IE, did not address the select element issue, and that you
could not drag one window over the contents of another because the mouse
co-ordinates were not available in the containing frame (that is, it
failed on the three primary issues of an in browser 'windowing' system
in IE). I suspect that much else that would be useful in any actual
application would also be missing, such as an ability for code executing
in a 'window' to respond to window dragging, re-sizing, closing and
focusing (moving to the front) actions.

It's far from perfect but it includes all
basic functionality required, plus an "immediate"
box, and a manual.
>

>It looks like it is indented to be the bases for an
>in-browser windowing system for web-applications. It
>doesn't look capable enough for any actual example of
>such,

>
Under Help->Examples there are several working examples
for making windows, making objects draggable, a hello
world program, etc.

There is quite a gap between 'hello world' and a web application
multi-facetted enough to warrant a windowing GUI.

Also the windowing system itself works, as does the
desktop.
>

>but I suppose could be extended for specific
>applications . However, as it is only really suited
>for Mozilla/Gecko browsers as it stands

>
There isn't any browser-specific code, and although it's
not coded to an apparently well-known ie bug,

At least two well known IE bugs, but the number doesn't matter as any
one is sufficient to make the result viable for use on Windows IE only
Intranets, or multi-browser Intranets that include IE (i.e. the actual
market) for as long as your "I'm not particularly interested in coding
to the bugs of a product whose manufacturers don't even pretend it's
good anymore" stands.

it's fairly lightweight and quite
responsive in either major browser.

Maybe as it stands, but an actual application would be expected to have
something going on in those windows, which is what will slow the total
down.

(Incidentally "either major browser" sounds like the 'both browsers'
attitude prevalent at the end of the last century.)

>I don't see it being of much practical benefit in
>a world where IE support is normally expected (and
>sometimes sufficient).

>
It's meant as a free codebase. I've seen nothing really
that does all desktop-environment stuff in a short, free,
clear fashion. Most is heavy or proprietary, or both, and
most try to reinvent the wheel.

There is the dilemma; if you attempt to anticipate and provide all that
an application may need the result will be 'heavy', and much of what is
included will be unnecessary in any real application, but so long as it
is omitted all you have is a demonstration that it is possible to drag
and re-size IFRAMEs in a container of some sort on a particular set of
browsers.

or contribute.

>>
>You don't appear to be someone who takes advice, so
>anything approaching collaboration is out of the question.

>
I appreciate your advice, even if you don't like what I do
with it. I happen to consider that what "works" is very
important.

My long experience of people declaring that something "works" or
"doesn't work" on this group has diminished the significance of the
word. So many things "work", by some criteria or another, that 'works'
is barely the starting point for a choice of implementation strategies.

Much of the time people are declaring things to 'work' only because they
have not tested them vigorously/seriously. Indeed you don't seem to have
tried stressing your code much, as the two megabyte memory leak in IE
per window instance should have become evident once you had opened and
closed 100 windows or so.

Javsacript specs are what browsers should implement, but
actual browser support is what programmers need to worry
about.

The two are far too interrelated for the specifications to be dismissed
in favour of studying implementations (assuming you had access to, and
time to study, all browser implications). As far as the javascript
specification is concerned the implementations that assert that they
comply with ECMA 262 actually have very few deviations from the
specification (and mostly insignificant ones) so knowing how a
javascript engine should be expected to behave is a very good guide to
99%+ of the actual behaviour of implementations , including the ones that
are unavailable for actual testing.

It seems that moving windows around by reference rather
than ID would be a speed improvement and probably slightly
less code,

As in general whenever you can pass, access or store a string value you
can also pass, access or store an object reference the use of string
references just adds a layer of needless complexity and a runtime
overhead.

so you can rest-assured my application will reflect this
when I next have a play with it.

OK, but doesn't that make you suspect "all you need to know to ..."

I don't respond to authority though. Never have, never will

Not even to listen?

(unless you're paying me).

In the event of needing more javascript programmers I would be looking
for someone with more practical experience (though it would not be me
paying anyway, just interviewing).

Richard.