javascript parentNode

A

anupamjain

An interesting thing is happening. My table doesnt have 'TBody', but
the elem.parentNode.tagName is returning 'TBody' where elem refers to
the 'tr' tag.

Shouldnt it be returning 'table' ?

<body>
<table>
<tr>
<td>1</td>
<td>2</td>
</tr>
<tr>
<td>3</td>
<td>4</td>
</tr>
</table>
</body>

Also, its adding html tag even if its not present in the document (if I
lookup parentNode of body). Is there a way to tell javascript not to be
intelligent? (because I am building an xpath and I want to extract the
exact xpath from the real-world-html-document)

Thanks,
Anupam
 
V

VK

An interesting thing is happening. My table doesnt have 'TBody', but
the elem.parentNode.tagName is returning 'TBody' where elem refers to
the 'tr' tag.

Shouldnt it be returning 'table' ?

The TBODY element is exposed for all tables, even if the table does not
explicitly define a TBODY element. (True for IE at least => 90% of
UA's)

Same for HTML (=> document.documentElement) It is actually an
obligatory element for HTML documents said:
Is there a way to tell javascript not to be
intelligent? (because I am building an xpath and I want to extract the
exact xpath from the real-world-html-document)

JavaScript has nothing to do with it. The "intelligence" is
demonstarated by browser DOM parser. You seem mixing two very different
issues here: i) the source HTML code representing a page and ii) DOM
tree built on the basis of this source code.

You can retrieve any HTML source by using say responseText from an
ajaxoid and study it line by line. Here it is not important how many
rude mistakes is made in the layout, because it is just plain text for
you.

But with xpath and DOM methods you are dealing with the parsing
*results*, and these results can be far away of what is written in the
code. More poorly written code -> more efforts UA needs to spend to
build some reasonnable DOM tree -> more this DOM tree may differ from
the one intended in the obscured author's mind.
From the other side without DOM tree ready you cannot work with it. So
for xpath you just have to drop the idea to study the source and
concentrate on source parsing results:- bearing in mind that these
results may differ significally from one browser to another.

An alternative solution would be only to write your very own HTML
parser and feed the source into it over responseText.

P.S. It is actually strange that you are worring about such small and
easy to fix issues. I would expect you being nocked by phantom nodes on
tags' borders in W3C-victimized browsers (cannot say "W3C-compliant" in
this particular case). Either you already solved it or did not noticed
yet.
 
J

Johannes Koch

An interesting thing is happening. My table doesnt have 'TBody', but
the elem.parentNode.tagName is returning 'TBody' where elem refers to
the 'tr' tag.

Shouldnt it be returning 'table' ?

<body>
<table>
<tr>
<td>1</td>
<td>2</td>
</tr>
<tr>
<td>3</td>
<td>4</td>
</tr>
</table>
</body>

As you posted to an XML group, I assume that the above is XHTML, not
HTML. In the case of HTML, the tbody element would be there implicitly,
even if you did not write it in your code. In the case of XHTML, it
would not be there.

In general: for HTML use HTML tools, for XHTML use XML tools.

If you have problems with HTML, post to an HTML group.
 
T

Thomas 'PointedEars' Lahn

