By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,636 Members | 1,213 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,636 IT Pros & Developers. It's quick & easy.

[boolean: IE & Gecko] IE treats false as true?

P: n/a
Hi all,

Following two sniperts of code I'm using and getting very interesting results from.

..html
<tr id="1" class="segment" open="false">

This is the segment under 'investigation'

..js
if (segmentRows[i].open || segmentRows[i].open=='true') doWhatever();

When running this if statement (made sure that above <tr> is contained in segmentRows[i]) Gecko processes this properly.
As in it *does not* enter the if.
IE 5+ on the other hand alerts (as in debug) me that segmentRows[i].open evaluates to false and subsequently does *not*
have any trouble entering the if statement.

I know this sounds strange but it *is* actually taking place.
Once again this exact same code is *processed correctly by Gecko*.

Is this a known thing, should I not rely on boolean stuff or ...?

Any suggestions are appreciated.

TIA
Fermin DCG
Jul 20 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
F. Da Costa wrote on 08 dec 2003 in comp.lang.javascript:
Hi all,

Following two sniperts of code I'm using and getting very interesting
results from.

.html
<tr id="1" class="segment" open="false">

This is the segment under 'investigation'

.js
if (segmentRows[i].open || segmentRows[i].open=='true') doWhatever();


<div id="t1" open=false>
This is the segment under 'investigation'
</div>

<script>
z=document.getElementById("t1");
alert(z.open);

if (z.open)
alert("exists")
else
alert("does not exist");

if (z.open!=false)
alert("boolean value is not 'false'")
else
alert("boolean value is 'false'");

if(z.open!="false")
alert("string value is not 'false'")
else
alert("string value is 'false'");
</script>

I suggest that you test the segmentRows[i] seperately

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jul 20 '05 #2

P: n/a


F. Da Costa wrote:
Following two sniperts of code I'm using and getting very interesting
results from.

.html
<tr id="1" class="segment" open="false">
In which HTML version do you find the attribute named open for <tr>
elements?
Is the any browser having an object model for <tr> element objects where
a property named open exists? If so what does the object model tell
about the type of the property?

What you have done is added your own attribute named open to a HTML <tr>
element. Whether that attribute is reflected in the DOM as a property
depends on the browser, IE/Win at least is known to add a property,
Mozilla is known not to do that. So with IE
trElement.open
has a value while with Mozilla
trElement.open
is undefined.

For instance try the following:

<html>
<head>
<title>custom attributes and scripting</title>
<script type="text/javascript">
function checkAttribute (element, attributeName) {
if (!element) {
return;
}
else {
var result = '';
var attributeValue = element.getAttribute(attributeName);
result += 'element.getAttribute("' + attributeName + '"): '
+ element.getAttribute(attributeName);
var propertyType = typeof element[attributeName];
result += '\n';
result += 'typeof element["' + attributeName + '"]: ' + (typeof
element[attributeName]);
alert(result);
}
}
window.onload = function (evt) {
if (document.getElementById) {
checkAttribute(document.getElementById('aP'), 'open');
}
};
</script>
</head>
<body>
<p id="aP" open="false">
paragraph
</p>
</body>
</html>

With IE6/Win you will see that the property named open is defined but of
type string so your subject line complaining about booleans simple
doesn't describe what is happening in the code.
With Mozilla you will seee that the property named open is undefined so
all your attempts to access elementVariable.open simply yield undefined
in Mozilla and again what is happening in code has nothing to do with
boolean values.
With Opera 7 you will also find that the property is undefined.
Thus if you use custom attributes and want to do cross-browser scripting
then
element.attributename
doesn't help, use
element.getAttribute('attributename')
instead and be aware that that always returns a string value.

This is the segment under 'investigation'

.js
if (segmentRows[i].open || segmentRows[i].open=='true') doWhatever();

When running this if statement (made sure that above <tr> is contained
in segmentRows[i]) Gecko processes this properly.
Ok, with Mozilla the first condition
segmentRows[i].open
yields undefined, is converted to a boolean which yields false so the
second condition
segmentRows[i].open=='true'
is evaluated
'undefined' == 'true
is false so the whole condition is false.
As in it *does not* enter the if.
IE 5+ on the other hand alerts (as in debug) me that segmentRows[i].open
evaluates to false and subsequently does *not* have any trouble entering
the if statement.


With IE the first condition
segmentRows[i].open
yields 'false', that is converted to a boolean value and any non empty
string yields the boolean value true so the whole or condition is true.

Not what you want to happen but perfectly correct.

