Adding rows to a table, works in Firefox, but not IE

[Marc Bradshaw]

Hi there, I'm fairly new to JavaScript, coming from a PHP background,
and I am using JavaScript to make the interface nicer on a customer
management system I developed. I'm currently working on the actual page
which allows users to edit a certain customer's details, but I am having
problems getting it to work in IE7.

I have a table containing names and contact details for customers. I
have a <tbody> tag after my <table> tag, and a </tbody> tag before my
</table> tag, which I thought meant that JavaScript in IE could then
work with the table. In any event, one of my JavaScript functions is
supposed to add two rows and then populate them.

The code is incredibly long so I have included a cut-down version below,
but here is a summary of how it works: I use createElement to produce
many <span> elements, four <td> elements and two <tr> elements. I then
use appendChild to place the <span> elements into the <td> elements, the
<td> elements into the <tr> elements, and the <tr> elements into my
existing <tbody>.

In Firefox this works fine. In IE, as soon as I click the button which
should execute the function, I get an 'error on page' message in the
Status bar. On clicking the icon, I get the error "Object doesn't
support this property or method" with this line:
contactsTable.appendChild(newContactTr1);. 'contactsTable' is my tbody,
which I get by using getElementById() on the previous line.

It's got me stumped. Does anyone have any ideas? The cut-down code is
pasted below.

Thanks,
Marc


this.insertContactDiv = function() {
var self = Contacts;

var fnameSpan = null;
var lnameSpan = null;

var fnameInput = null;
var lnameInput = null;

var cancelButton = null;
var saveButton = null;
var leftButtonDiv = null;
var rightButtonDiv = null;
var clearBothDiv = null;

fnameSpan = document.createElement('span');
lnameSpan = document.createElement('span');

fnameSpan.id = 'fname-NewContactTemp';
lnameSpan.id = 'lname-NewContactTemp';

newContactTr1 = document.createElement('tr');
newContactL1 = document.createElement('td');
newContactR1 = document.createElement('td');
newContactL1.style.fontWeight = 'bold';
newContactR1.style.fontWeight = 'bold';

space = function () { return document.createTextNode(' '); }

newContactTr1.id = 'row1-NewContactTemp';

newContactL1.appendChild(fnameSpan);
newContactL1.appendChild(space());
newContactL1.appendChild(lnameSpan);

newContactR1.appendChild(document.createTextNode('Address'));

newContactTr1.appendChild(newContactL1);
newContactTr1.appendChild(newContactR1);

contactsTable = document.getElementById('contactsTable');
contactsTable.appendChild(newContactTr1);

return true;
};

The applicable HTML being:
<tbody id="contactsTable">...</tbody>

 

[Richard Cornford]

Hi there, I'm fairly new to JavaScript, coming from a PHP
background, and I am using JavaScript to make the interface
nicer on a customer management system I developed. I'm
currently working on the actual page which allows users to
edit a certain customer's details, but I am having problems
getting it to work in IE7.

I have a table containing names and contact details for
customers. I have a <tbody> tag after my <table> tag, and
a </tbody> tag before my </table> tag, which I thought meant
that JavaScript in IE could then work with the table.

The tags themselves are optional in HTML. Omit them form the mark-up and
they will be implied, the opening tag by any TR encounter outside a
table section element (TBODY, THEAD and/or TFOOT) and the closing one by
the first subsequent occurrence of a closing TABLE tag or opening table
section tag.

In any event, one of my JavaScript functions is supposed to add two
rows and then populate them.

The code is incredibly long so I have included a cut-down
version below, but here is a summary of how it works: I
use createElement to produce many <span> elements, four
<td> elements and two <tr> elements. I then use
appendChild to place the <span> elements into the <td>
elements, the <td> elements into the <tr> elements, and
the <tr> elements into my existing <tbody>.

In Firefox this works fine. In IE, as soon as I click the
button which should execute the function, I get an 'error
on page' message in the Status bar. On clicking the icon,
I get the error "Object doesn't support this property or
method" with this line: contactsTable.appendChild(newContactTr1);.
'contactsTable' is my tbody,

