typeof.currentElement.innerText not working in Firefox?

[effendi]

I am testting the following code in firefox

function fDHTMLPopulateFields(displayValuesArray, displayOrderArray)
{
var i,
currentElement,
displayFieldID,
currentChild,
nDisplayValues = displayValuesArray.length;
for (i=0; i<nDisplayValues; i++) {
displayFieldID = "div_" + displayOrderArray + "ID";
currentElement = (document.getElementById
&& document.getElementById(displayFieldID))
|| (document.all
&& document.all(displayFieldID));
if (typeof currentElement == "object") {
if (typeof currentElement.innerText != "undefined") {
currentElement.innerText = displayValuesArray;
}
else if (
currentElement.firstChild
&& currentElement.removeChild
&& currentElement.appendChild
&& document.createTextNode
) {
while ((currentChild = currentElement.firstChild)) {
currentElement.removeChild(currentChild);
}
currentElement.appendChild(
document.createTextNode(displayValuesArray)
);
}
}
}
}

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]

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.replace(/<[^>]*>/g,'');
}

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

 

[Trond Michelsen]

function getText(el)
{
if ('string' == typeof el.textContent) return el.textContent;
if ('string' == typeof el.innerText) return el.innerText;
return el.innerHTML.replace(/<[^>]*>/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.

 

[Richard Cornford]

function getText(el)
{
if ('string' == typeof el.textContent) return el.textContent;
if ('string' == typeof el.innerText) return el.innerText;
return el.innerHTML.replace(/<[^>]*>/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]

(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'.

 

[Richard Cornford]

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]

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)===true, as your comment suggested.

 

[Richard Cornford]

Richard Cornford said:

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)===true, 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.

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Tue, 3 Oct 2006 02:33:56 remote, seen in

innerText is a proprietary IE property, the W3C equivalent (supported
by Firefox) is textContent.

Would that justify a modification to FAQ 4.15, if the FAQ were being
updated?

 

[Touffy]

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:

, 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.

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Tue, 3 Oct 2006 06:58:06 remote, seen in
Richard Cornford

"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.

 

[Richard Cornford]

Richard Cornford said:

Well, that's not exactly true, is it ?

It is true. The - if - expression must result in a boolean decision
regardless of the type/value of the result of the expression. That is
achieved by type-converting non-boolean values to boolean, using the
usual type-conversion rules.

Mere presence in an if() will
not convert the expression (x = 'string'),

Yes it will, if you use - (x = 'string') - as the expression for an -
if - statement the resulting value has to be type-converted to boolean if
the - if - statement is to work at all.

so why does (typeof (x = 'string')) get converted ?

Because all values resulting from expressions used in an - if -
expression are passed through the internal ToBoolean function, which will
type-convert non-boolean values to boolean.

An expression will be converted to a Boolean
by an if() if and only if it's the outermost expression.

"If and only if its outermost expression" what?

I wasn't disputing that, anyway.

What weren't you disputing.

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

Ironic? ;-)

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

The truness of non-empty strings is a fact of life in javascript, and is
manifest in - if - expressions.

, 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"

And the expression does become boolean true, internally in the process of
determining how the - if - statement will act.

which translates in pure JavaScript to:

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

No it doesn't. The - if - expression uses the internal ToBoolean
function, so it is the type-converted truness that is significant.

and that's never true, right ?

That the evaluated value of the expression - (typeof (x = 'string')) -
would be boolean true was never true (it is always a non-empty string).
It was however always true that the resulting value would be such that
when the - if - expression's value is type-converted to boolean in order
to determine the - if - statement behaviour the result of that
type-conversion will always be boolean true.

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.

If it was ambiguous why were you arguing that it was false?

Richard.

 

[Touffy]

"If and only if its outermost expression" what?

An expression is usually made of several expressions. In the case we
were discussing, (x = 'string') is part of a larger expression, but
it's an expression itself.
The expression (x = 'string') is present in the if(), right ?
Yet it is not converted to a Boolean.
That's what I meant by "only the outermost expression".

What weren't you disputing.

I don't know... oh yes. I wasn't disputing the use of semicolons after
every instruction in JavaScript, for example. Don't start me on that
subject

Ironic? ;-)

half ironic. As usual.

The truness of non-empty strings is a fact of life in javascript, and is
manifest in - if - expressions.

Non-empty strings are true if true is an adjective, meaning that
non-empty strings have a property (not a JavaScript property, I'm just
speaking English) "truth" or "truness" or whatever, which indicates
they convert to the boolean true.
But they are not the Boolean true, not even equivalent unless their
value is "1" (or some other form of the number 1) or "true". They only
convert to true, and they don't have much choice since booleans have
only 2 values.