Custom attributes are questionable but if you use them then learn how to
script them.
--

Martin Honnen
http://JavaScript.FAQTs.com/

Jul 20 '05 #3

P: n/a
Evertjan. wrote:
F. Da Costa wrote on 08 dec 2003 in comp.lang.javascript:

Hi all,

Following two sniperts of code I'm using and getting very interesting
results from.

.html
<tr id="1" class="segment" open="false">

This is the segment under 'investigation'

.js
if (segmentRows[i].open || segmentRows[i].open=='true') doWhatever();
<div id="t1" open=false>
This is the segment under 'investigation'
</div>

<script>
z=document.getElementById("t1");
alert(z.open);

if (z.open)
alert("exists")
else
alert("does not exist");

if (z.open!=false)
alert("boolean value is not 'false'")
else
alert("boolean value is 'false'");

changed line above to
if (z.open==false) alert("boolean value is 'false'")
else alert("boolean value is NOT 'false'");

if(z.open!="false")
alert("string value is not 'false'")
else
alert("string value is 'false'");
</script>

I suggest that you test the segmentRows[i] seperately

Tested your snip on IE 5+ (with the modded line) and got the following output:
false - exists - *boolean value is NOT 'false'* - string value is 'false'
As you can see the third result is *not* what one would expect.
Gecko got me:
undefined - does not exist - *boolean value is NOT 'false'* - string value is not 'false'
I am a bit surprised about the non-existence nature but otherwise one can argue this is all correct.

Did you test in some other way because I still don't get the z.open==false *not* ending up in the then instead of the else.

Jul 20 '05 #4

P: n/a
Martin Honnen wrote:


F. Da Costa wrote:
Following two sniperts of code I'm using and getting very interesting
results from.

.html
<tr id="1" class="segment" open="false">

In which HTML version do you find the attribute named open for <tr>
elements?
Is the any browser having an object model for <tr> element objects where
a property named open exists? If so what does the object model tell
about the type of the property?

What you have done is added your own attribute named open to a HTML <tr>
element. Whether that attribute is reflected in the DOM as a property
depends on the browser, IE/Win at least is known to add a property,
Mozilla is known not to do that. So with IE
trElement.open
has a value while with Mozilla
trElement.open
is undefined.

This is *exactly* what is happening.
So basically I do not have to supply the attribute in the HTML doc.
If and when required I can add it to the DOM model instead and use it from thereon?

It would explain what is happening to the code.
Never too late to learn.

Thx for the effort and the insight given
For instance try the following:

<html>
<head>
<title>custom attributes and scripting</title>
<script type="text/javascript">
function checkAttribute (element, attributeName) {
if (!element) {
return;
}
else {
var result = '';
var attributeValue = element.getAttribute(attributeName);
result += 'element.getAttribute("' + attributeName + '"): '
+ element.getAttribute(attributeName);
var propertyType = typeof element[attributeName];
result += '\n';
result += 'typeof element["' + attributeName + '"]: ' + (typeof
element[attributeName]);
alert(result);
}
}
window.onload = function (evt) {
if (document.getElementById) {
checkAttribute(document.getElementById('aP'), 'open');
}
};
</script>
</head>
<body>
<p id="aP" open="false">
paragraph
</p>
</body>
</html>

With IE6/Win you will see that the property named open is defined but of
type string so your subject line complaining about booleans simple
doesn't describe what is happening in the code.
With Mozilla you will seee that the property named open is undefined so
all your attempts to access elementVariable.open simply yield undefined
in Mozilla and again what is happening in code has nothing to do with
boolean values.
With Opera 7 you will also find that the property is undefined.
Thus if you use custom attributes and want to do cross-browser scripting
then
element.attributename
doesn't help, use
element.getAttribute('attributename')
instead and be aware that that always returns a string value.

This is the segment under 'investigation'

.js
if (segmentRows[i].open || segmentRows[i].open=='true') doWhatever();

When running this if statement (made sure that above <tr> is contained
in segmentRows[i]) Gecko processes this properly.

Ok, with Mozilla the first condition
segmentRows[i].open
yields undefined, is converted to a boolean which yields false so the
second condition
segmentRows[i].open=='true'
is evaluated
'undefined' == 'true
is false so the whole condition is false.
As in it *does not* enter the if.
IE 5+ on the other hand alerts (as in debug) me that
segmentRows[i].open evaluates to false and subsequently does *not*
have any trouble entering the if statement.

With IE the first condition
segmentRows[i].open
yields 'false', that is converted to a boolean value and any non empty
string yields the boolean value true so the whole or condition is true.