That is a very non-obvious name for a TBODY element reference.

which I get by using getElementById() on the previous line.

It's got me stumped. Does anyone have any ideas? The
cut-down code is pasted below.

Cut-down code is probably better than masses of irrelevant code, but
ideally you would create a fully 'working' self-contained, minimal
test-case page that demonstrated the phenomenon in isolation, and post
that (along with the URL of it online, to satisfy the people who prefer
them online). That lets everyone start off with an ability to try it in
context and see if the phenomenon described exists, and is the one
described (experience shows that neither are necessarily true for
questions asked on this group).

It has also been observed that the attempt to create a minimal test-case
page often revels the source of the issue and so avoids the need to ask
the question.

this.insertContactDiv = function() {

"insertContactDiv" is a perverse name for a method that seems to have
nothing to do with DIV elements at all.

var self = Contacts;

This is never used.

var fnameSpan = null;
var lnameSpan = null;

var fnameInput = null;
var lnameInput = null;

var cancelButton = null;
var saveButton = null;
var leftButtonDiv = null;
var rightButtonDiv = null;
var clearBothDiv = null;

why waste time assigning null to all these variables?

fnameSpan = document.createElement('span');
lnameSpan = document.createElement('span');

fnameSpan.id = 'fname-NewContactTemp';
lnameSpan.id = 'lname-NewContactTemp';

newContactTr1 = document.createElement('tr');
newContactL1 = document.createElement('td');
newContactR1 = document.createElement('td');
newContactL1.style.fontWeight = 'bold';
newContactR1.style.fontWeight = 'bold';

space = function () { return document.createTextNode(' '); }

Where is - space - declared? If you want an inner function then why not
an inner function declaration?

newContactTr1.id = 'row1-NewContactTemp';

newContactL1.appendChild(fnameSpan);
newContactL1.appendChild(space());
newContactL1.appendChild(lnameSpan);

newContactR1.appendChild(document.createTextNode('Address'));

newContactTr1.appendChild(newContactL1);
newContactTr1.appendChild(newContactR1);

contactsTable = document.getElementById('contactsTable');

It is actually this line that is erroring. You have not declared a local
variable (or a global variable, though it should not be global) called
"contactsTable", but you do have a DOM element with the ID
"contactsTable". On IE, for each DOM element with an ID attribute a
property of the global object is created with the property name that
corresponds with the ID and a value that is a reference to the DOM
element (unless a global variable is declared using that global property
name). These global properties created for IDed DOM elements are
read-only and produce an "object doesn't support this property or
method" error if you attempt to write values to them. And without
declaring a "contactsTable" variable locally your assignment to it is an
assignment to a property of the global object.

contactsTable.appendChild(newContactTr1);

return true;
};

The applicable HTML being:
<tbody id="contactsTable">...</tbody>

No that is not the applicable HTML. The first question anyone looking at
it will ask is; 'what do the dots represent?', and it has no context.
Context is very impotent in debugging javascript.

Richard.

 

[Marc Bradshaw]

The tags themselves are optional in HTML. Omit them form the mark-up and
they will be implied, the opening tag by any TR encounter outside a
table section element (TBODY, THEAD and/or TFOOT) and the closing one by
the first subsequent occurrence of a closing TABLE tag or opening table
section tag.

How confusing. I only added the <tbody> tags in at the suggestion of

That is a very non-obvious name for a TBODY element reference.

Indeed it is. The reasoning is above, but I have now changed this to
contactsTbody.

Cut-down code is probably better than masses of irrelevant code, but
ideally you would create a fully 'working' self-contained, minimal
test-case page that demonstrated the phenomenon in isolation, and post
that (along with the URL of it online, to satisfy the people who prefer
them online). That lets everyone start off with an ability to try it in
context and see if the phenomenon described exists, and is the one
described (experience shows that neither are necessarily true for
questions asked on this group).

It has also been observed that the attempt to create a minimal test-case
page often revels the source of the issue and so avoids the need to ask
the question.

