«

I have a 4row x 1col table, I would like to drop all the content of row
three.
Since Mac IE5.2 does not suppport deleteRow method,
I have also try to set the innerHTML=''; but it does not work.

How can I delete the node from DOM in other way?
Thanks.

Cylix wrote:
> I have a 4row x 1col table, I would like to drop all the content of row
> three.
> Since Mac IE5.2 does not suppport deleteRow method,
> I have also try to set the innerHTML=''; but it does not work.
>
> How can I delete the node from DOM in other way?
> Thanks.

Oh, Sorry, I found the way to do so already ...

Suppose "row" is the object going to delete:
row.parentNode.removeChild(row);

Cylix wrote:
> I have a 4row x 1col table, I would like to drop all the content of row
> three.
> Since Mac IE5.2 does not suppport deleteRow method,
> I have also try to set the innerHTML=''; but it does not work.
>
> How can I delete the node from DOM in other way?
> Thanks.

Can't you remove the <TR> from the <TBODY>? E.g. for the third row, if
tbody refers to the TBODY element:

tbody.removeChild(tbody.childNodes[2]);

Ray

Cylix wrote:
> I have a 4row x 1col table, I would like to drop all the content of row
> three.
> Since Mac IE5.2 does not suppport deleteRow method,
> I have also try to set the innerHTML=''; but it does not work.
>
> How can I delete the node from DOM in other way?
> Thanks.

Two-line function library:
<script>
function $(id){return document.getElementById(id);}
function $del(id) {$(id).parentNode.removeChild($(id));}
</script>

Usage:
<script>
$del(ObjectIDString);
</script>

Methods are lame because you have to repeat yourself. They are fine for
toolkits but not applications, which should be created in plain english
or as close as you can get.

hth

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

wrote:
<snip>
> Two-line function library:
> <script>
> function $(id){return document.getElementById(id);}
> function $del(id) {$(id).parentNode.removeChild($(id));}
> </script>
<snip>

As the specification for javascript (ECMA 262) explicitly states that
Identifiers beginning with the - $ - symbol are intended to signify
machine generated Identifiers it is poor javascript design to write code
that uses such identifiers in non-machine generated Identifiers. All
real javascript programmers can be expected to be familiar with that
formal convention and so bring expectations to their reading of code
that uses Identifiers that start with - $ -, which, when disappointed,
will result in wasted time and effort, thus needlessly increasing code
maintenance costs. (Not to mention the impact of using such
self-evidently obscure Identifiers in code).

Though in practice wrapping calls to - removeChild - in two function
calls, and requiring that Elements referenced have ID attributes would
not be a good idea anyway. In most cases the desire to remove an element
from the DOM implies already having a reference to that element so its
parent's - removeChild - method could be more easily called directly,
and the impact of giving elements ID attributes on IE's memory leak
problem would suggest minimising their use in any event.

Richard.

Richard Cornford wrote:
> wrote:
> <snip>
> > Two-line function library:
> > <script>
> > function $(id){return document.getElementById(id);}
> > function $del(id) {$(id).parentNode.removeChild($(id));}
> > </script>
> <snip>
>
> As the specification for javascript (ECMA 262) explicitly states that
> Identifiers beginning with the - $ - symbol are intended to signify
> machine generated Identifiers it is poor javascript design to write code
> that uses such identifiers in non-machine generated Identifiers. All
> real javascript programmers can be expected to be familiar with that
> formal convention and so bring expectations to their reading of code
> that uses Identifiers that start with - $ -, which, when disappointed,
> will result in wasted time and effort, thus needlessly increasing code
> maintenance costs. (Not to mention the impact of using such
> self-evidently obscure Identifiers in code).

I disagree, i find it highly intuitive to group functions which handle
dom-related elements, and it works across browsers.

You can talk in vague theory about obscure code and confused
programmers but I'm not convinced. I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html

> Though in practice wrapping calls to - removeChild - in two function
> calls, and requiring that Elements referenced have ID attributes would
> not be a good idea anyway. In most cases the desire to remove an element
> from the DOM implies already having a reference to that element so its
> parent's - removeChild - method could be more easily called directly,
> and the impact of giving elements ID attributes on IE's memory leak
> problem would suggest minimising their use in any event.