Not what you want to happen but perfectly correct.

Custom attributes are questionable but if you use them then learn how to
script them.

Jul 20 '05 #5

P: n/a
> Following two sniperts of code I'm using and getting very interesting results
from.

.html
<tr id="1" class="segment" open="false">

This is the segment under 'investigation'

.js
if (segmentRows[i].open || segmentRows[i].open=='true') doWhatever();

When running this if statement (made sure that above <tr> is contained in segmentRows[i]) Gecko processes this properly. As in it *does not* enter the if.
IE 5+ on the other hand alerts (as in debug) me that segmentRows[i].open evaluates to false and subsequently does *not* have any trouble entering the if statement.


There is a difference between false and "false". One is a boolean and the other
is a string. The DOM is returning a string for segmentRows[i].open.

http://www.crockford.com/#javascript

Jul 20 '05 #6

P: n/a
VK
False is false and true is true everywhere (God thanks!).
Your problems relies on how different browsers let you extend the object
model, and how they caste non-boolean values to boolean ones.

IE allows you to add extra properties simply by putting new attributes
inside the tag.
NN goes strict by 3W, thus all non-listed tag and attributes are ignored
(unless you declared them using XML namespaces). Thus after processing
<td id="c1" open="false">
in IE c1.open = false, in NN c1.open = undefined (null)

After that (c1.open) gives false in IE (and it would still give you
false even with c1.open equals null, because in boolean operations IE
casts null to false)
In NN (c1.open) gives you undefined (null), because for NN null is not
true or false, it's null, and that's end of it.

Coming back to your example, the right syntax would to avoid casting at
all (which makes you dependent on particular casting mechanics), and use
explicit boolean operations instead:
if ((obj.property != null)&&(obj.property == value)) {...}

Jul 20 '05 #7

P: n/a
On Mon, 8 Dec 2003 17:21:15 +0100, "VK" <sc**********@yahoo.com>
wrote:
False is false and true is true everywhere (God thanks!).


Philosophy even! Pontius Pilate asked Jesus "What is truth?" and I
think it is still a matter of debate in some circles ;-)

Paul
Jul 20 '05 #8

P: n/a
F. Da Costa wrote:
<tr id="1" class="segment" open="false">

[...]
So basically I do not have to supply the attribute in the HTML doc.


You *must* *not* supply the attribute, otherwise you
get invalid HTML and thus no HTML at all, only some
tag soup that looks like HTML.
If and when required I can add it to the DOM model instead and use
it from thereon?


If the DOM of the UA supports that, you add a property
to a DOM object (as with any other JavaScript object),
not an attribute to an HTML element.
PointedEars

P.S.: Please trim your quotes to the absolute necessary.
Jul 20 '05 #9

P: n/a
On Tue, 09 Dec 2003 00:21:06 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
F. Da Costa wrote:
<tr id="1" class="segment" open="false">


[...]
So basically I do not have to supply the attribute in the HTML doc.


You *must* *not* supply the attribute, otherwise you
get invalid HTML and thus no HTML at all, only some
tag soup that looks like HTML.


HTML is an application of SGML, it's perfectly possible to add
attributes in the internal subset that would make it valid. Or to use
a dtd with the attribute defined.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #10