Point taken. I shall do this next time.

"insertContactDiv" is a perverse name for a method that seems to have
nothing to do with DIV elements at all.

Indeed. The reasoning is that I did try to produce the page with <div>
elements but reluctantly switched to a table when too much customer

This is never used.

In the cut down code, no. Contacts is the object which this function is
a method of. I suppose I could have removed this line when I pasted it.

why waste time assigning null to all these variables?

I was told it was good practice in JavaScript to declare variables as
null first, before assigning them values. Is this not the case?

Where is - space - declared? If you want an inner function then why not
an inner function declaration?

Excuse my ignorance, but could you explain this comment please? What is
an inner function declaration?

It is actually this line that is erroring. You have not declared a local
variable (or a global variable, though it should not be global) called
"contactsTable", but you do have a DOM element with the ID
"contactsTable". On IE, for each DOM element with an ID attribute a
property of the global object is created with the property name that
corresponds with the ID and a value that is a reference to the DOM
element (unless a global variable is declared using that global property
name). These global properties created for IDed DOM elements are
read-only and produce an "object doesn't support this property or
method" error if you attempt to write values to them. And without
declaring a "contactsTable" variable locally your assignment to it is an
assignment to a property of the global object.

Thank you for your explanation, I changed the variable name to
'contactsTbody' and because the ID of the <tbody> is contactsTable, the
code now works correctly. Is there a better way to do this though? I
now have a <tbody> with an ID attribute of 'contactsTable' which is
referred to in my JavaScript as 'contactsTbody' which I guess is not
ideal for code readability and debugging.

No that is not the applicable HTML. The first question anyone looking at
it will ask is; 'what do the dots represent?', and it has no context.
Context is very impotent in debugging javascript.

Okay, I should not have inserted the dots. They represent the rows that
the JavaScript I have already pasted inserts.

Thank you for your assistance.

Marc

 

[Thomas 'PointedEars' Lahn]

Indeed. The reasoning is that I did try to produce the page with <div>
elements but reluctantly switched to a table when too much customer
information meant I was left with <div> soup.

A `table' element should only be used on purpose, i.e. when there is tabular
data, or there is no interoperable formatting solution with CSS.

I was told it was good practice in JavaScript to declare variables as
null first, before assigning them values. Is this not the case?

It is not. Null is an object type, so only object variables (i.e. variables
that only exist to hold references to objects) should be initialized with
`null'. However,

var cancelButton;

*is* a declaration that implicitly assigns `undefined' to that variable.
Since `undefined' is a false-value, too, it would not be necessary to
initialize with `null' if one is only to test whether there is an object
reference assigned to the variable or not.

Furthermore, you are assigning everything twice needlessly:

var fnameSpan = null;
// ...
fnameSpan = document.createElement('span');

Since you are not testing for anything (which is a Bad Thing though), you
could equally write

var fnameSpan = document.createElement('span');

However, feature-testing would be better:

/**
* @see http://pointedears.de/scripts/types.js
*/
function isMethodType(s)
{
return /\b(function|object)\b/i.test(s);
}

var fnameSpan; // or initialize with `null' here, I can accept that
if (isMethodType(typeof document.createElement)
&& document.createElement
&& (fnameSpan = document.creatElement('span')))
{
// ...
}

Excuse my ignorance, but could you explain this comment please? What is
an inner function declaration?

function outer()
{
function inner()
{
}

inner();
}


HTH

PointedEars

 

[Marc Bradshaw]

A `table' element should only be used on purpose, i.e. when there is tabular
data, or there is no interoperable formatting solution with CSS.

Agreed. I could not get the page using <div> elements to display
correctly with CSS, and so I converted it to a table as I reasoned that
it is sort of tabular data (customer contact information and details).
My ideal solution would be detailed lists, which I hope to convert this
page to when I have more time, but I settled with a table as a temporary
solution.

It is not. Null is an object type, so only object variables (i.e. variables
that only exist to hold references to objects) should be initialized with
`null'. However,