It's the same for NaN. Every value that can't be converted to Number is
obviously not a number (ie does not belong to the numbers category),
but they are not the number NaN itself. They are... well, themselves.
0/0 is NaN. 'string' is not NaN.

When you say "'string', which is inevitably the boolean true", you
clearly define true as an object, not an adjective.

To me (and not just me, otherwise I'd just download the latest language
update for my brain and adopt the universal standard), "object A is
object B" means "A===B". Either we differ in this, or it was
metaphorical ("'string' is true"... hmmm... what did he mean by that
?), or you implied "after conversion to Boolean" and I must point out
that if someone was unlucky enough to read it but not the following
conversation, they might, as I did, not get it right.

And the expression does become boolean true, internally in the process of
determining how the - if - statement will act.

The expression returns a string value. That value is not the boolean
true. As you said, it becomes true. It becomes something else. Through
a conversion operation. The if() statement may not care about the
original string value, but I do. Well, not really, but I know it exists.

No it doesn't. The - if - expression uses the internal ToBoolean
function, so it is the type-converted truness that is significant.

That doesn't make (typeof (x = 'string'))===true.
As insignificant as it may be.
I can only agree to this:
Boolean(typeof (x = 'string'))===true
or this:
((typeof (x = 'string')) ? a:b)===(true ? a:b)

If it was ambiguous why were you arguing that it was false?

As I said, you could have implied more than you wrote, or used "is"
metaphorically. Even if you haven't, people don't know what you thought
when you wrote it, so they are free to guess that you couldn't possibly
have said something seemingly false about such a simple JavaScript
matter, and that you surely implied more. However it happens, it would
give your comment a second meaning, in addition to the litteral
incorrect one. Thus the statement would become ambiguous. The litteral
meaning is the strongest, and it's false by my definition of "A is B",
and it's the one I'm arguing about.

 

[Richard Cornford]

Richard Cornford said:

An expression is usually made of several expressions. In the case
we were discussing, (x = 'string') is part of a larger expression,

The case we were discussing is the larger expression; the expression
used as the expression in an - if - statement.

but it's an expression itself.

Expressions may be constructed from other expression. The production
for the expression in an - if - statement is not more specific than
requiring an Expression.

The expression (x = 'string') is present in the if(), right ?

It is part of the - if - statement's Expression.

Yet it is not converted to a Boolean.

No, as I have now said many times; it is the resolved value of
Expression for the - if - statement that is type-converted to boolean.

That's what I meant by "only the outermost expression".
OK.

When you say "'string', which is inevitably the boolean true", you
clearly define true as an object, not an adjective.

So you are disputing the most literal meaning of half a sentence?

To me (and not just me, otherwise I'd just download the latest
language update for my brain and adopt the universal standard),
"object A is object B" means "A===B".

<snip>

And with the sentence "a seed is inevitably a plaint if allowed to
grow" is it reasonable to complain that a seed is not a plant?

Richard.

 

[Touffy]

Richard Cornford said:

And with the sentence "a seed is inevitably a plaint if allowed to
grow" is it reasonable to complain that a seed is not a plant?

