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

F

F. Da Costa

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.open || segmentRows.open=='true') doWhatever();

When running this if statement (made sure that above <tr> is contained in segmentRows) 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.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
 
E

Evertjan.

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.open || segmentRows.open=='true') doWhatever();
Click to expand...


<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 seperately
 
M

Martin Honnen

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

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

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.open || segmentRows.open=='true') doWhatever();

When running this if statement (made sure that above <tr> is contained
in segmentRows) Gecko processes this properly.
Click to expand...


Ok, with Mozilla the first condition
segmentRows.open
yields undefined, is converted to a boolean which yields false so the
second condition
segmentRows.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.open
evaluates to false and subsequently does *not* have any trouble entering
the if statement.
Click to expand...


With IE the first condition
segmentRows.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.
 
F

F. Da Costa

Evertjan. said:
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.open || segmentRows.open=='true') doWhatever();
Click to expand...



<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'");
Click to expand...

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 seperately
Click to expand...

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

F. Da Costa

Martin said:
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.
Click to expand...
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.open || segmentRows.open=='true') doWhatever();

When running this if statement (made sure that above <tr> is contained
in segmentRows) Gecko processes this properly.
Click to expand...



Ok, with Mozilla the first condition
segmentRows.open
yields undefined, is converted to a boolean which yields false so the
second condition
segmentRows.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.open evaluates to false and subsequently does *not*
have any trouble entering the if statement.
Click to expand...



With IE the first condition
segmentRows.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.
Click to expand...
 
D

Douglas Crockford

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.open || segmentRows.open=='true') doWhatever();

When running this if statement (made sure that above <tr> is contained in
Click to expand...

segmentRows) 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.open
Click to expand...

evaluates to false and subsequently does *not*
have any trouble entering the if statement.
Click to expand...

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

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

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)) {...}
 
P

Paul Cooper

False is false and true is true everywhere (God thanks!).
Click to expand...

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

Paul
 
T

Thomas 'PointedEars' Lahn

F. Da Costa said:
[...]
So basically I do not have to supply the attribute in the HTML doc.
Click to expand...

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?
Click to expand...

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

Jim Ley

F. Da Costa said:
<tr id="1" class="segment" open="false">
Click to expand...

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

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.
Click to expand...

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

Thomas 'PointedEars' Lahn

Jim said:
Thomas said:
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.
Click to expand...

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.
Click to expand...

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
 
D

Douglas Crockford

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):
Click to expand...

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>
 
T

Thomas 'PointedEars' Lahn

Douglas said:
Hold it there, little buddy. That's just wacko revisionism.
Click to expand...

It is not.
HTML is a lot older than those DTDs.
True.

For the record, an HTML document is any document with <html> tags.
Click to expand...

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.
Click to expand...

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
 
J

Jim Ley

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.).
Click to expand...

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.
Click to expand...

Afraid it is.
For adding elements and attributes to the language,
there is Extensible HTML (XHTML):

http://www.w3.org/TR/xhtml1/introduction.html
Click to expand...

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

Jim Ley

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)
| [...]
Click to expand...

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.
Click to expand...

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

John G Harris

,-<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.).
Click to expand...

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.


For adding elements and attributes to the language,
there is Extensible HTML (XHTML):

http://www.w3.org/TR/xhtml1/introduction.html
Click to expand...

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

John
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

How to return boolean true and false 3
When draggable=false & draggable=true dont work ? 1
[DOM related] IE vs. Gecko 1
Conditional Compilation: add to Gecko 5
Subtle difference between boolean value and boolean comparison? 7
Variable won't evaluate correctly in Javascript 4
Bool inside switch 1
Arithmetic with Boolean values 15

Members online

Total: 119 (members: 1, guests: 118)
Robots: 119

Forum statistics

Threads
474,077
Messages
2,570,567
Members
47,204
Latest member
abhinav72673

Latest Threads

Top