var cancelButton;

*is* a declaration that implicitly assigns `undefined' to that variable.
Since `undefined' is a false-value, too, it would not be necessary to
initialize with `null' if one is only to test whether there is an object
reference assigned to the variable or not.

Thank you for clarifying. I assume I misread/misunderstood something in
my reading about variable declaration then. I'm still leaning.

Furthermore, you are assigning everything twice needlessly:

var fnameSpan = null;
// ...
fnameSpan = document.createElement('span');

Since you are not testing for anything (which is a Bad Thing though), you
could equally write

var fnameSpan = document.createElement('span');

However, feature-testing would be better:

/**
* @see http://pointedears.de/scripts/types.js
*/
function isMethodType(s)
{
return /\b(function|object)\b/i.test(s);
}

var fnameSpan; // or initialize with `null' here, I can accept that
if (isMethodType(typeof document.createElement)
&& document.createElement
&& (fnameSpan = document.creatElement('span')))
{
// ...
}

Thanks for that. I sort of understand what you're saying. I shall have
a play with this later.

function outer()
{
function inner()
{
}

inner();
}

In that case, was I not declaring an inner function, just on one line?
What is the difference between space = function() and function space()?

Marc

 

[Thomas 'PointedEars' Lahn]

Agreed. I could not get the page using <div> elements to display
correctly with CSS, and so I converted it to a table as I reasoned that
it is sort of tabular data (customer contact information and details).
My ideal solution would be detailed lists, which I hope to convert this
page to when I have more time, but I settled with a table as a temporary
solution.

"Detailed lists"?

In that case, was I not declaring an inner function, just on one line?
What is the difference between space = function() and function space()?

You did not declare it, as `space' was a variable, and the `var' keyword was
missing; so you either modified an existing property of an object along the
scope chain, added a property to the global object (i.e. a global variable),
or cause a runtime error (in the MSHTML DOM if `space' was the name or ID of
an element).

Another difference is that the variable assignment requires a function
expression, while the function declaration does not. And the declared
function can be `delete'd (i.e. its identifier made unavailable so that the
Function object referenced can be subject to Garbage Collection), while the
declared variable cannot be `delete'd (it can only be assigned `null' and so
its referenced object can be GC'd, with the identifier still being available).


PointedEars

 

[Thomas 'PointedEars' Lahn]

Another difference is that the variable assignment requires a function
expression, while the function declaration does not. And the declared
function can be `delete'd (i.e. its identifier made unavailable so that the
Function object referenced can be subject to Garbage Collection), while the
declared variable cannot be `delete'd (it can only be assigned `null' and so
its referenced object can be GC'd, with the identifier still being available).

Apparently neither can be deleted anymore (FF2). Or is my memory betraying me?


PointedEars

 

[Thomas 'PointedEars' Lahn]

Apparently neither can be deleted anymore (FF2). Or is my memory betraying me?

It isn't. Inner functions cannot be deleted in FF2, outer (global)
functions can be.


PointedEars

 

[Marc Bradshaw]

"Detailed lists"?

Sorry, I meant definition lists:
http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.3

You did not declare it, as `space' was a variable, and the `var' keyword was
missing; so you either modified an existing property of an object along the
scope chain, added a property to the global object (i.e. a global variable),
or cause a runtime error (in the MSHTML DOM if `space' was the name or ID of
an element).

I assume then, that the result I was achieving was the middle of your
three options. Presumably I should have done var space; first?

Another difference is that the variable assignment requires a function
expression, while the function declaration does not. And the declared
function can be `delete'd (i.e. its identifier made unavailable so that the
Function object referenced can be subject to Garbage Collection), while the
declared variable cannot be `delete'd (it can only be assigned `null' and so
its referenced object can be GC'd, with the identifier still being available).

I'm afraid this totally went over my head.

Marc

 

[Marc Bradshaw]

Furthermore, you are assigning everything twice needlessly:

var fnameSpan = null;
// ...
fnameSpan = document.createElement('span');