An important consideration, and one of which I was not aware. On the
other hand, it runs like lightning in firefox and microsoft will
readily admit their browser update is long overdue. I'm not
particularly interested in coding to the bugs of a product whose
manufacturers don't even pretend it's good anymore.

$del("id"); is quick and easy and allows you to be more productive.

> Richard.

wrote:
> Richard Cornford wrote:
>> wrote:
>> <snip>
>> > Two-line function library:
>> > <script>
>> > function $(id){return document.getElementById(id);}
>> > function $del(id) {$(id).parentNode.removeChild($(id));}
>> > </script>
>> <snip>
>>
>> As the specification for javascript (ECMA 262) explicitly states that
>> Identifiers beginning with the - $ - symbol are intended to signify
>> machine generated Identifiers it is poor javascript design to write
>> code that uses such identifiers in non-machine generated
>> Identifiers. All real javascript programmers can be expected to be
>> familiar with that formal convention and so bring expectations to
>> their reading of code that uses Identifiers that start with - $ -,
>> which, when disappointed, will result in wasted time and effort,
>> thus needlessly increasing code maintenance costs. (Not to mention
>> the impact of using such self-evidently obscure Identifiers in code).
>
> I disagree,

The existence of the convention in the language's specification is fact.

> i find it highly intuitive to group functions which handle
> dom-related elements, and it works across browsers.

What 'works' is not really an issue. Making up your own conventions is
your choice, but disregarding well known and established conventions
will make your personal conventions act against the wider readability of
your code for programmers who are familiar with the well known and
established conventions.

> You can talk in vague theory about obscure code and
> confused programmers but I'm not convinced.

Working to programming conventions is such a sensible idea that software
houses tend to formalise a set of conventions and insist that all their
programmers work to those. They don't do that because following
conventions represents a 'vague theory', they do it because it reduces
their code maintenance costs by making code quicker to read/understand.
As a result there are sets of well established conventions for most
languages coming from various sources, and conventions that are found in
the pertinent language's specification are likely to be common in use.

> I challenge you to find an obscure
> line in this entire windowing system:
> http://darwinist.googlepages.com/htmldesktop.html

Don't be silly.

>> Though in practice wrapping calls to - removeChild - in
>> two function calls, and requiring that Elements referenced
>> have ID attributes would not be a good idea anyway. In most
>> cases the desire to remove an element from the DOM implies
>> already having a reference to that element so its parent's
>> - removeChild - method could be more easily called directly,
>> and the impact of giving elements ID attributes on IE's
>> memory leak problem would suggest minimising their use in any
>> event.
>
> An important consideration, and one of which I was not aware.
> On the other hand, it runs like lightning in firefox and
> microsoft will readily admit their browser update is long
> overdue.

Overdue as it may be, commercial browser scripting has to accommodate IE
browsers. If you would prefer to work in some personal 'hobby' market
that is up to you but that does not mean that proposing practices that
are not suitable in a commercial environment is a good idea.

> I'm not particularly interested in coding to the bugs of a
> product whose manufacturers don't even pretend it's good
> anymore.
>
> $del("id"); is quick and easy and allows you to be more
> productive.

What it does for you is not relevant. It will potentially get in the way
of the productivity of a third party knowledgeable javascript programmer
attempting to maintain your code as they will have to spend effort
determining that this apparently machine generated Identifier is not
actually machine generated (and then expend effort re-writing your code
to eliminate the faulty Identifiers).

The overall impact of having to stuff a document with an excessive
number of unique element IDs may be less apparent, but it will act to
hinder development in the longer term.

Generally, javascript is easier to write, maintain and understand when
it uses references to objects directly instead of indirectly referring
to them with string values representing names and IDs.

Richard.

Richard Cornford wrote:
> wrote:
> > Richard Cornford wrote:
> >> wrote:
> >> <snip>
> >> > Two-line function library:
> >> > <script>
> >> > function $(id){return document.getElementById(id);}
> >> > function $del(id) {$(id).parentNode.removeChild($(id));}
> >> > </script>
> >> <snip>
> >>
> >> As the specification for javascript (ECMA 262) explicitly states that
> >> Identifiers beginning with the - $ - symbol are intended to signify
> >> machine generated Identifiers it is poor javascript design to write
> >> code that uses such identifiers in non-machine generated
> >> Identifiers. All real javascript programmers can be expected to be
> >> familiar with that formal convention and so bring expectations to
> >> their reading of code that uses Identifiers that start with - $ -,
> >> which, when disappointed, will result in wasted time and effort,
> >> thus needlessly increasing code maintenance costs. (Not to mention
> >> the impact of using such self-evidently obscure Identifiers in code).
> >
> > I disagree,
>
> The existence of the convention in the language's specification is fact.

