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

Firefox inserts text nodes in TR elements?

P: n/a

Why does Firefox insert #text nodes as children of TR elements?

As a work-around for older Safari versions not properly supporting a
table row's cells collection, I used the row's childNodes collection as
it was pretty much exactly the same thing. However, in Firefox 1.0.7
text nodes are inserted between the TDs. I'm certain that this didn't
use to happen with older versions.

The HTML specification states that the only element that can be the
child of a TR is a TD, so why does Firefox put text nodes in there?

If this how the DOM is supposed to be built, can someone give me a
reference to where it states that? Or should this be reported as a
Firefox bug?

--
Rob
Sep 23 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
ASM
RobG a écrit :

Why does Firefox insert #text nodes as children of TR elements?
I would be glad to see your example (url?)
for my
- own tests
- own knowledge
As a work-around for older Safari versions not properly supporting a
table row's cells collection, I used the row's childNodes collection as
it was pretty much exactly the same thing. However, in Firefox 1.0.7
text nodes are inserted between the TDs. I'm certain that this didn't
use to happen with older versions.

The HTML specification states that the only element that can be the
child of a TR is a TD, so why does Firefox put text nodes in there?
As I know you didn't do errors, strange it is
If this how the DOM is supposed to be built, can someone give me a
reference to where it states that? Or should this be reported as a
Firefox bug?


--
Stephane Moriaux et son [moins] vieux Mac
Sep 23 '05 #2

P: n/a

RobG wrote:
Why does Firefox insert #text nodes as children of TR elements?
Because they are in the source e.g. if you have
<tr><td>Kibo</td></tr>
then there are no white space text nodes as child nodes of the <tr>
element but as people usually author
<tr>
<td>Kibo</td>
</tr>
if you build a (normalized) DOM then the first child of the <tr> element
is a text node with white space, the second the <td> element, and the
third a text node with white space.
However, in Firefox 1.0.7
text nodes are inserted between the TDs. I'm certain that this didn't
use to happen with older versions.
I rather doubt that, I don't think such behaviour has changed between
1.0.x releases. I haven't tested now but I don't think the beahvior is
much different in earlier Mozilla releases.

The HTML specification states that the only element that can be the
child of a TR is a TD, so why does Firefox put text nodes in there?
Well the browser's tag soup parser does not look at a DTD so even if you
author your HTML to a HTML 4.01 DTD and declare that at the beginning of
the document the browser does not check whether your markup complies
with that DTD and throws out stuff that is not supposed to be in there
when building a DOM.
If this how the DOM is supposed to be built, can someone give me a
reference to where it states that?


White space and whether it or when it should occur in the DOM tree is an
underspecified issue I think, anyone picturing the tree usually ignores
that.
The current W3C DOM FAQ has this entry
<http://www.w3.org/DOM/faq.html#emptytext> on the issue:

"In XML, all whitespace has to be passed through to the application.
This means that if you have whitespace, such as carriage returns,
between tags in your source file, these have to be passed through, even
if they're just there for pretty-printing. The DOM implementation has to
put this whitespace somewhere, and the only possibility is a text node.
Thus you will get text nodes which look empty, but in fact have a
carriage return or other whitespace in them."

But then it adds: "Note that some DOM implementations, which do not
consider whitespace in element content to be meaningful for the XML
languages they support, discard these whitespace nodes before exposing
the DOM to their users."

So that FAQ acknowledges that implementations differ and that means you
have to deal with the differences if you write code against the
different implementations.
The latest core DOM Level 3 in its introduction pictures an example tree
for a table in
<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/introduction.html>
and does not show white space text nodes but mentions in the text before
the graphics:
"A graphical representation of the DOM of the example table, with
whitespaces in element content (often abusively called "ignorable
whitespace") removed"
In the end if you script against different implementations then my
experience is that if you walk childNodes or use firstChild or lastChild
then you should never expect a certain type of node (e.g. an element
node) at a particular position as what is an element node in one
implementation might be a text node in another. Checking nodeType and
then dealing with the type found is a safer way.
--

Martin Honnen
http://JavaScript.FAQTs.com/
Sep 23 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.