Since you are not testing for anything (which is a Bad Thing though), you
could equally write

var fnameSpan = document.createElement('span');

What is be the difference between the following two lines assuming
fnameSpan is not a previously used variable name, and there is no HTML
element with the id fnameSpan?

var fnameSpan = document.createElement('span');

fnameSpan = document.createElement('span');

However, feature-testing would be better:

/**
* @see http://pointedears.de/scripts/types.js
*/
function isMethodType(s)
{
return /\b(function|object)\b/i.test(s);
}

var fnameSpan; // or initialize with `null' here, I can accept that
if (isMethodType(typeof document.createElement)
&& document.createElement
&& (fnameSpan = document.creatElement('span')))
{
// ...
}

I reread this several times, and I had a look at your script and the
comments therein, and I really can't understand what this code does -
what are you testing for?

Marc

 

[Richard Cornford]

How confusing. I only added the <tbody> tags in at the suggestion
of someone else that IE could not directly write to <table>
elements.

IE cannot append TR elements to TABLE elements, and errors if you try.
But Mozilla/Friefox/Gecko cannot do so either in their HTML DOMs, the
only difference is that if you try in those browsers they will 'correct'
the mistake by automatically creating a new TBODY element, appending
that to the TABLE element and then append your TR element to the new
TBODY. To be honest I prefer IE's handling of this as it is up-front
about letting you know that what you are attempting is not on.

The Mozilla/firefox issue is confused by XHTML, where a TR can be a
direct child of a TABLE. Because no tags are optional in XHTML and they
wanted some compatibility with HTML where the TBODY tags are optional
and so the TBODY elements are (or can be) implied. That is, you can
write both HTML and XHTML mark-up without THOBY tags, but the resulting
DOM has a differing structure if you do.

I was told it was good practice in JavaScript to declare
variables as null first, before assigning them values.
Is this not the case?

Total nonsense. It sounds like the sort of thing that might come form
someone familiar(ish) with Java who has not understood that javascript
is not Java (or even similar to it).

In javascript if you declare a variable it is automatically initialised
with the undefined value (in javascript undefined is a value not a
state). From then on the variable exists (as a named property of a
Variable object) and has a determinable value (either the initial
undefined value or a value subsequently assigned in code), until the
Variable object it is created on becomes unavailable (mostly because the
function in which the variable is declared returns) and gets garbage
collected.

There are a huge number of things that get said about writing
javascript, some of which are ladled 'best (or good) practices'.
Unfortunately they include a great many things that are rumours,
old-wife's tales and/or mystical incantations. They persist because, by
and large, the do no perceivable harm, and the people promoting them
never expose themselves to an environment where there is enough genuine
knowledge to challenge them (or they don't listen when that does
happen). This one is a mystical incantation; it does nothing useful, it
does no notable harm, it just makes everything run just fractionally
slower that it would if you didn't bother.

Generally, if someone proposes that something represents a 'best
practice' in javascript you should read their explanation with
_critical_ judgment, and if they don't explain, or cannot explain, then
don't pay any attention. The noise-to-signal ratio is very high in this
area.

Excuse my ignorance, but could you explain this comment please?
What is an inner function declaration?

An inner function declaration is a function declaration inside a
function declaration. What you have here is a function expression
assigned to an Identifier (space) that is undeclared (in this code). The
result is that you can call the function that results from the
evaluation of the function expression using - space() -, and you do. But
if you use a function declaration:-

function space(){ return document.createTextNode(' '); }

- you end up with a function that you can call with - space() -. In both
cases you create a new function object each time the containing method
is executed (which is not a good idea given that this function has no
interest in the context of its creation and so could be a single global
function declared and created once). But one difference with using an
inner function declaration here is that the resulting function cannot
then be accessible outside of the containing method, which it is in your
code, though seemingly not by design/need/intention.

Thank you for your explanation, I changed the variable name to
'contactsTbody' and because the ID of the <tbody> is
contactsTable, the code now works correctly. Is there a better
way to do this though?