I disagree that it will add to net confusion or obscurity.

> > i find it highly intuitive to group functions which handle
> > dom-related elements, and it works across browsers.
>
> What 'works' is not really an issue.

Sorry I must have misheard you. Could you say that again?

> Making up your own conventions is
> your choice, but disregarding well known and established conventions
> will make your personal conventions act against the wider readability of
> your code for programmers who are familiar with the well known and
> established conventions.

Not all conventions are of equal value. It depends on how well any
convention is suited to the task that your code is intended to achieve.

> > You can talk in vague theory about obscure code and
> > confused programmers but I'm not convinced.
>
> Working to programming conventions is such a sensible idea that software
> houses tend to formalise a set of conventions and insist that all their
> programmers work to those. They don't do that because following
> conventions represents a 'vague theory', they do it because it reduces
> their code maintenance costs by making code quicker to read/understand.
> As a result there are sets of well established conventions for most
> languages coming from various sources, and conventions that are found in
> the pertinent language's specification are likely to be common in use.

There are lots of conventions and they don't always agree.

> > I challenge you to find an obscure
> > line in this entire windowing system:
> > http://darwinist.googlepages.com/htmldesktop.html
>
> Don't be silly.

Don't be puritanical.

> >> Though in practice wrapping calls to - removeChild - in
> >> two function calls, and requiring that Elements referenced
> >> have ID attributes would not be a good idea anyway. In most
> >> cases the desire to remove an element from the DOM implies
> >> already having a reference to that element so its parent's
> >> - removeChild - method could be more easily called directly,
> >> and the impact of giving elements ID attributes on IE's
> >> memory leak problem would suggest minimising their use in any
> >> event.
> >
> > An important consideration, and one of which I was not aware.
> > On the other hand, it runs like lightning in firefox and
> > microsoft will readily admit their browser update is long
> > overdue.
>
> Overdue as it may be, commercial browser scripting has to accommodate IE
> browsers. If you would prefer to work in some personal 'hobby' market
> that is up to you but that does not mean that proposing practices that
> are not suitable in a commercial environment is a good idea.

You have much more time to test and optimise for speed if you can
express the initial applicaton at some level higher than the base
toolkit. Methods are lame because they don't know anything about your
application.

> > I'm not particularly interested in coding to the bugs of a
> > product whose manufacturers don't even pretend it's good
> > anymore.
> >
> > $del("id"); is quick and easy and allows you to be more
> > productive.
>
> What it does for you is not relevant. It will potentially get in the way
> of the productivity of a third party knowledgeable javascript programmer
> attempting to maintain your code as they will have to spend effort
> determining that this apparently machine generated Identifier is not
> actually machine generated (and then expend effort re-writing your code
> to eliminate the faulty Identifiers).

a) it's a common practice (ask google if you don't believe me)
b) it makes your code shorter and more readable
c) you can combine it with other useful element functions, like
$make(tagname, id); // make an element
$input(type, name, value, [id]) // make an input
$text(text) // make a text node
d) this approach allows you write applications more quickly.
e) you can then optimise for speed in any areas that are script-heavy.
f) most programmers would know it to be a waste of time to rewrite
something that works for style alone
g) In this particular case, nobody would be confused for more than ten
seconds, if at all, after which this function will save them a great
many keystrokes, without a noticable difference in page performance.

> The overall impact of having to stuff a document with an excessive
> number of unique element IDs may be less apparent, but it will act to
> hinder development in the longer term.

So will long and complicated statements, which are inevitable if you
stick as close as possible to the native javascript/dom methods when
writing your applicatoin.

> Generally, javascript is easier to write, maintain and understand when
> it uses references to objects directly instead of indirectly referring
> to them with string values representing names and IDs.

True, but to get the initial reference you often have to use id, and if
you do this many times in a document, on various events for example,
then you're going to get sick of typing document.getElementById() for
such a common task.

