FAQ Topic - How do I modify the content of the current page? (2009-12-18)
FAQ server
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.
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.
http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-FF21A306
http://msdn.microsoft.com/en-us/library/cc304097%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms533897%28VS.85%29.aspx
http://developer.mozilla.org/en/Whitespace_in_the_DOM
http://developer.mozilla.org/en/docs/DOM:element.innerHTML
http://jibbering.com/faq/faq_notes/alt_dynwrite.html
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.
Stefan Scholl
> Using the non-standard but widely implemented ` innerHTML ` property:
The not-yet-standard ...
http://www.w3.org/TR/html5/embedded-content-0.html#innerhtml
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
Garrett Smith
> FAQ server <javas...@dotinternet.be> wrote:
>> Using the non-standard but widely implemented ` innerHTML ` property:
>
> The not-yet-standard ...
>
> http://www.w3.org/TR/html5/embedded-content-0.html#innerhtml
IE does it differently. Tags are upper case. Many attributes are unquoted.
That document seems too far from reality. Should a link to it be added?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
Thomas 'PointedEars' Lahn
> Stefan Scholl wrote:
>> http://www.w3.org/TR/html5/embedded-content-0.html#innerhtml
> That document specifies rules serializing a fragment of HTML.
>
> IE does it differently. Tags are upper case. Many attributes are unquoted.
>
> That document seems too far from reality. Should a link to it be added?
IMHO no. Let us wait for the PR/REC instead. Same for the rest of HTML 5,
with maybe the exception of the multimedia elements that already work in
Gecko 1.9.1+ (Firefox 3.5+).
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Garrett Smith
> Garrett Smith wrote:
>
>> Stefan Scholl wrote:
>>> http://www.w3.org/TR/html5/embedded-content-0.html#innerhtml
>> That document specifies rules serializing a fragment of HTML.
>>
>> IE does it differently. Tags are upper case. Many attributes are unquoted.
>>
>> That document seems too far from reality. Should a link to it be added?
>
> IMHO no. Let us wait for the PR/REC instead. Same for the rest of HTML 5,
> with maybe the exception of the multimedia elements that already work in
> Gecko 1.9.1+ (Firefox 3.5+).
the browsers actually do.
It would have just as easy for the standard to use a new,
feature-detectible property (innerXML). That way IE could still keep the
effed up serialization routine based on the attributes problem in IE.
Browsers that supported the *new* property name (innerXML), could also
implmeent innerHTML. Most modern browsers already have some
implementatin of innerHTML. Of course it would be easy to feature test
that new property:-
if(typeof el.innerXML === "string") {
// OK, got at standard behavior.
} else if(typeof el.innerHTML === "string") {
// Who knows what this property will do.
// Time for some capability tests...
}
HTML 5 is a w3c working draft. The w3c does not seem to have anyone who
understands how to write browsers scripts. Looking to what javascript
libraries do is a bit short-sighted. The w3c "API designers", as Allen
euphamistically (diplomatically) calls them, should instead be looking
at what *problem* the library code is addressing.
Feature detection, its significance, and how it can be used by
programmers to develop degradable APIs seems totally foreign to the w3c.
This is evidenced in the APIs that are being developed that are not
detectible in scripts. Overloading xhr.send() method. A new method name
would have made feture detection easy: xhr.sendFile(). Easyt to detect
with:-
if(typeof xhr.sendFile !== "undefined") {
}
Standardizing innerHTML, document.all, quirks mode are all mistakes.
The w3c doesn't seem to have anyone who understands ecmascript, either.
I think if Brendan could be cloned to about five or six people, the
outlook for the web would be much better. Recently, Brendan indicated
hat he wanted to "banish host objects to the ninth circle of hell, in a
future edition."
Of course the other problem with the w3c is the politics of the
organization.
The actions of the w3c today are going to have irretractable effects.
David Mark
A bit? They are looking at the waste running through a sewer, rather
than what is generating it. It's worse than short-sighted. It's
backwards, focused on the (very troubled) past.
> The w3c "API designers", as Allen
> euphamistically (diplomatically) calls them, should instead be looking
> at what *problem* the library code is addressing.
Exactly. Because they are lock to fuck up virtually any problem they
address. Their endless foibles are smeared all over the Web. What
next? Standardize the jQuery attr method? Of course, then they'd
really have to _define_ it. :)
>
> Feature detection, its significance, and how it can be used by
> programmers to develop degradable APIs seems totally foreign to the w3c.
Unsurprising. It's foreign to their Web developers as well.
> This is evidenced in the APIs that are being developed that are not
> detectible in scripts. Overloading xhr.send() method.
Idiots.
> A new method name
> would have made feture detection easy: xhr.sendFile(). Easyt to detect
> with:-
>
> if(typeof xhr.sendFile !== "undefined") {
>
> }
Yes.
>
> Standardizing innerHTML, document.all, quirks mode are all mistakes.
The first I think is okay as long as developers keep in mind that such
standardization is not retroactive (maybe you can depend on them in
five yaars). The other two seem like wastes of time.
>
> The w3c doesn't seem to have anyone who understands ecmascript, either.
Who does? :)
> I think if Brendan could be cloned to about five or six people, the
> outlook for the web would be much better.
I don't follow.
> Recently, Brendan indicated
> hat he wanted to "banish host objects to the ninth circle of hell, in a
> future edition."
That is meaningless to me.
>
> Of course the other problem with the w3c is the politics of the
> organization.
Lousy democrats! :)
>
> The actions of the w3c today are going to have irretractable effects.
Sounds like another decade of futility. Or maybe, a few years from
now, Web Browsers as application platforms will be an antiquated
notion. Try to imagine future historians hailing early-century
"breakthroughs" like jQuery as watershed moments in software
development. I can't either. If the W3C is laboring under such
delusions, they are going to continue to produce useless standards
(e.g. QSA).
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> Stefan Scholl wrote:
>>>> http://www.w3.org/TR/html5/embedded-content-0.html#innerhtml
>>> That document specifies rules serializing a fragment of HTML.
>>>
>>> IE does it differently. Tags are upper case. Many attributes are
>>> unquoted.
>>>
>>> That document seems too far from reality. Should a link to it be added?
>>
>> IMHO no. Let us wait for the PR/REC instead. Same for the rest of HTML
>> 5, with maybe the exception of the multimedia elements that already work
>> in Gecko 1.9.1+ (Firefox 3.5+).
> I wouldn't mind linking to that section of HTML5, but that is not what
> the browsers actually do.
>
> It would have just as easy for the standard to use a new,
> feature-detectible property (innerXML). That way IE could still keep the
> effed up serialization routine based on the attributes problem in IE.
XML parsers and serializers are readily available, so there is no need for
another property. In addition, HTML has nothing to do with XML.
> HTML 5 is a w3c working draft.
Only on paper.
> The w3c does not seem to have anyone who
> understands how to write browsers scripts. Looking to what javascript
> libraries do is a bit short-sighted. The w3c "API designers", as Allen
> euphamistically (diplomatically) calls them, should instead be looking
> at what *problem* the library code is addressing.
You are punishing the messenger here. HTML 5 was not devised and is not
actively maintained by the W3C.
> Standardizing innerHTML, document.all, quirks mode are all mistakes.
>
> The w3c doesn't seem to have anyone who understands ecmascript, either.
The W3C relies mostly on the community effort. Simply complaining that
other people do not do what you want them to do is not going to accomplish
anything but piss those people off.
> I think if Brendan could be cloned to about five or six people, the
> outlook for the web would be much better. Recently, Brendan indicated
> hat he wanted to "banish host objects to the ninth circle of hell, in a
> future edition."
:)
> Of course the other problem with the w3c is the politics of the
> organization.
No, the problem of the W3C today is that so few people are willing to make a
commitment but rather sit on their backs and complain without really
understanding what they are talking about.
> The actions of the w3c today are going to have irretractable effects.
They are caused by the non-actions of complaining ignorants, though. If
nobody is interested to find a concensus, somebody incompetent like the
WHATWG thinks they are the Second Coming and if enough vendor support is
present the W3C will have little chance but to accept that nonsense as a Web
standard.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
Jorge
> (...)
> Feature detection, its significance, and how it can be used by
> programmers to develop degradable APIs seems totally foreign to the w3c.
> This is evidenced in the APIs that are being developed that are not
> detectible in scripts.
>
> Overloading xhr.send() method. A new method name
> would have made feture detection easy: xhr.sendFile(). Easyt to detect
> with:-
>
> if(typeof xhr.sendFile !== "undefined") {
>
> }
Unless the browser implements the file API (and therefore the Blob
Interface) and the The FormData Interface (and therefore, again, the
Blob Interface) you won't be able to pass a Blob or a FormData as a
parameter to xhr.send(). In that case there's not much to worry about
XHR.send() overloading.
If a browser that implements the blob interface necessarily accepts a
blob as a parameter to XHR.send(), and the same goes for formdata,
then there's the inference you're looking for.
--
Jorge.
Jorge
The point being made is that innerHTML is a standard already. A de-
facto standard. They're just trying to specify its behaviour, because
it wasn't specified anywhere. And that's -no matter what you say- a
good thing, my dear friend.
--
Jorge.
Jorge
The intention of your posts -like this one that I'm replying to right
now- seems to be no more than to piss off everybody else. And you've
become a master in that. If you've got anything useful -positive- to
contribute you should start by correcting that ugly attitude of yours
when posting to the w3c lists (and to es-discuss, too). For example,
neither Brendan nor anybody else (including me, as a subscriber) needs
*you* to post complains about top-posting. No, thanks. For that, go
somewhere else, thanks.
If you believe that with your inestimable contributions much better
apis would be delivered, then stop pissing off and switch from
contributing noise and complaints and little else to contributing
value. Thanks.
--
Jorge.
Jorge
> Of course the other problem with the w3c is the politics of the
> organization.
>
> The actions of the w3c today are going to have irretractable effects.
Hopefully:
-A step towards an open-standards non-propietary web.
-A well specified API.
-Better cross-browser compatibility.
-A richer API.
-The end of Flash and alikes.
To name a few.
--
Jorge.
David Mark
> On Dec 19, 6:49 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > (...)
> > Feature detection, its significance, and how it can be used by
> > programmers to develop degradable APIs seems totally foreign to the w3c.
> > This is evidenced in the APIs that are being developed that are not
> > detectible in scripts.
>
> > Overloading xhr.send() method. A new method name
> > would have made feture detection easy: xhr.sendFile(). Easyt to detect
> > with:-
>
> > if(typeof xhr.sendFile !== "undefined") {
>
> > }
>
> Unless the browser implements the file API (and therefore the Blob
> Interface) and the The FormData Interface (and therefore, again, the
> Blob Interface) you won't be able to pass a Blob or a FormData as a
> parameter to xhr.send(). In that case there's not much to worry about
> XHR.send() overloading.
>
Fair enough.
Garrett Smith
Garrett Smith
> On Dec 19, 6:49 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> (...)
>> Feature detection, its significance, and how it can be used by
>> programmers to develop degradable APIs seems totally foreign to the w3c.
>> This is evidenced in the APIs that are being developed that are not
>> detectible in scripts.
>>
>> Overloading xhr.send() method. A new method name
>> would have made feture detection easy: xhr.sendFile(). Easyt to detect
>> with:-
>>
>> if(typeof xhr.sendFile !== "undefined") {
>>
>> }
>
> Unless the browser implements the file API (and therefore the Blob
> Interface) and the The FormData Interface (and therefore, again, the
> Blob Interface) you won't be able to pass a Blob or a FormData as a
> parameter to xhr.send(). In that case there's not much to worry about
> XHR.send() overloading.
>
But what if you have a file? Will xhr.send( file ) work?
> If a browser that implements the blob interface necessarily accepts a
> blob as a parameter to XHR.send(), and the same goes for formdata,
> then there's the inference you're looking for.
Right. File is coupled to the XHR spec. Given a File object, there is no
way to know if xhr.send(file) will work. It's sort of an implicit
contract that an implementation of FileAPI APIs musht also implement XHR2.
Garrett Smith
> On Dec 19, 12:49 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Garrett Smith wrote:
>>>> Stefan Scholl wrote:
>
>> Standardizing innerHTML, document.all, quirks mode are all mistakes.
>
> The first I think is okay as long as developers keep in mind that such
> standardization is not retroactive (maybe you can depend on them in
> five yaars). The other two seem like wastes of time.
>
Everybody is already using innerHTML. The problem is if the program
wants to serialize some fragment of HTML and save it, for some type of
rich text editor or something. What innerHTML returns now would need to
be cleaned up a lot, in various ways, depending on the browser and its
version.
GYm time. :-D
Dr J R Stockton
>, Fri, 18 Dec 2009 00:00:02, FAQ server <javas...@dotinternet.be>
posted:
>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.
The example should be in the form of a function (cf. Wryt in my
include1.js), since it is likely to be used several times on one page.
In fact, the essence of the answer is "assign a string to the innerHTML
property of an element. That should be stated explicitly - there is no
need to get..Id if another form of reference is easier.
And "the content of the current page" should be interpreted as "the
visible content of the current page". Look at my estr-xpl.htm, and
click on brown bits. That works (ta, MH) by scripting
visibility/display of existing HTML, which must commonly be better than
writing a new string by script.
AFAICS, assignment to innerHTML should generally only be necessary if
the string needs to be computed.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Garrett Smith
The whining is harmless.
Comments on w3c lists that have potential to change things can be
dangerous, particularly to a business that has vested interest in making
things go a certain way.
The business can benefit from having someone on the inside, to have
greater influence on which ideas are heard and which are silenced. That
helps business.
Art Barstow is Nokia's w3c employee. He gets to control who can post
ideas on the webapps mailing list. And believe me, he does ban those who
criticize the APIs that Nokia's business decisions are based upon.
[...]
Dr J R Stockton
Sun, 20 Dec 2009 09:07:14, Thomas 'PointedEars' Lahn
<Point...@web.de> posted:
>The W3C relies mostly on the community effort. Simply complaining that
>other people do not do what you want them to do is not going to accomplish
>anything but piss those people off.
The same, of course, applies to most of what you write.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Grandson-Of-RFC1036 is released. RFC 5536 Netnews Article Format is a
subset of Internet Message Format which is described in RFC 5532. The
RFCs are read together to determine standard Netnews article format.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn posted:
>> The W3C relies mostly on the community effort. Simply complaining that
>> other people do not do what you want them to do is not going to
>> accomplish anything but piss those people off.
>
> The same, of course, applies to most of what you write.
The difference, my dear Doctor, is that I am not complaining (although not
solving a problem certainly is unsatisfactory, it is not my problem after
all); instead I am hinting, giving advice to those who want to hear it.
You should read my postings more carefully, then you might discover that.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Garrett Smith
The definition fails to specify the behavior as seen in Internet
Explorer. That is the most common mistake/anti-pattern of the w3c.
The consequence of this action makes it hard for Microsoft to comply
with the standard. It puts them in the position where they like to
consider opt-in standards mode, or compatibility buttons. Those are
awful things.
Garrett Smith
> On Dec 19, 6:49 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> The w3c doesn't seem to have anyone who understands ecmascript, either.
>
> The intention of your posts -like this one that I'm replying to right
> now- seems to be no more than to piss off everybody else. And you've
> become a master in that. If you've got anything useful -positive- to
> contribute you should start by correcting that ugly attitude of yours
> when posting to the w3c lists (and to es-discuss, too). For example,
> neither Brendan nor anybody else (including me, as a subscriber) needs
> *you* to post complains about top-posting. No, thanks. For that, go
> somewhere else, thanks.
>
Allen has gotten a little better at inline-style response. SO has
Travis, though his posts have never been worthwhile reading material.
> If you believe that with your inestimable contributions much better
> apis would be delivered, then stop pissing off and switch from
> contributing noise and complaints and little else to contributing
> value. Thanks.
Looks like your emotional reaction prevented you from finding value in
something I wrote. I wonder what that was.