P: n/a
Jim Ley wrote:
Thomas 'PointedEars' Lahn wrote:
You *must* *not* supply the [`open'] attribute, otherwise you
get invalid HTML and thus no HTML at all, only some
tag soup that looks like HTML.


HTML is an application of SGML, it's perfectly possible to add
attributes in the internal subset that would make it valid.
Or to use a dtd with the attribute defined.


Wrong.

,-<http://www.w3.org/TR/html4/appendix/notes.html#h-B.1
|
| B.1 Notes on invalid documents
| [...]
| For reasons of interoperability, authors must not "extend" HTML
| through the available SGML mechanisms (e.g., extending the DTD,
| adding a new set of entity definitions, etc.).

Any document that either does not validate on one of the HTML-DTDs named
in the HTML specification or validates on other DTDs than those is *not*
an HTML document. For adding elements and attributes to the language,
there is Extensible HTML (XHTML):

http://www.w3.org/TR/xhtml1/introduction.html
PointedEars
Jul 20 '05 #11

P: n/a
> Any document that either does not validate on one of the HTML-DTDs named
in the HTML specification or validates on other DTDs than those is *not*
an HTML document. For adding elements and attributes to the language,
there is Extensible HTML (XHTML):


Hold it there, little buddy. That's just wacko revisionism. HTML is a lot older
than those DTDs. For the record, an HTML document is any document with <html>
tags. HTML was quite lenient in its tolerance of unrecognized tags and
attributes. That's true. <blink>Intolerance is a recent invention.</blink>

Jul 20 '05 #12

P: n/a
Douglas Crockford wrote:
Any document that either does not validate on one of the HTML-DTDs named
in the HTML specification or validates on other DTDs than those is *not*
an HTML document. For adding elements and attributes to the language,
there is Extensible HTML (XHTML):
Hold it there, little buddy. That's just wacko revisionism.


It is not.
HTML is a lot older than those DTDs.
True.
For the record, an HTML document is any document with <html> tags.
No. From the first specified version of HTML, HTML 2.0 (RFC 1866 of
November 1995, now obsolete), on (if not from the first version on),
(conforming) HTML documents have been defined as

,-<http://www.w3.org/MarkUp/html-spec/html-spec_1.html#SEC1.2>
|
| A document is a conforming HTML document if:
|
| * It is a conforming SGML document, and it conforms to the
| HTML DTD (see section HTML DTD). (1)
| [...]
HTML was quite lenient in its tolerance of unrecognized tags and
attributes.


No, user agents were and still are (IE is leading here which is _not_
a plus) using tagsoup parsers instead of strict SGML parsers which is
still a big problem for web authors and implementors of competitive
user agents today. HTML was designed by Tim Berners-Lee to be a
cross-platform language, proprietary (most of them presentational)
elements and attributes later added by Netscape, then by Microsoft
(part of the "arms race" in the "browser wars"), counteracted this.
With HTML 4, the issue was finally pushed in the right direction,
declaring most presentational elements and attributes deprecated.
PointedEars
Jul 20 '05 #13

P: n/a
On Wed, 10 Dec 2003 00:02:19 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
Jim Ley wrote:
,-<http://www.w3.org/TR/html4/appendix/notes.html#h-B.1
|
| B.1 Notes on invalid documents
| [...]
| For reasons of interoperability, authors must not "extend" HTML
| through the available SGML mechanisms (e.g., extending the DTD,
| adding a new set of entity definitions, etc.).
That's for HTML4 - HTML 4 documents cannot use internal subsets, HTML
3.2, or 2.0 or ISO etc. do not all have the same requirements,
equally text/html is defined much more lenienantly than HTML 4.0 -
otherwise HTML 2.0 or XHTML 1.0 would not be able to be served with
that mime-type.
Any document that either does not validate on one of the HTML-DTDs named
in the HTML specification or validates on other DTDs than those is *not*
an HTML document.
Afraid it is.
For adding elements and attributes to the language,
there is Extensible HTML (XHTML):

http://www.w3.org/TR/xhtml1/introduction.html


and XHTML 1.0 can be served as text/html, so you could extend that,
even if you were misguided enough to think you couldn't extend HTML.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #14

P: n/a
On Wed, 10 Dec 2003 11:58:56 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
Douglas Crockford wrote:
| A document is a conforming HTML document if:
|
| * It is a conforming SGML document, and it conforms to the
| HTML DTD (see section HTML DTD). (1)
| [...]
Which doesn't mention the internal subset...
No, user agents were and still are (IE is leading here which is _not_
a plus) using tagsoup parsers instead of strict SGML parsers which is
still a big problem for web authors and implementors of competitive
user agents today.


Have you read RFC 2854, have you read the ISO HTML DTD, HTML is a lot
broader church than you misguidedly seem to think.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #15

P: n/a
In article <3F**************@PointedEars.de>, Thomas 'PointedEars' Lahn
<Po*********@web.de> writes
<snip>

,-<http://www.w3.org/TR/html4/appendix/notes.html#h-B.1
|
| B.1 Notes on invalid documents
| [...]
| For reasons of interoperability, authors must not "extend" HTML
| through the available SGML mechanisms (e.g., extending the DTD,
| adding a new set of entity definitions, etc.).
You missed out a more relevant part of section B.1 :

* If a user agent encounters an attribute it does not recognize, it
should ignore the entire attribute specification (i.e., the
attribute and its value).

They don't want browsers to be upset by unrecognised attributes. On the
other hand, they aren't asking for them to appear in the browser's DOM.
<snip>For adding elements and attributes to the language,
there is Extensible HTML (XHTML):

http://www.w3.org/TR/xhtml1/introduction.html


XHTML isn't that extensible. You would need to use namespaces, and even
that is not part of strict XHTML 1.0.

John
--
John Harris
Jul 20 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.