Also you could modify $del() to accept either elements(by reference) or
IDs and act accordingly.

---
http://darwinist.googlepages.com/htmldesktop.html
(A free, open-source web-based IDE, windowing system, and desktop
environment, in 31kB of html and javascript.)

> Richard.

darwinist wrote:
> Richard Cornford wrote:
>> wrote:
>>> Richard Cornford wrote:
>>>> wrote:
>>>>> Two-line function library:
>>>>> <script>
>>>>> function $(id){return document.getElementById(id);}
>>>>> function $del(id) {$(id).parentNode.removeChild($(id));}
>>>>> </script>
>>>> <snip>
>>>>
>>>> As the specification for javascript (ECMA 262) explicitly
>>>> states that Identifiers beginning with the - $ - symbol
>>>> are intended to signify machine generated Identifiers it
>>>> is poor javascript design to write code that uses such
>>>> identifiers in non-machine generated Identifiers. ...
<snip>
>>> I disagree,
>>
>> The existence of the convention in the language's
>> specification is fact.
>
> I disagree that it will add to net confusion or obscurity.

Perhaps you should try trimming try quotes you reply to so that the
context of your responses is not ambiguous.

Confusion results form disappointing expectations. It is not
unreasonable for someone to read the convention in the language's
specification and expect others to follow it. When you disregard that
convention for no good reason you are going to cause confusion, and
delays and increased maintenance costs while that confusion is resolved.

>>> i find it highly intuitive to group functions which
>>> handle dom-related elements, and it works across browsers.
>>
>> What 'works' is not really an issue.
>
> Sorry I must have misheard you. Could you say that again?

What 'works' is not really an issue. In allowing the inclusion of the $
symbol in identifiers and then asserting that it should only be used at
the start of a machine generated Identifier the specification had no
choice but allow any Identifier starting with a $ symbol to be legal.
The interpreter cannot know that an Identifier has been machine
generated, and so cannot apply special tokenising/parsing rules for
machine generated Identifiers. Using them where they should not be used
is going to 'work', it is just something that should not be done.

>> Making up your own conventions is
>> your choice, but disregarding well known and established conventions
>> will make your personal conventions act against the wider
>> readability of your code for programmers who are familiar with the
>> well known and established conventions.
>
> Not all conventions are of equal value.

No they are not. Conventions are essentially arbitrary, they can all be
disregarded and leave an end result that still 'works'. And there are
numbers of different conventions applying to the same situations and
producing different results. Which conventions get followed is largely a
matter of authority. In a software house there likely are a set of house
conventions for coding in various languages, probably formalised, and
all programming staff are required to conform to those conventions.
However, the set of conventions chosen are not likely to be some
arbitrary notions plucked from the air and imposed as an exercise in
power. They will b chosen because they act to benefit the software
authoring/maintaining process, by making code standard in formal
structure, easily understood and recognisable for what it is. They will
be conventions that the programmers are (more or less) familiar with and
appreciate the motivation for.

The act of specifically stating the convention if the language's
specification pretty much guarantees that any serious javascript
programmer will be familiar with it. From that starting point an formal
coding standards document that overwrites that convention with another
would be ill-conceived.

> It depends on how well any convention is suited to the
> task that your code is intended to achieve.

Any naming convention could make DOM related method distinct from
others, and may would be less ambiguous themselves, and all others would
avoid facing the reasonable assumption that the convention laid down in
the specification was in use.

>>> You can talk in vague theory about obscure code and
>>> confused programmers but I'm not convinced.
>>
>> Working to programming conventions is such a sensible idea
>> that software houses tend to formalise a set of conventions
>> and insist that all their programmers work to those. They
>> don't do that because following conventions represents a
>> 'vague theory', they do it because it reduces their code
>> maintenance costs by making code quicker to read/understand.
>> As a result there are sets of well established conventions
>> for most languages coming from various sources, and
>> conventions that are found in the pertinent language's
>> specification are likely to be common in use.
>
> There are lots of conventions and they don't always agree.

Of course not. If a formal coding standard say everyone will use one
particular style of block indentation that it immediately precludes all
other styles.

>>> I challenge you to find an obscure
>>> line in this entire windowing system:
>>> http://darwinist.googlepages.com/htmldesktop.html
>>
>> Don't be silly.
>
> Don't be puritanical.

