typeof.currentE lement.innerTex t not working in Firefox?

[effendi]

I am testting the following code in firefox

function fDHTMLPopulateF ields(displayVa luesArray, displayOrderArr ay)
{
var i,
currentElement,
displayFieldID,
currentChild,
nDisplayValues = displayValuesAr ray.length;
for (i=0; i<nDisplayValue s; i++) {
displayFieldID = "div_" + displayOrderArr ay[i] + "ID";
currentElement = (document.getEl ementById
&& document.getEle mentById(displa yFieldID))
|| (document.all
&& document.all(di splayFieldID));
if (typeof currentElement == "object") {
if (typeof currentElement. innerText != "undefined" ) {
currentElement. innerText = displayValuesAr ray[i];
}
else if (
currentElement. firstChild
&& currentElement. removeChild
&& currentElement. appendChild
&& document.create TextNode
) {
while ((currentChild = currentElement. firstChild)) {
currentElement. removeChild(cur rentChild);
}
currentElement. appendChild(
document.create TextNode(displa yValuesArray[i])
);
}
}
}
}

The code works in IE but running in FF it does not go into the loop
--->
if (typeof currentElement. innerText != "undefined" )

if this something only IE recognises? I do I change it to work in FF?

Thanks in advance.

[RobG]

ef*****@epitome .com.sg wrote:

I am testting the following code in firefox

[...]

The code works in IE but running in FF it does not go into the loop
--->
if (typeof currentElement. innerText != "undefined" )

if this something only IE recognises? I do I change it to work in FF?

innerText is a proprietary IE property, the W3C equivalent (supported
by Firefox) is textContent. You might like to use a function that
works in a wide variety of browsers:

function getText(el)
{
if ('string' == typeof el.textContent) return el.textContent;
if ('string' == typeof el.innerText) return el.innerText;
return el.innerHTML.re place(/<[^>]*>/g,'');
}

where 'el' is a reference to a DOM element.
--
Rob

[Trond Michelsen]

RobG wrote:

function getText(el)
{
if ('string' == typeof el.textContent) return el.textContent;
if ('string' == typeof el.innerText) return el.innerText;
return el.innerHTML.re place(/<[^>]*>/g,'');
}

This completely off-topic is, but programmed this was by Yoda?

I know their order doesn't really matter, but I would just think that

if (typeof el.textContent == 'string') return el.textContent;

would read better. "if (5 == x)" just seems so backwards to me.

--
Trond Michelsen

[Richard Cornford]

Trond Michelsen wrote:

RobG wrote:

function getText(el)
{
if ('string' == typeof el.textContent) return el.textContent;
if ('string' == typeof el.innerText) return el.innerText;
return el.innerHTML.re place(/<[^>]*>/g,'');
}

This completely off-topic is,

It is not off topic. The topic of the group is javascript and how
javascript code may be written is certainly on topic. Don't let the
subjects of posts fool you, the do not restrict the subsequent
discussion to anything in particular (except by coincidence).

but programmed this was by Yoda?

I know their order doesn't really matter, but I would just think that

if (typeof el.textContent == 'string') return el.textContent;

would read better. "if (5 == x)" just seems so backwards to me.

Writing the comparison this way around avoids the common error where
and assignment operator is used in place of a comparisons operator. If
code attempts to assign to a string (or indeed any) literal then the
error happens at that point. While assigning a string value to an
Identifier is legal, and the consequential errors (if spotted at all)
happen elsewhere and may be difficult to attribute to their cause.

Precedence plays a role in this as assignment has higher precedence
than - typeof - which has higher precedence than comparison. So:-

typeof x == 'string'

-is:-

((typeof x) == 'string')

- while:-

typeof x = 'string'

-is:-

(typeof (x = 'string')) //which is inevitably boolean true
// if used in an - if - expression.

Richard.

[Touffy]

On 2006-10-03 15:58:06 +0200, "Richard Cornford"
<Ri*****@litote s.demon.co.uksa id:

(typeof (x = 'string')) //which is inevitably boolean true
// if used in an - if - expression.

Look what coding in C has done to you ;)

In JavaScript, an assignment operation returns the assigned value, not
true of false. Which is why you can write things like :

a = b = c = 'value'

or this beautiful one-line Fibonacci formula :

a = b + (b = a) // too bad there must be parens here

and this behavior is not altered by and enclosing if().
So the type of (x = 'string') happens to be the value itself, 'string'.

--
David Junger

[Richard Cornford]

Touffy wrote:

On 2006-10-03 15:58:06 +0200, "Richard Cornford"
<Ri*****@litote s.demon.co.uksa id:

(typeof (x = 'string')) //which is inevitably boolean true
// if used in an - if - expression.

Look what coding in C has done to you ;)