Yes, declare the variable that you assign the value returned from -
document.getelementById - as a function local variable (with - var -
inside the containing function body (preferably at, or near, the
beginning)) and your assignment will then never go anywhere near the
global object, and so it will not matter at all what IE may have done to
the global object.

I now have a <tbody> with an ID attribute of 'contactsTable'
which is referred to in my JavaScript as 'contactsTbody' which
I guess is not ideal for code readability and debugging.

<snip>

Not ideal, but not at all a difficult problem to solve. Suppose, for
example, that you adopted a style of naming for ID attributes that used
an initial uppercase letter, all upper case, or words separated with
underscores, or anything that you never use in your javascript naming
conventions. Then this type of thing cannot happen. Though with
appropriate use of variable declarations it would not happen most of the
time anyway.

Richard.

 

[Marc Bradshaw]

Testing to see if document.createElement is a function/object, then it
is redundantly testing for it again, then it is testing to see if it can
set fnameSpan to a newly created Span element.

It is overly complicated and redundant testing.

I meant that I couldn't understand the reasons for testing more than I
couldn't understand the code itself. With your clarification, I still
can't see the reasons, other than if the testing is to make sure the
code works in older browsers before proceeding to use it, thus
preventing errors?

Marc

 

[Thomas 'PointedEars' Lahn]

Sorry, I meant definition lists:
http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.3

Ahh, but IMHO definition lists should be used for *definition* *lists* only.

I assume then, that the result I was achieving was the middle of your
three options.

Probably. But the outcome of such an assignment is often counter-intuitive,
so that one should simply declare everything. See the recent thread
"JavaScript knowledge test".

Presumably I should have done var space; first?

var space = function()
{
// ...
};

or

function space()
{
// ...
}

where I preferred (and Richard recommended) the latter here.

I'm afraid this totally went over my head.

The first thing you have to understand is that functions are (first-class)
objects in ECMAScript implementations. So if you write

var space = function()
{
// ...
};

what happens is essentially that

1. Upon variable instantiation, which happens before execution,
a new local variable named `space' is created as property of the
Variable Object of the local execution context.

2. When execution comes to this line, the right-hand side is evaluated
as a FunctionExpression that creates a Function object. A reference
to that Function object is then stored, through evaluation of the
AssignmentExpression, as the value of the `space' variable.

With

function space()
{
// ...
}

what happens is essentially that

1. Upon variable instantiation, a new local variable named `space' is
created as property of the Variable Object of the local execution
context. A new Function object is created and a reference to it
is assigned to that local variable.

The `delete' difference I described was that you could write

delete space;

and then have the `space' identifier made unavailable through this. Since
there was no more reference to the corresponding Function object, that
Function object could then be subject to Garbage Collection (i.e. the memory
allocated for it could be freed through an internal marking algorithm).

The same could happen if one would assign `null' later to the previously
initialized variable:

var space = ...;
// ...
space = null;

However, in a later test it turned out that if `space' was the name of an
inner function, then in Firefox 2.0.0.6

delete space;

would constitute no change -- the `space' identifier would be available
still; whereas in global context, access to the identifier after the
`delete' statement, like

space();

would result in a run-time error.


HTH

PointedEars

 

[Thomas 'PointedEars' Lahn]

What is be the difference between the following two lines assuming
fnameSpan is not a previously used variable name, and there is no HTML
element with the id fnameSpan?

var fnameSpan = document.createElement('span');

fnameSpan = document.createElement('span');

The first one declares the local variable fnameSpan; the second one modifies
a property of an object along the scope chain or creates a global variable
(i.e. a property of the global object).

I reread this several times, and I had a look at your script and the
comments therein, and I really can't understand what this code does -
what are you testing for?

I am making sure

1. that document.createElement can be called.

- The type of document.createElement is tested for by using the
`typeof' operator. If the result of operation contains one of
the words `function' or `object' (the latter known to be returned
for supported DOM methods in the MSHTML DOM), isMethodType() returns
`true'.

- However, if the `typeof' operation resulted in "object" (or something
containing it), the value of the property might still be `null'.
So it is *required* that the property value be implicitly
type-converted and tested that the type conversion does not result
in `false'.