In any substantial body of code there will be at least one line that is
totally obscure when taken out of context.

But we are not interested in absolute obscurity but rather relative
obscurity. Your:-

$del("something");

- is inherently obscure, It just needs comparing with alternatives such
as:-

removeDomElementById("soemthing);

In the first case you almost know nothing without the source code for -
$del -, while in the second case the odds are good that the reader does
not have to even go an see what the functions does because its name has
already told them.

<snip>
>>> I'm not particularly interested in coding to the bugs of a
>>> product whose manufacturers don't even pretend it's good
>>> anymore.
>>>
>>> $del("id"); is quick and easy and allows you to be more
>>> productive.
>>
>> What it does for you is not relevant. It will potentially get
>> in the way of the productivity of a third party knowledgeable
>> javascript programmer attempting to maintain your code as they
>> will have to spend effort determining that this apparently
>> machine generated Identifier is not actually machine generated
>> (and then expend effort re-writing your code to eliminate the
>> faulty Identifiers).
>
> a) it's a common practice (ask google if you don't believe me)

What is common practice? Using initial $ symbols in javascript code, or
using initial $ symbols to indicate DOM related methods?

First, the vast majority of the javascript code in the world was written
(or copy and pasted) by people who did not really know what they were
doing (and most of the stuff that can be copy and pasted was written by
equally under informed individuals). As a result any appeal to what is
'common practice' is likely an appeal to 'bad practice'.

Initial $ symbols are commonly abused in actual javascript code, but
they certainly are not commonly misused for any single specific purpose.
They can be used to reflect the use of the $ symbol in other languages
(usually with a significant conceptual mismatch), they can be being used
to indicate values of string type, they can be used to indicate values
that should be regarded as internal or private. Indeed you are the first
person I have read proposing that they be used to indicate DOM related
functions. It is in fact this diversity of $ abuses that suggests that
any use outside of the conventions provided in the specification is
unwise, as no other expectation would be common.

> b) it makes your code shorter and more readable

Shorter maybe, but shortness at the cost of readability is not a good
trade-off (as shortness can be machine imposed post development). While
readability is precisely what it does not proved. There is no reason for
a reader to see a $ symbol as having anything to do with DOM related
functions, and very good reasons for them to see the $ symbol as having
something to do with machine generation.

> c) you can combine it with other useful element functions, like
> $make(tagname, id); // make an element
> $input(type, name, value, [id]) // make an input
> $text(text) // make a text node

Wrapping common code structures into parameterised functions is not an
idea that requires, or justifies, a specific naming convention.
dom_make, dom_input and dom_text being just as possible, and
fractionally less obscure.

> d) this approach allows you write applications more quickly.

It is well known that the maintenance costs are always a significant
factor in applications.

> e) you can then optimise for speed in any areas that
> are script-heavy.

There is no relationship between an ability to optimise for speed and
the use of any particular naming convention.

> f) most programmers would know it to be a waste of time to
> rewrite something that works for style alone

Most programmers would know enough not to write something obscurely in
the first place.

> g) In this particular case, nobody would be confused for
> more than ten seconds, if at all, after which this function
> will save them a great many keystrokes, without a noticable
> difference in page performance.

If you were not even aware of the IE memory leak problem I don't think
you have ever written anything with javascript that qualifies you to
make such statements about performance.

Of all the things that may be 'saved' in software authoring I don't
think anyone would seriously propose that keystrokes are something that
needs worrying about.


>> The overall impact of having to stuff a document with an
>> excessive number of unique element IDs may be less apparent,
>> but it will act to hinder development in the longer term.
>
> So will long and complicated statements, which are inevitable
> if you stick as close as possible to the native javascript/dom
> methods when writing your applicatoin.


Well? Replacing re-occurring blocks of code with parameterised function
call is normal and sensible. I would question the reason for wrapping
code in a function when that function itself only contains one line of
code.
>> Generally, javascript is easier to write, maintain and understand
>> when it uses references to objects directly instead of indirectly
>> referring to them with string values representing names and IDs.
>
> True, but to get the initial reference you often have to
> use id,

No you don't. In an event driven system like a web browser the starting
point of code execution is usually attached to the DOM elements of
interest, or they can be recovered from the event object (with elements
that have structural relationships to those elements being recoverable
by reference through the DOM), and if you create an element you have a
reference to it at that point and do not need to get another so long as
you don't prematurely throw it away.

