Replacing text on the fly
in [JavaScript]
|
Prev: Determining Browser Vendor, Version, and Operating System With JavaScript
Next: FAQ Topic - How do I trim whitespace? (2010-06-06)
From: Thomas 'PointedEars' Lahn on 6 Jun 2010 13:15 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
From: VK on 6 Jun 2010 14:19 On Jun 6, 9:06 pm, Thomas 'PointedEars' Lahn <PointedE...(a)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 cursor:pointer 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-design-principles-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/library/ms533899%28VS.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
From: Thomas 'PointedEars' Lahn on 6 Jun 2010 18:09 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 cursor:pointer 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/library/ms533899%28VS.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
From: kelvSYC on 6 Jun 2010 22:52 On Jun 5, 6:51Â pm, Thomas 'PointedEars' Lahn <PointedE...(a)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 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). 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>.
From: Thomas 'PointedEars' Lahn on 7 Jun 2010 06:23
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 |