VK said:
The TBODY element is exposed for all tables, even if the table does not
explicitly define a TBODY element. (True for IE at least => 90% of
UA's)

Your figures are wrong, and they do not matter.
[...] I would expect you being nocked by phantom nodes on tags' borders in
W3C-victimized browsers (cannot say "W3C-compliant" in this particular
case).

There are no phantom nodes. There are specified white-space text nodes.
Stop applying your fantasies on standardized and implemented reality.


PointedEars
 
P

Peter Flynn

Thomas said:
Your figures are wrong, and they do not matter.

Actually they matter quite a lot, but it is correct that TBODY is
optional but implied in HTML. The problem is that the DOM pretends
to mimic the requirements of an SGML parser.
[...] I would expect you being nocked by phantom nodes on tags' borders in
W3C-victimized browsers (cannot say "W3C-compliant" in this particular
case).

There are no phantom nodes. There are specified white-space text nodes.

The specification differs between SGML-style parsing and XML-style
parsing. XML has no phantom nodes but it does have disappearing nodes
in mixed content, which SGML only has in element content.

///Peter
 
V

VK

Thomas said:
There are no phantom nodes. There are specified white-space text nodes.
Stop applying your fantasies on standardized and implemented reality.

You should stop living in fantasies, not me and nor the developers
community. This question was studied rather deeply - there is not any
written standard for *pretty-print of source code affecting DOM tree*.
Just again a piece of W3C text written so poorly that you can read it
in several ways at once.
If you have your own valuable considerations, please post in the famous
bug #26179 at<https://bugzilla.mozilla.org/show_bug.cgi?id=26179>

P.S. This bug is being switched through the entire year from
VERIFIED-OPEN-MAJOR (by the community) to VERIFIED-CLOSED-INVALID (by
Mozilla) This game goes rather intensively so I cannot predict its
current status as of today.

P.P.S I do not participate in the "switch it" game - I'm just a reader
- and one of victimes of someone's non-rightified stuberness.
 
R

RobG

An interesting thing is happening. My table doesnt have 'TBody', but
the elem.parentNode.tagName is returning 'TBody' where elem refers to
the 'tr' tag.

You mean tr element.

Shouldnt it be returning 'table' ?

No. Most browsers, reading your markup, will assume HTML. In HTML, a tbody
element is mandatory in a table but the tags are optional. By omitting the
tags, you are allowing the browser to create tbody elements where it
considers appropriate.

<body>
<table>
<tr>
<td>1</td>
<td>2</td>
</tr>
<tr>
<td>3</td>
<td>4</td>
</tr>
</table>
</body>

Also, its adding html tag even if its not present in the document (if I
lookup parentNode of body). Is there a way to tell javascript not to be
intelligent? (because I am building an xpath and I want to extract the
exact xpath from the real-world-html-document)

You are using script to look at the document object model (DOM) that is
created from your HTML. JavaScript is just reporting what the browser has
created.

There is no way JavaScript can return the original HTML that created the
DOM - even innerHTML will return a serialised version of the DOM, not the
source markup.

You should not expect serialised DOM objects to be identical to the
original markup.
 
T

Thomas 'PointedEars' Lahn

Peter said:
Actually they matter quite a lot,

That is shortsighted thinking. It is the World Wide Web, not the Internet
Explorer Web. Interoperability is what counts, so it does not matter
whether the /supposed/ _current_ market share of a user agent is 10% or
90%. Not supporting the other UA because one depends on proprietary
features and behavior reduces the number of your potential visitors by 10%
or 90%. Likewise is your expected profit margin reduced by that number if
you run a commercial Web site, although that could have been avoided. I
would not call that being reasonable or responsible behavior, especially
when the additional costs (time, manpower) to accomplish interoperability
are this low in the beginning. In fact, the maintenance costs in the
mid-term are considerably higher for a proprietary-only approach compared
to the costs accounted for if you targeted interoperability from the
beginning. Some major companies had to and still have to recognize this
now, when they used IE-only code before and now want to support Firefox
as well (Intranets included). Do not make the same mistake.
but it is correct that TBODY is optional but implied in HTML. The problem
is that the DOM pretends to mimic the requirements of an SGML parser.

It is not a problem at all, and nothing is mimicked here. The DOM is
created on what is parsed, including elements that are optional or have
optional start/end tags.
[...] I would expect you being nocked by phantom nodes on tags' borders
in W3C-victimized browsers (cannot say "W3C-compliant" in this
particular case).
There are no phantom nodes. There are specified white-space text nodes.

The specification differs between SGML-style parsing and XML-style
parsing. XML has no phantom nodes but it does have disappearing
nodes in mixed content, which SGML only has in element content.

How did you get that idea?


PointedEars
 
T

Thomas 'PointedEars' Lahn

VK said:
You should stop living in fantasies, not me and nor the developers
community. This question was studied rather deeply - there is not any
written standard for *pretty-print of source code affecting DOM tree*.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You are not making any sense. No surprise here, though.


PointedEars
 
V

VK

Thomas said:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You are not making any sense. No surprise here, though.

You are demonstrating a lack of practical experience - no surprise
here, though. First check the definition of pretty-print (I actually
prefer the old term "indentations").

Now count the nodes in (or simply look at this in DOM Inspector):

<!-- Conventional pretty-print -->
<form name="frm01" method="post" action="foobar.cgi">
<fieldset>
<legend>Demo</legend>
<label for="foo">Foo:</label>
<input type="text" name="foo" id="foo" accesskey="f">
</fieldset>
</form>


<fieldset><legend>Demo</legend
<label for="foo">Foo:</label
<input type="text" name="foo" id="foo" accesskey="f"
</fieldset
</form>

P.S. On of rare moments when I'm ready to say "W3C MUST DIE!".
 
T

Thomas 'PointedEars' Lahn

VK said:
Thomas said:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You are not making any sense. No surprise here, though.

You are demonstrating a lack of practical experience [...]
YMMD.

[...]
<!-- Conventional pretty-print -->
<form name="frm01" method="post" action="foobar.cgi">
<fieldset>
<legend>Demo</legend>
<label for="foo">Foo:</label>
<input type="text" name="foo" id="foo" accesskey="f">
</fieldset>
</form>


<fieldset><legend>Demo</legend
<label for="foo">Foo:</label
<input type="text" name="foo" id="foo" accesskey="f"
</fieldset
</form>

It is only your ignorance and idioticy that is clearly displayed here.
Especially for the `form' element, it is not required to use the second
code style.
P.S. On of rare moments when I'm ready to say "W3C MUST DIE!".

Reconsidering my previous statement, please go on fighting the windmills,
and beating your head against the wall. This newsgroup wouldn't be as much
fun if you stopped.


PointedEars
 
V

VK

Thomas said:
It is only your ignorance and idioticy that is clearly displayed here.
Especially for the `form' element, it is not required to use the second
code style.

Anyone, do you mind to count nodes in both blocks in Firefox for
Thomas, he has math problems today.


<!-- Conventional pretty-print -->
<form name="frm01" method="post" action="foobar.cgi">
<fieldset>
<legend>Demo</legend>
<label for="foo">Foo:</label>
<input type="text" name="foo" id="foo" accesskey="f">
</fieldset>
</form>
 
A

anupamjain

VK, Johannes, Thomas, Peter, RobG. Thanks for all the replies !

I think I have a much better understanding now.

What I am actually doing is : I am grabbing the xpath of an element(by
building it bottom-up at the client side) and then storing it on the
server. Then later I am retrieving that xpath and again tracing it back
for the same URL. But I am tracing it back using
XPathAPI.selectSingleNode on the server side, whereas I was building
the xpath on the client side using javascript.

So there was a little bit inconsistency in the way the two 'documents'
are intrepreted by two different parsers. (Jtidy,Xerces on the server
side and javascript on the client side)

I was converting the HTML to XHTML using JTidy and then parsing it
using Xerces at the server side.(So it 'was' XHTML on the server side,
so no TBODYs)

But I guess now I will parse it also on the client side using mozilla's
doc.evaluate (It's ok for me if it runs only on Mozilla)

I hope it works. Will let you know.

Thanks again,

Anupam
 
D

Dr John Stockton

JRS: In article <442fc680$0$2116$5a62ac22@per-qv1-newsreader-
01.iinet.net.au>, dated Sun, 2 Apr 2006 22:41:38 remote, seen in
news:comp.lang.javascript said:
In HTML, a tbody
element is mandatory in a table but the tags are optional. By omitting the
tags, you are allowing the browser to create tbody elements where it
considers appropriate.

ASIDE - actually OT, but may be of interest :

For an author using HTML and Javascript only, there seems to be
no direct benefit in having explicit <TBODY> and </TBODY>.

However, for an author using CSS, ISTM that <TBODY> can be a
rather useful place to deposit class=... or style="..." .

FURTHER ASIDE -

Does anyone know of usage of Programme Week Numbering
*other* *than* matching ISO Week Numbering but for
weeks Saturday to Friday (Week 1 still containing the
first mid-week of the calendar year)?
 
V

VK

I was converting the HTML to XHTML using JTidy and then parsing it
using Xerces at the server side.(So it 'was' XHTML on the server side,
so no TBODYs)

But I guess now I will parse it also on the client side using mozilla's
doc.evaluate (It's ok for me if it runs only on Mozilla)

I hope it works. Will let you know.

It will not work - but you may try out of interest. First of all IE
doesn't support XHTML at all - it will be parsed as malformed HTML
Transitional with the most funny results (and the most fancy trees) to
expect. Given the phantom nodes problem on the standard-compliant
company plus some little but nasty DOM parsing discrepancies between
different browsers... I would say your idea of server-side /
client-side matching xpath's is like running two random numbers
generators on two machines and hope that the sequences will match.

I would suggest to use xpath in the environment it was intended to:- in
XSLT templates to process XML data part. With .xml (data) and .xsl
(transformations) you'll get what you want in the cross-browser way.
 

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

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top