> and if you do this many times in a document, on various
> events for example, then you're going to get sick of typing
> document.getElementById() for such a common task.

I may if I did. A quick text search for '.getElementById(' in all the
60,000 lines of javascript code in the web application I am working on
at the moment shows 220 occurrences.

> Also you could modify $del() to accept either elements(by
> reference) or IDs and act accordingly.

Given how simple the contents of the actual function is, and the fact
that the programmer should know whether they re dealing with an ID sting
or an object reference at the point of calling the function, it would
probably be better to have two function than have each function call
test and branch.

Richard.

Richard Cornford wrote:
> darwinist wrote:
> > Richard Cornford wrote:
> >> wrote:
> >>> Richard Cornford wrote:
> >>>> wrote:
> >>>>> Two-line function library:
> >>>>> <script>
> >>>>> function $(id){return document.getElementById(id);}
> >>>>> function $del(id) {$(id).parentNode.removeChild($(id));}
> >>>>> </script>
> >>>> <snip>
> >>>>
> >>>> As the specification for javascript (ECMA 262) explicitly
> >>>> states that Identifiers beginning with the - $ - symbol
> >>>> are intended to signify machine generated Identifiers it
> >>>> is poor javascript design to write code that uses such
> >>>> identifiers in non-machine generated Identifiers. ...
> <snip>
> >>> I disagree,
> >>
> >> The existence of the convention in the language's
> >> specification is fact.
> >
> > I disagree that it will add to net confusion or obscurity.
>
> Perhaps you should try trimming try quotes you reply to so that the
> context of your responses is not ambiguous.

Apologies for not being clear.

> Confusion results form disappointing expectations. It is not
> unreasonable for someone to read the convention in the language's
> specification and expect others to follow it. When you disregard that
> convention for no good reason you are going to cause confusion, and
> delays and increased maintenance costs while that confusion is resolved.

And I still say this is vague theory when I have presented a practical
example, if an imperfect one, to illustrate just how much "confusion"
would ensue before one sees that $del is delete an element and $make is
make an element and all else in the application is clearer. It's a
style convention, which are project specific, and unenforcable by
interpreters as you say.

> >>> i find it highly intuitive to group functions which
> >>> handle dom-related elements, and it works across browsers.
> >>
> >> What 'works' is not really an issue.
> >
> > Sorry I must have misheard you. Could you say that again?
>
> What 'works' is not really an issue. In allowing the inclusion of the $
> symbol in identifiers and then asserting that it should only be used at
> the start of a machine generated Identifier the specification had no
> choice but allow any Identifier starting with a $ symbol to be legal.
> The interpreter cannot know that an Identifier has been machine
> generated, and so cannot apply special tokenising/parsing rules for
> machine generated Identifiers. Using them where they should not be used
> is going to 'work', it is just something that should not be done.

If the only practical difference it makes is to how some people
interpret it, then it's a style difference, which has no place in a
language specification. Just cause it's in a spec doesn't mean it
should be followed, when the spec doesn't describe the actual platform
you are writing for.

> >> Making up your own conventions is
> >> your choice, but disregarding well known and established conventions
> >> will make your personal conventions act against the wider
> >> readability of your code for programmers who are familiar with the
> >> well known and established conventions.
> >
> > Not all conventions are of equal value.
>
> No they are not. Conventions are essentially arbitrary, they can all be
> disregarded and leave an end result that still 'works'. And there are
> numbers of different conventions applying to the same situations and
> producing different results. Which conventions get followed is largely a
> matter of authority. In a software house there likely are a set of house
> conventions for coding in various languages, probably formalised, and
> all programming staff are required to conform to those conventions.
> However, the set of conventions chosen are not likely to be some
> arbitrary notions plucked from the air and imposed as an exercise in
> power. They will b chosen because they act to benefit the software
> authoring/maintaining process, by making code standard in formal
> structure, easily understood and recognisable for what it is. They will
> be conventions that the programmers are (more or less) familiar with and
> appreciate the motivation for.
>
> The act of specifically stating the convention if the language's
> specification pretty much guarantees that any serious javascript
> programmer will be familiar with it. From that starting point an formal
> coding standards document that overwrites that convention with another
> would be ill-conceived.

