«

I'm having a tough JavaScript problem. I'm fairly new to JavaScript,
and what I'm trying to do is to replace instances of a particular
string inside a particular element with another string. Here's what I
have so far:

var result = document.evaluate('//div[@class="code"]/code', document,
null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);

if (result) {
for (var i = 0, len = result.snapshotLength; i < len; i++) {
// use snapshotItem(i) to get nodes
var val = result.snapshotItem(i).nodeValue;
val = val.replace(/<-/gi, "�");
result.snapshotItem(i).nodeValue = val;
}
}

The problem is that, even though I checked that my xpath works, the
result list is empty for some reason even though I know that it should
not be empty. Because of this, I haven't even checked to see that the
inside code works. Why is that?

kelvSYC wrote:

> var result = document.evaluate('//div[@class="code"]/code', document,
> null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
>
> if (result) {
> for (var i = 0, len = result.snapshotLength; i < len; i++) {
> // use snapshotItem(i) to get nodes
> var val = result.snapshotItem(i).nodeValue;
> val = val.replace(/<-/gi, "�");
> result.snapshotItem(i).nodeValue = val;
> }
> }
>
> The problem is that, even though I checked that my xpath works, the
> result list is empty for some reason even though I know that it should
> not be empty. Because of this, I haven't even checked to see that the
> inside code works. Why is that?

The `nodeValue' of an element node is not the content of the element; it is
`null' by definition, and assigning to that property has no effect then.
The element node has a text node as child node, which `nodeValue' you need
to change. As an alternative, and to deal summarily with further child
nodes, you can change the `textContent' of the element node (DOM Level 3
Core):

<http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-745549614>
<http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1950641247>

It is however possible that you only want to change the content of a
specific text node that is the child node of a specific child element of the
`code' element. In that case you can either modify exactly that text node,
which can be tricky if inline elements are nested, or you can use the
proprietary `innerHTML' property. The synhl() function used in
<http://PointedEars.de/es-matrix> does the latter, although it does not use
XPath (yet).


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$> (2004)