That sentence abuses "is" in the same way.
If a seed needs to grow to become a plant, then indeed it's not a plant yet.
I'm not saying you will never hear that sentence, but when you hear it,
your brain does some amazingly complex error correction (from a
computer's point of view) to extract meaning from it. Thought follows
many paths, but one of them could be:
"if allowed to" "grow" -> "growing" takes time, water, minerals... ->
"a seed is a plant" should be interpreted if and when the condition
(growth) and all it implies has happened -> if the conditions are not
met (yet), "a seed is a plant" may not be interpreted correctly, else
why would you include a condition in the sentence?

 

[Richard Cornford]

Richard Cornford said:


That sentence abuses "is" in the same way.
If a seed needs to grow to become a plant, then indeed it's not a plant yet.
I'm not saying you will never hear that sentence, but when you hear it,
your brain does some amazingly complex error correction (from a
computer's point of view) to extract meaning from it. Thought follows
many paths, but one of them could be:
"if allowed to" "grow" -> "growing" takes time, water, minerals... ->
"a seed is a plant" should be interpreted if and when the condition
(growth) and all it implies has happened -> if the conditions are not
met (yet), ...

<snip>

So the statement is correct if the conditions in the qualification have
been applied. What else would the qualification be there for?

Richard.

 

[Touffy]

Richard Cornford said:

So the statement is correct if the conditions in the qualification have
been applied. What else would the qualification be there for?

The statement is not correct in any circumstance. But, if you
instantiate the seed (take an individual seed instead of the category),
the instantiated version might become true.

suppose we place our seed inside variable A

"a seed is a plant" is false
"A is a plant" is false

Now we water variable A, put it in the Sun (that would mean plant
growth is programmed in JAVA, eh ? )

When the seed is grown,

"a seed is a plant" remains false
but "A is a plant" is now true

A is the same reference as before, but if you compared its contents
with the contents it held at first, they would not be the same.
Therefore the seed A is not the plant A.
(we're still talking about JavaScript... are we ?)
If you wanted to make "a seed is a plant" become true, you'd have to
redefine the plant category to encompass seeds, or redefine the seed
category to comply with the plant definition.

 

[Richard Cornford]

Richard Cornford said:


The statement is not correct in any circumstance. But,
if you instantiate the seed (take an individual seed
instead of the category), the instantiated version might
become true.

There is no need to worry about individual seeds. It is the general
nature of seeds that when they grow they become plants. If they became
rocks, fish, fungi or tunnels when they grew they would not have been
seeds to start with.

suppose we place our seed inside variable A

"a seed is a plant" is false
"A is a plant" is false

Now we water variable A, put it in the Sun (that would
mean plant growth is programmed in JAVA, eh ? )

When the seed is grown,

"a seed is a plant" remains false
but "A is a plant" is now true

If a seed grows it is inevitable that the outcome would be a plan.

A is the same reference as before, but if you compared
its contents with the contents it held at first, they
would not be the same.
Therefore the seed A is not the plant A.

But seed A transformed by growth is plaint A.

(we're still talking about JavaScript... are we ?)

What you are doing is quibbling about the literal meaning of a fragment
of a sentence.

In javascript terms we know that the expression used in an - if -
statement will be type-converted to boolean in order to determine how
the - if - statement will behave, we know that non-empty strings will
type-convert to boolean true, and we know that the evaluated result of
a - typeof - expression is a non-empty string. Thus we know that -
(typeof (x = 'string)) -, when used as the Expression in an - if -
statement, will be type-converted to boolean by virtue of the context of
its use, and that the outcome of that type-conversion will be boolean
true because of the nature of the value it evaluates as.

If you wanted to make "a seed is a plant" become true,

I don't want to make "a seed is a plant" become true, as it is not. I
have no desire to insist that all fragments of true sentences be true in
isolation, nor any expectation that such could be achieved.

you'd have to redefine the plant category to encompass
seeds, or redefine the seed category to comply with the
plant definition.

The 'seeds' category is such that when grown the results are plants. The
statement "a seed is inevitably a plaint if allowed to grow" does no more
than express that.

Richard.

 

[VK]

(typeof (x = 'string')) //which is inevitably boolean true

Look what coding in C has done to you

In JavaScript, an assignment operation returns the assigned value, not
true of false.

I don't see what the problem is: that is totally correct in application
to JavaScript, where a Perl-like simplified schema for conditional
checks is used: empty string, 0, undefined, null == false, anything
else == true. The words "...if used in an - if - expression" exclude
any ambigousity in the statement.

The statement is wrong for another reason: typeof operator has much
higher precedence than the assignment operator, so typeof x is always
executed first. But: typeof is not allowed to be in the left-hand of
assignment (because you are not allowed to change type information of
objects, it's ReadOnly).

This way a typo like:
if (typeof x = 'undefined')
will lead to a *syntax error* (so you script will not be executed at
all, so any try-catch blocks are useless), and a typo like
if ('undefined' = x)
will lead to a *run-time error* "cannor assign to string".

I do personally agree with another poster that semantically (typeof x
== 'undefined') is more natural than ('undefined' == typeof x).

Yet after a few hard lesson cases I prefer to use the latter form
(though do not call it at all as "required", "proper" or anything like
that).

 

[RobG]

I don't see what the problem is: that is totally correct in application
to JavaScript, where a Perl-like simplified schema for conditional
checks is used: empty string, 0, undefined, null == false, anything
else == true. The words "...if used in an - if - expression" exclude
any ambigousity in the statement.

The statement is wrong for another reason: typeof operator has much
higher precedence than the assignment operator, so typeof x is always
executed first. But: typeof is not allowed to be in the left-hand of
assignment (because you are not allowed to change type information of
objects, it's ReadOnly).

This way a typo like:
if (typeof x = 'undefined')
will lead to a *syntax error* (so you script will not be executed at
all, so any try-catch blocks are useless), and a typo like
if ('undefined' = x)
will lead to a *run-time error* "cannor assign to string".

I do personally agree with another poster that semantically (typeof x
== 'undefined') is more natural than ('undefined' == typeof x).

Yet after a few hard lesson cases I prefer to use the latter form
(though do not call it at all as "required", "proper" or anything like
that).

If the LHS is a variable, e.g.

var y = 'string'; // or the result of some function

then:

if ( y = typeof x )

will always be true. So maybe for typeof tests it is always better to
put typeof on the left because:

if (typeof x = ... )

will always give a syntax error regardless of what is on the other side
of the assignment operator, but the reverse is not the case.