Not necessarily, it depends what actual difference it makes.

> > It depends on how well any convention is suited to the
> > task that your code is intended to achieve.
>
> Any naming convention could make DOM related method distinct from
> others, and may would be less ambiguous themselves, and all others would
> avoid facing the reasonable assumption that the convention laid down in

Except manipulating dom objects is so common and important that an
obvious single symbol is very efficient. dom_make takes up more space
on the screen without adding clarity. $make is easier to spot, as well.

> >>> You can talk in vague theory about obscure code and
> >>> confused programmers but I'm not convinced.
> >>
> >> Working to programming conventions is such a sensible idea
> >> that software houses tend to formalise a set of conventions
> >> and insist that all their programmers work to those. They
> >> don't do that because following conventions represents a
> >> 'vague theory', they do it because it reduces their code
> >> maintenance costs by making code quicker to read/understand.
> >> As a result there are sets of well established conventions
> >> for most languages coming from various sources, and
> >> conventions that are found in the pertinent language's
> >> specification are likely to be common in use.
> >
> > There are lots of conventions and they don't always agree.
>
> Of course not. If a formal coding standard say everyone will use one
> particular style of block indentation that it immediately precludes all
> other styles.
>
> >>> I challenge you to find an obscure
> >>> line in this entire windowing system:
> >>> http://darwinist.googlepages.com/htmldesktop.html
> >>
> >> Don't be silly.
> >
> > Don't be puritanical.
>
> In any substantial body of code there will be at least one line that is
> totally obscure when taken out of context.
>
> But we are not interested in absolute obscurity but rather relative
> obscurity. Your:-
>
> $del("something");
>
> - is inherently obscure, It just needs comparing with alternatives such
> as:-
>
> removeDomElementById("soemthing);
>
> In the first case you almost know nothing without the source code for -
> $del -, while in the second case the odds are good that the reader does
> not have to even go an see what the functions does because its name has
> already told them.

Besides the fact that the this approach makes the programs much
shorter, allowing context to be seen more quickly, anyone browsing the
code ought to have sufficient commentary as to why something is being
deleted, and what it is. An application must be allowed its own
linguistic context in which things like "del" have a known meaning. In
a file-system-based command line it would be assumed it was a file, in
any web-application that's gui heavy, it might mean a gui element. The
$ just makes it even more clear in the context of that particular
project.

> <snip>
> >>> I'm not particularly interested in coding to the bugs of a
> >>> product whose manufacturers don't even pretend it's good
> >>> anymore.
> >>>
> >>> $del("id"); is quick and easy and allows you to be more
> >>> productive.
> >>
> >> What it does for you is not relevant. It will potentially get
> >> in the way of the productivity of a third party knowledgeable
> >> javascript programmer attempting to maintain your code as they
> >> will have to spend effort determining that this apparently
> >> machine generated Identifier is not actually machine generated
> >> (and then expend effort re-writing your code to eliminate the
> >> faulty Identifiers).
> >
> > a) it's a common practice (ask google if you don't believe me)
>
> What is common practice? Using initial $ symbols in javascript code, or
> using initial $ symbols to indicate DOM related methods?

The latter, to return elements by id or reference. I don't know if many
people use $make and $del and $input and $text, but I liked the idea
and the syntax so much (being a php programmer, which I think a lot of
js programmers are these days), that I extended the idea for my
windowing system.

> First, the vast majority of the javascript code in the world was written
> (or copy and pasted) by people who did not really know what they were
> doing (and most of the stuff that can be copy and pasted was written by
> equally under informed individuals). As a result any appeal to what is
> 'common practice' is likely an appeal to 'bad practice'.

Your primary argument against using the $ to denote dom elements is one
of convention, to avoid confusing people who are experienced
javascript programmers. What if they're experienced in these bad
practices?