On Jun 5, 10:34Â*pm, kelvSYC <kelv...@gmail.com> wrote:
> var result = document.evaluate('//div[@class="code"]/code', document,
> null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
>
> if (result) {
> Â* Â* Â* Â* for (var i = 0, len = result.snapshotLength; i < len; i++) {
> Â* Â* Â* Â* Â* Â* Â* Â* // use snapshotItem(i) to get nodes
> Â* Â* Â* Â* Â* Â* Â* Â* var val = result.snapshotItem(i).nodeValue;
> Â* Â* Â* Â* Â* Â* Â* Â* val = val.replace(/<-/gi, "â†�");
> Â* Â* Â* Â* Â* Â* Â* Â* result.snapshotItem(i).nodeValue = val;
> Â* Â* Â* Â* }
>
> }
>
> The problem is that, even though I checked that my xpath works, the
> result list is empty for some reason even though I know that it should
> not be empty. Â*Because of this, I haven't even checked to see that the
> inside code works. Â*Why is that?

nodeValue property has a completely idiotic standard mechanics and
very seldom does what its name seemingly suggests:
https://developer.mozilla.org/En/NodeValue
The purpose of such standardization and naming is obscure, possibly it
is of a too strong grass they smoke in W3C

To overcome the idioticy, browser producers introduced additional
textContent property that does what you need and what nodeValue should
be doing if W3C members would be using right part of the body for
thinking.
https://developer.mozilla.org/En/DOM/Node.textContent

IE doesn't have this property because it has for ages its own
innerText property that does the same.
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

To not be bothered with the environment check every single time, you
may define once a string variable with the right property name:

var text = (/*@cc_on true || @*/ false) ? 'innerText' : 'textContent';

// ...

var val = result.snapshotItem(i)[text];

On Jun 6, 10:38*am, VK <schools_r...@yahoo.com> wrote:
> To not be bothered with the environment check every single time, you
> may define once a string variable with the right property name:
>
> var text = (/*@cc_on true || @*/ false) ? 'innerText' : 'textContent';
>
> // ...
>
> var val = result.snapshotItem(i)[text];

To be complete, DOM1 defines for text nodes read/write "data"
property, so theoretically you may use it instead:
var val = result.snapshotItem(i).data;

I never used it so I cannot comment on possible advantages/
disadvantages.

VK wrote:

> nodeValue property has a completely idiotic standard mechanics and
> very seldom does what its name seemingly suggests:
> https://developer.mozilla.org/En/NodeValue
> The purpose of such standardization and naming is obscure, possibly it
> is of a too strong grass they smoke in W3C

Will you *please* stop perpetuating your ongoing delusions? The value of an
element node is not supposed to be the element's text content, for an
element can have non-text content.

> To overcome the idioticy, browser producers introduced additional
> textContent property that does what you need and what nodeValue should
> be doing if W3C members would be using right part of the body for
> thinking.

Utter nonsense. For one, Microsoft is a W3C member.

> https://developer.mozilla.org/En/DOM/Node.textContent
>
> IE doesn't have this property

You only know IE and Mozilla, don't you? The majority of DOM
implementations supports the `textContent' property. That is
why it became and stays a Web standard, not vice-versa.

> because it has for ages

"For ages" -- 13 years?

> its own innerText property that does the same.
>
> http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

Those properties are _not_ equivalent. For one, `innerText' does not
include leading white-space text nodes, while `textContent' does.

> To not be bothered with the environment check every single time, you
> may define once a string variable with the right property name:
>
> var text = (/*@cc_on true || @*/ false) ? 'innerText' : 'textContent';

This is insane. The scripting language has nothing to do with whether
either of those DOM properties are supported.

OP: Ignore VK, they do not know what they are talking about.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

VK wrote:

> VK wrote:
>> To not be bothered with the environment check every single time, you
>> may define once a string variable with the right property name:
>>
>> var text = (/*@cc_on true || @*/ false) ? 'innerText' : 'textContent';
>>
>> // ...
>>
>> var val = result.snapshotItem(i)[text];
>
> To be complete, DOM1 defines for text nodes read/write "data"
> property, so theoretically you may use it instead:
> var val = result.snapshotItem(i).data;

Since result.snapshotItem(i) does not refer to a text node but to an element
node here, a `data' property it might have is certainly not defined by W3C
DOM Level 1 (which was obsoleted by W3C DOM Level 2 a decade ago).

Unsurprisingly, however, it does not have a `data' property, and the `data'
property of the first child text node (which could but does not have to be
result.snapshotItem(i).firstChild) does not need to equal the value of the
`textContent' property; the text content of an element may include several
text nodes, not necesarily adjacent ones.

> I never used it so I cannot comment on possible advantages/disadvantages.

You have not the shadow of a clue of what you are talking about. And that
is only a crude approximation.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

On Jun 6, 9:06*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Will you *please* stop perpetuating your ongoing delusions? *The value of an
> element node is not supposed to be the element's text content, for an
> element can have non-text content.

Surely: for instance, <textNode>Text</textNode> node has nodeValue
null. It is an obvious behavior additionally hinted by the property
name itself...

> You only know IE and Mozilla, don't you? *The majority of DOM
> implementations supports the `textContent' property. *That is
> why it became and stays a Web standard, not vice-versa.

It became Web standard for the same reason why CSS cursor:hand is
"wrong" and rather idiotic cursorointer is now "right" (any type of
cursor is pointer). The reason is that in Microsoft it is called that
way, so the "standard" one has to be called differently. This practice
has been abandoned only after the W3C's famous letter that ended the
2nd (Religious) Browser Wars (November 26, 2007):
http://www.w3.org/TR/2007/WD-html-de...ples-20071126/
In the particular see "2.3. Do not Reinvent the Wheel".

> > because it has for ages
>
> "For ages" -- 13 years?

Don't make yourself silly so often. Yes, 13 years for IT and the Web
is like 13 centuries for the human history.

> > its own innerText property that does the same.
>
> > *http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
>
> Those properties are _not_ equivalent. *For one, `innerText' does not
> include leading white-space text nodes, while `textContent' does.

It is a separate problem of the phantom nodes introduced by Gecko and
then reproduced by others, see
https://bugzilla.mozilla.org/show_bug.cgi?id=26179
IE never had that problem. So it is not a property specific, it is a
underlaying structure difference. See also
https://developer.mozilla.org/en/Whitespace_in_the_DOM
I especially like that multi-line code under the title "Making things
easier". Yet another proof that some programmers in Mozilla are real
humorists...

> > To not be bothered with the environment check every single time, you
> > may define once a string variable with the right property name:
>
> > var text = (/*@cc_on true || @*/ false) ? 'innerText' : 'textContent';
>
> This is insane. *The scripting language has nothing to do with whether
> either of those DOM properties are supported.
>
> OP: Ignore VK, they do not know what they are talking about.

OP: do as you wish.

> --
> * * realism: * *HTML 4.01 Strict
> * * evangelism: XHTML 1.0 Strict
> * * madness: * *XHTML 1.1 as application/xhtml+xml
> * * * * * * * * * * * * * * * * * * * * * * * * * * -- Bjoern Hoehrmann

VK wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Will you *please* stop perpetuating your ongoing delusions? The value of
>> an element node is not supposed to be the element's text content, for an
>> element can have non-text content.
>
> Surely: for instance, <textNode>Text</textNode> node has nodeValue
> null. [...]

No, certainly not.

>> You only know IE and Mozilla, don't you? The majority of DOM
>> implementations supports the `textContent' property. That is
>> why it became and stays a Web standard, not vice-versa.
>
> It became Web standard for the same reason why CSS cursor:hand is
> "wrong"

It is wrong because it implies a shape that is not necessarily used, and
because it is insufficient to describe the shape that is used if it is used.

> and rather idiotic cursorointer is now "right" (any type of
> cursor is pointer).

Utter nonsense. Pointer here means an shape that can point to something.
This could be an icon that is the pointer digit of a human hand, but does
not need to (it depends on the cursor theme).

> The reason is that in Microsoft it is called that way,

No, the reason is that "hand" does not reflect the shape.

> so the "standard" one has to be called differently.

Nonsense.

>> > its own innerText property that does the same.
>> >
>> > http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
>>
>> Those properties are _not_ equivalent. For one, `innerText' does not
>> include leading white-space text nodes, while `textContent' does.
>
> It is a separate problem of the phantom nodes

"Phantom nodes" are an fantasy of yours. Fortunately, the Wikipedia article
you created did not live long enough for this nonsense to be perpetuated.

> introduced by Gecko and then reproduced by others,

Nonsense.

> see
> https://bugzilla.mozilla.org/show_bug.cgi?id=26179

Your delusions have been disproved there, too (the bug is rightfully marked
VERIFIED INVALID, stupid). White-space text nodes are _not_ introduced by
non-MSHTMLs, they are sometimes disregarded by MSHTML. Everybody who has
the slightest clue about the DOM API knows that.

> IE never had that problem.

It has another, more serious problem of not providing a consistent document
tree. White-space text nodes are seemingly disregarded at random in MSHTML.
No, we do not really want that.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

On Jun 5, 6:51Â*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> kelvSYC wrote:
> > var result = document.evaluate('//div[@class="code"]/code', document,
> > null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
>
> > if (result) {
> > for (var i = 0, len = result.snapshotLength; i < len; i++) {
> > // use snapshotItem(i) to get nodes
> > var val = result.snapshotItem(i).nodeValue;
> > val = val.replace(/<-/gi, "�");
> > result.snapshotItem(i).nodeValue = val;
> > }
> > }
>
> > The problem is that, even though I checked that my xpath works, the
> > result list is empty for some reason even though I know that it should
> > not be empty. Â*Because of this, I haven't even checked to see thatthe
> > inside code works. Â*Why is that?
>
> The `nodeValue' of an element node is not the content of the element; it is
> `null' by definition, and assigning to that property has no effect then. Â*
> The element node has a text node as child node, which `nodeValue' you need
> to change. Â*As an alternative, and to deal summarily with further child
> nodes, you can change the `textContent' of the element node (DOM Level 3
> Core):
>
> <http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-745549614>
> <http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1950641247>
>
> It is however possible that you only want to change the content of a
> specific text node that is the child node of a specific child element of the
> `code' element. Â*In that case you can either modify exactly that text node,
> which can be tricky if inline elements are nested, or you can use the
> proprietary `innerHTML' property. Â*The synhl() function used in
> <http://PointedEars.de/es-matrix> does the latter, although it does not use
> XPath (yet).

Interesting about the inner part. But I still don't get why the xpath
expression "//div[@class="code"]/code" isn't matching anything, even
though there is such a thing in my document. I'm seeing "//div" not
matching anything, "//body" not matching anything, even "//html" not
matching anything. I can get "//*[@class="code"]" to match, though.

I should tell you about my eventual code. I'm planning on having it
so that a string like "<-" is entered in my HTML code in that form,
only for some javascript to transform it to an arrow character upon
rendering (whenever it appears in the XPath expression stated). If I
select the text and copy it, then I should get back the original "<-".

Relating to that is how I can replace some text in a text node with
node content - for example, replacing the word "foo" with a <span
class="...">foo</span>.

kelvSYC wrote:

> Thomas 'PointedEars' Lahn wrote:
>> kelvSYC wrote:
>> > var result = document.evaluate('//div[@class="code"]/code', document,
>> > null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
>> >
>> > if (result) {
>> > for (var i = 0, len = result.snapshotLength; i < len; i++) {
>> > // use snapshotItem(i) to get nodes
>> > var val = result.snapshotItem(i).nodeValue;
>> > val = val.replace(/<-/gi, "�");
>> > result.snapshotItem(i).nodeValue = val;
>> > }
>> > }
>>
>> > The problem is that, even though I checked that my xpath works, the
>> > result list is empty for some reason even though I know that it should
>> > not be empty. Because of this, I haven't even checked to see that the
>> > inside code works. Why is that?
>>
>> The `nodeValue' of an element node is not the content of the element; it
>> is `null' by definition, and assigning to that property has no effect
>> then. The element node has a text node as child node, which `nodeValue'
>> you need to change. [...]
>
> Interesting about the inner part. But I still don't get why the xpath
> expression "//div[@class="code"]/code" isn't matching anything, even
> though there is such a thing in my document. I'm seeing "//div" not
> matching anything, "//body" not matching anything, even "//html" not
> matching anything. I can get "//*[@class="code"]" to match, though.

In your first posting you have said that your XPath expression works, only
that the element content does not change. Therefore, I have explained why
it does not change and how to change it.

But now you are saying the XPath expression does not work in the first
place. Something does not add up here.

Suppose your XPath expression does not work, then it is impossible to say
why that would be so without you providing further details about your
runtime environment and the document; at best, a test case. I have since
updated synhl() and '//code[not(contains(concat(" ", @class, " "),
"donthl"))]' works fine in "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.9.2.3) Gecko/20100404 Iceweasel/3.6.3 (like Firefox/3.6.3) GTB7.0".


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16