The `typeof' operation is used first because it does not evaluate its
operand. So isMethodType() would not cause a run-time error if used
on unknown identifiers. (Only a simple type-conversion test could not
provide this.)

2. that if the former applies, the call is successful in the sense that it
returns an object reference. The boolean expression combined with the
assignment makes sure that after the boolean expression has been
evaluated to `true' and execution has entered the block, `fnameSpan' is
assigned a reference to the newly created object.

It is the most reliable and efficient way of feature detection I have seen
to date.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Ignore Randy, he does not know what he is writing about.

I meant that I couldn't understand the reasons for testing more than I
couldn't understand the code itself. With your clarification, I still
can't see the reasons, other than if the testing is to make sure the
code works in older browsers before proceeding to use it, thus
preventing errors?

Almost correct. Using such feature detection allows client-side DOM
scripting to degrade gracefully, providing fallbacks for peculiarities of
DOM implementations and alternatives for proprietary DOMs where such
alternatives exist. That does not have anything to do with the age of the
supported Web user agent; vendors have introduced proprietary features and
behaviors at all times.


PointedEars

 

[Richard Cornford]

I meant that I couldn't understand the reasons for testing more
than I couldn't understand the code itself. With your
clarification, I still can't see the reasons, other than if
the testing is to make sure the code works in older browsers
before proceeding to use it, thus preventing errors?

The testing is a matter of being in a position to control the behaviour
of your scripts in environment where they cannot do what you would like
then to do, which is not just "older browsers" because there are plenty
of brand new browsers that are just not dynamic enough to proved
scripted modification of the DOM (mostly due to being designed for small
devices where the resources (in terms of memory and processor speed) are
not sufficed for the task).

Ideally a public web site should be designed so that it can achieve
'clean degradation' whenever the user's browser does not facilitate
whatever is demanded of it in terms of scripting, but to do that it is
usually necessary that a script discover the limitations and back-out of
what it might otherwise attempt under its own control. If a script
generates a runtime error then it is likely to leave the page in an
unknown/intermediate state that would be less viable than if the script
had never existed in the first place. That is considered the nadir of
web browser scripting, and the opposite of a demonstration of
competence.

(For other contexts, such as browser-specific Internet
sites/applications, other criteria and strategies may be appropriate.
Though this group stats (in its FAQ) that its default assumption is that
the context of code posted is public web use, unless explicitly stated
otherwise)

Richard.

 

[Marc Bradshaw]

Ahh, but IMHO definition lists should be used for *definition* *lists* only.

Is this not a list of customer contact details? How, prey tell, would
you recommend I markup this data then? I would think definition lists
(for example phone numbers and their descriptions) would be valid here.

HTH

Thanks, your detailed explanation did. =)

Marc

 

[Marc Bradshaw]

... That does not have anything to do with the age of the
supported Web user agent; vendors have introduced proprietary features and
behaviors at all times.

But presumably the same logic and coding style could be applied to catch
instances where certain JavaScript will not work due to an older browser
being used?

Marc

 

[Marc Bradshaw]

(For other contexts, such as browser-specific Internet
sites/applications, other criteria and strategies may be appropriate.
Though this group stats (in its FAQ) that its default assumption is that
the context of code posted is public web use, unless explicitly stated
otherwise)

I'll be sure to make that clarification next time, as all of this code
was for a backend interface, of which I have some (though not complete)
control over the browser being used.

Marc

 

[Thomas 'PointedEars' Lahn]

Is this not a list of customer contact details? How, prey tell, would
you recommend I markup this data then? I would think definition lists
(for example phone numbers and their descriptions) would be valid here.

Reads like tabular data to me, that is a heading assigned to one or more
values. The heading (th) would be the name of the date, for example `Phone
number' and the date itself (td) would be the phone number. So a `table'
element is indicated, indeed.

Thanks, your detailed explanation did. =)

You're welcome.


PointedEars