> Initial $ symbols are commonly abused in actual javascript code, but
> they certainly are not commonly misused for any single specific purpose.
> They can be used to reflect the use of the $ symbol in other languages
> (usually with a significant conceptual mismatch), they can be being used
> to indicate values of string type, they can be used to indicate values
> that should be regarded as internal or private. Indeed you are the first
> person I have read proposing that they be used to indicate DOM related
> functions. It is in fact this diversity of $ abuses that suggests that
> any use outside of the conventions provided in the specification is
> unwise, as no other expectation would be common.
>
> > b) it makes your code shorter and more readable
>
> Shorter maybe, but shortness at the cost of readability is not a good
> trade-off (as shortness can be machine imposed post development). While
> readability is precisely what it does not proved. There is no reason for
> a reader to see a $ symbol as having anything to do with DOM related
> functions, and very good reasons for them to see the $ symbol as having
> something to do with machine generation.

If you're open to the idea of project-specific style-conventions, then
as I've said it's a matter of a few seconds to see the consistent
convention in any application that uses the dollar sign this way. I
propose it because so many web applications are getting so gui heavy,
and it's the shortest, clearest means of distinction that I can see.

> > c) you can combine it with other useful element functions, like
> > $make(tagname, id); // make an element
> > $input(type, name, value, [id]) // make an input
> > $text(text) // make a text node
>
> Wrapping common code structures into parameterised functions is not an
> idea that requires, or justifies, a specific naming convention.
> dom_make, dom_input and dom_text being just as possible, and
> fractionally less obscure.

You can spot a dollar sign more easily in a sea of roman characters.

> > d) this approach allows you write applications more quickly.
>
> It is well known that the maintenance costs are always a significant
> factor in applications.

Yes, which is why brevity and readability are so important.

> > e) you can then optimise for speed in any areas that
> > are script-heavy.
>
> There is no relationship between an ability to optimise for speed and
> the use of any particular naming convention.

If you can express the initial prototype more quickly and clearly then
yes, there is.

> > f) most programmers would know it to be a waste of time to
> > rewrite something that works for style alone
>
> Most programmers would know enough not to write something obscurely in
> the first place.

Your equation of clarity with an absolute naming convention, is close
minded. There is much more to clarity.

> > g) In this particular case, nobody would be confused for
> > more than ten seconds, if at all, after which this function
> > will save them a great many keystrokes, without a noticable
> > difference in page performance.
>
> If you were not even aware of the IE memory leak problem I don't think
> you have ever written anything with javascript that qualifies you to
> make such statements about performance.

Lucky for me I don't care what you think I'm qualified to do.

> Of all the things that may be 'saved' in software authoring I don't
> think anyone would seriously propose that keystrokes are something that
> needs worrying about.

Brevity of code is not just keystrokes. You can look at more code at
once and still see more comments and whitespace. The code is closer to
english and no matter how well you get to know any computer language,
english will be clearer, especially when you've been away from the
project for a while or someone else takes over some of it.

> >> The overall impact of having to stuff a document with an
> >> excessive number of unique element IDs may be less apparent,
> >> but it will act to hinder development in the longer term.
> >
> > So will long and complicated statements, which are inevitable
> > if you stick as close as possible to the native javascript/dom
> > methods when writing your applicatoin.
>
>
> Well? Replacing re-occurring blocks of code with parameterised function
> call is normal and sensible. I would question the reason for wrapping
> code in a function when that function itself only contains one line of
> code.

To save 10 - 20 bytes per call.

> >> Generally, javascript is easier to write, maintain and understand
> >> when it uses references to objects directly instead of indirectly
> >> referring to them with string values representing names and IDs.
> >
> > True, but to get the initial reference you often have to
> > use id,
>
> No you don't. In an event driven system like a web browser the starting
> point of code execution is usually attached to the DOM elements of
> interest, or they can be recovered from the event object (with elements
> that have structural relationships to those elements being recoverable
> by reference through the DOM), and if you create an element you have a
> reference to it at that point and do not need to get another so long as
> you don't prematurely throw it away.

Interesting, I'll try to be more efficient with my references.

> > and if you do this many times in a document, on various
> > events for example, then you're going to get sick of typing
> > document.getElementById() for such a common task.
>
> I may if I did. A quick text search for '.getElementById(' in all the
> 60,000 lines of javascript code in the web application I am working on
> at the moment shows 220 occurrences.
>
> > Also you could modify $del() to accept either elements(by
> > reference) or IDs and act accordingly.
>
> Given how simple the contents of the actual function is, and the fact
> that the programmer should know whether they re dealing with an ID sting
> or an object reference at the point of calling the function, it would
> probably be better to have two function than have each function call
> test and branch.

Good idea.

> Richard.