Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #14104 > unrolled thread

FAQ Topic - How do I modify the content of the current page? (2012-05-23)

Back to article view | Back to comp.lang.javascript

Contents

  FAQ Topic - How do I modify the content of the current page? (2012-05-23) "FAQ server" <javascript@dotinternet.be> - 2012-05-22 23:00 +0000
    Re: FAQ Topic - How do I modify the content of the current page? (2012-05-23) Matt McDonald <matt@fortybelow.ca> - 2012-05-22 18:07 -0600
      Re: FAQ Topic - How do I modify the content of the current page? (2012-05-23) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-05-23 19:57 +0200

#14104 — FAQ Topic - How do I modify the content of the current page? (2012-05-23)

-----------------------------------------------------------------------
FAQ Topic - How do I modify the content of the current
page?
-----------------------------------------------------------------------

Using the non-standard but widely implemented
`innerHTML` property:
`<div id="anID">Some Content</div>` with script:

document.getElementById("anID").innerHTML =
"Some <em>new</em> Content";

Where `"anID"` is the (unique on the HTML page)
`id` attribute value of the element to modify.

All versions of Internet Explorer exhibit problems with innerHTML, including:

  * Fails with FRAMESET, HEAD, HTML, STYLE, SELECT,
OBJECT, and all TABLE-related elements.

  * Replaces consecutive whitespace characters with a single space.

  * Changes attribute values and order of appearance.

  * Removes quotations around attribute values.

If the new content is only text and does not need to replace existing HTML,
it is more efficient to modify the `data` property of a text node.

document.getElementById("anID").firstChild.data = "Some new Text";

Compatibility Note: Implementations have been known to split long text
content among several adjacent text nodes, so replacing the data of the
first text node may not replace all the element's text. The `normalize`
method, where supported, will combine adjacent text nodes.

Note: Make sure the element exists in the document (has been parsed) before trying to
reference it.

<URL: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-FF21A306>
<URL: http://msdn.microsoft.com/en-us/library/cc304097%28VS.85%29.aspx>
<URL: http://msdn.microsoft.com/en-us/library/ms533897%28VS.85%29.aspx>
<URL: http://developer.mozilla.org/en/Whitespace_in_the_DOM>
<URL: http://developer.mozilla.org/en/docs/DOM:element.innerHTML>
<URL: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#html-fragment-serialization-algorithm> (draft)


The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/

-- 

The sendings of these daily posts are proficiently hosted
by http://www.pair.com.

[toc] | [next] | [standalone]

#14105

On 12-05-22 05:00 PM, FAQ server wrote:

> If the new content is only text and does not need to replace existing HTML,
> it is more efficient to modify the `data` property of a text node.

A more general approach is simply to use the `nodeValue`
property, though both are acceptable.

> Compatibility Note: Implementations have been known to split long text
> content among several adjacent text nodes, so replacing the data of the
> first text node may not replace all the element's text. The `normalize`
> method, where supported, will combine adjacent text nodes.

The DOM 4 specification states[0] that textual content replacement
(`Node::textContent`, setting) is to be done by clearing
the `childNodes` of a node and appending a text node containing
the new text for Element and DocumentFragment nodes, while simply
replacing the `data` (and by proxy the `nodeValue`) for Text,
ProcessingInstruction and Comment nodes. I've written a fork
of `textContent` (to be released soon) that does precisely this.
Since Element nodes are the most desired context, the former
behavior is advised.

[0]: http://dvcs.w3.org/hg/domcore/raw-file/tip
/Overview.html#dom-node-textcontent


-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

[toc] | [prev] | [next] | [standalone]

#14107

Matt McDonald wrote:

> On 12-05-22 05:00 PM, FAQ server wrote:
>> If the new content is only text and does not need to replace existing
>> HTML, it is more efficient to modify the `data` property of a text node.
> 
> A more general approach is simply to use the `nodeValue`
> property, though both are acceptable.

Either one should only be used as fallback, where nodeValue should be 
preferred for compatibility, though:

>> Compatibility Note: Implementations have been known to split long text
>> content among several adjacent text nodes, so replacing the data of the
>> first text node may not replace all the element's text.

[1]

>> The `normalize` method, where supported, will combine adjacent text
>> nodes.

[2]
 
> The DOM 4 specification states[0] that textual content replacement
> (`Node::textContent`, setting) is to be done by clearing
> the `childNodes` of a node and appending a text node containing
> the new text for Element and DocumentFragment nodes, while simply
> replacing the `data` (and by proxy the `nodeValue`) for Text,
> ProcessingInstruction and Comment nodes. I've written a fork
> of `textContent` (to be released soon) that does precisely this.
> Since Element nodes are the most desired context, the former
> behavior is advised.
> 
> [0]: http://dvcs.w3.org/hg/domcore/raw-file/tip
> /Overview.html#dom-node-textcontent

“It is inappropriate to use W3C Working Drafts as reference material or to 
cite them as other than ‘work in progress’. This is work in progress and 
does not imply endorsement by, or the consensus of, either W3C or members of 
the DOM Working Group.” [3a]

Likewise for other W3C Working Drafts, for example Selectors Level 4 [3b]:

“Publication as a Working Draft does not imply endorsement by the W3C 
Membership. This is a draft document and may be updated, replaced or 
obsoleted by other documents at any time. It is inappropriate to cite this 
document as other than work in progress.”

The specification that you are citing is not even that [4], it is only a 
(W3C) *Editor's* Draft.  (You will want to fix that elsewhere, too.)

The `textContent' property was first specificied in W3C DOM Level 3 Core, 
which has the status of Recommendation since several years, and specifies it 
in the same way as this Editor's Draft [5].  By contrast to the Editor's 
Draft, there are several implementations of that Specification already.
So you should refer to the latter instead, and should be wary having your 
code based on the former.


PointedEars
___________
[1]  <http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-FF21A306>
[2]  <http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-normalize>
[3a] <http://www.w3.org/TR/2003/WD-DOM-Level-3-Core-20030609/>
[3b] <http://www.w3.org/TR/2011/WD-selectors4-20110929/>
[4]  <http://www.w3.org/2005/10/Process-20051014/tr.html#Reports>
[5]  <http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent>
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web