In JavaScript, an assignment operation returns the assigned value, not
true of false. Which is why you can write things like :

a = b = c = 'value'

<snip>

I am aware of this, but the evaluated value of the expression used in
an - if - statement is not the end of the story.

and this behavior is not altered by and enclosing if().
So the type of (x = 'string') happens to be the value itself, 'string'.

In an - if - statement the value of the expression (string in this
case, as typeof operations always evaluate as strings) is internally
type-converted to boolean in order to determine how the - if -
expression will act. The - typeof - operator always returns non-empty
strings, and non-empty strings type-convert to boolean true. So if the
construct is placed in the expression of an - if - statement the effect
in terms of controlling the flow within the code will be identical to
placing - true - directly in that context

Richard.

[Touffy]

On 2006-10-03 16:31:10 +0200, "Richard Cornford"
<Ri*****@litote s.demon.co.uksa id:

Touffy wrote:

>Richard Cornford said:

>>(typeof (x = 'string')) //which is inevitably boolean true
// if used in an - if - expression.

and this behavior is not altered by and enclosing if().
So the type of (x = 'string') happens to be the value itself, 'string'.

In an - if - statement the value of the expression (string in this
case, as typeof operations always evaluate as strings) is internally
type-converted to boolean in order to determine how the - if -
expression will act. The - typeof - operator always returns non-empty
strings, and non-empty strings type-convert to boolean true. So if the
construct is placed in the expression of an - if - statement the effect
in terms of controlling the flow within the code will be identical to
placing - true - directly in that context

Exactly. The effect of if(typeof (whatever)) is the same as if(true).
Because Boolean(typeof whatever)==true .
However, the mere presence of an if statement does not make (typeof
whatever)===tru e, as your comment suggested.

--
David Junger

[Richard Cornford]

Touffy wrote:

Richard Cornford said:

Touffy wrote:

>>Richard Cornford said:
(typeof (x = 'string')) //which is inevitably boolean true
// if used in an - if - expression.

and this behavior is not altered by and enclosing if().
So the type of (x = 'string') happens to be the value itself, 'string'.

In an - if - statement the value of the expression (string in this
case, as typeof operations always evaluate as strings) is internally
type-converted to boolean in order to determine how the - if -
expression will act. ...

<snip>

Exactly. The effect of if(typeof (whatever)) is the same as if(true).
Because Boolean(typeof whatever)==true .
However, the mere presence of an if statement does not make (typeof
whatever)===tru e, as your comment suggested.

The mere presence of the expression in question in the expression of an
- if - statement means that its evaluated result _will_ be internally
type-converted to boolean, and the result of that type-conversion
_will_ be true.

Richard.

[Touffy]

On 2006-10-03 19:46:14 +0200, "Richard Cornford"
<Ri*****@litote s.demon.co.uksa id:

Touffy wrote:

>Exactly. The effect of if(typeof (whatever)) is the same as if(true).
Because Boolean(typeof whatever)==true .
However, the mere presence of an if statement does not make (typeof
whatever)===tr ue, as your comment suggested.

The mere presence of the expression in question in the expression of an
- if - statement means that its evaluated result _will_ be internally
type-converted to boolean, and the result of that type-conversion
_will_ be true.

Well, that's not exactly true, is it ? Mere presence in an if() will
not convert the expression (x = 'string'), so why does (typeof (x =
'string')) get converted ? An expression will be converted to a Boolean
by an if() if and only if it's the outermost expression.
I wasn't disputing that, anyway.

*sigh*... it could go on for a while, even without someone making mistakes.

I disagreed (still do) with the most litteral meaning of your earlier comment:

>>>>(typeof (x = 'string')) //which is inevitably boolean true
// if used in an - if - expression.

, not (most of (see above)) what you've said afterwards. The comment
could mean that in some conditions, the following expression becomes
true:

"(typeof (x = 'string')) is inevitably the boolean true"

which translates in pure JavaScript to:

(typeof (x = 'string')) === true

and that's never true, right ?

Since you like precise wording, well, I found it disturbing that you
would write such an ambiguous comment. Don't get me wrong, I like
precise wording too.
--
David Junger

[Dr John Stockton]

JRS: In article <11************ **********@i42g 2000cwa.googleg roups.com>,
dated Tue, 3 Oct 2006 06:58:06 remote, seen in
news:comp.lang. javascript, Richard Cornford
<Ri*****@litote s.demon.co.ukpo sted :

"if (5 == x)" just seems so backwards to me.

Writing the comparison this way around avoids the common error where
and assignment operator is used in place of a comparisons operator.

But those who write it backwards in order not to make the error of using
an assignment instead of a comparison will know that they must write ==
not just = and so don't need to write it backwards.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.