By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 941 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

if you have used createElement() and appendChild() on a page, how do you capture all the HTML to write to PHP?

P: n/a
I'm trying to learn AJAX so tonight I sat down and came up with a
little toy that I can do tests with. You can see it here:

http://www.publicdomainsoftware.org/ajaxExperiment.htm

I've got Stuart Langridge's book "DHTML Utopia: Modern Web Design using
Javascript and DOM" which seems pretty good. It covers the basics.

The next thing I'd like to do is add a Save button to this little page
I came up with. I may use Sam Stephenson's Prototype framework to
write the page to a PHP script. Which will then write the whole thing
out as a flat file. That would be a fun little toy to play with.

The only thing that I don't see in the book is, how do I get all the
text and HTML that is in the page after that HTML has been extensively
changed through the use of createElement() and appendChild()? That is,
how do I capture all the material that I'd like to send to that PHP
script?

Feb 5 '06 #1
Share this Question
Share on Google+
15 Replies


P: n/a
I should have added, to my original post, that when you go that page
you should click on something to start playing.
Jake Barnes wrote:
I'm trying to learn AJAX so tonight I sat down and came up with a
little toy that I can do tests with. You can see it here:

http://www.publicdomainsoftware.org/ajaxExperiment.htm

I've got Stuart Langridge's book "DHTML Utopia: Modern Web Design using
Javascript and DOM" which seems pretty good. It covers the basics.

The next thing I'd like to do is add a Save button to this little page
I came up with. I may use Sam Stephenson's Prototype framework to
write the page to a PHP script. Which will then write the whole thing
out as a flat file. That would be a fun little toy to play with.

The only thing that I don't see in the book is, how do I get all the
text and HTML that is in the page after that HTML has been extensively
changed through the use of createElement() and appendChild()? That is,
how do I capture all the material that I'd like to send to that PHP
script?


Feb 5 '06 #2

P: n/a


Jake Barnes wrote:
The only thing that I don't see in the book is, how do I get all the
text and HTML that is in the page after that HTML has been extensively
changed through the use of createElement() and appendChild()? That is,
how do I capture all the material that I'd like to send to that PHP
script?


HTML element nodes in the browser DOMs of IE, Opera and others have
properties named
outerHTML
innerHTML
which when accessed serialize the node and its contents (outerHTML) or
the contents of the node (innerHTML).
Mozilla only supports innerHTML.
Take note that the serialization might not be the form of markup you are
looking for in times of people serving XHTML as text/html to browsers
for instance.

Mozilla and Opera and Safari I think also provide an XMLSerializer which
you can apply to DOM nodes but as the name says it is meant mainly for
serializing in terms of XML and not of HTML. Nevertheless
new XMLSerializer().serializeToString(htmlDOMNode)
can be done in those browsers.

--

Martin Honnen
http://JavaScript.FAQTs.com/
Feb 5 '06 #3

P: n/a
VK

Jake Barnes wrote:
The only thing that I don't see in the book is, how do I get all the
text and HTML that is in the page after that HTML has been extensively
changed through the use of createElement() and appendChild()? That is,
how do I capture all the material that I'd like to send to that PHP
script?


Presuming that you want to save the whole page after editing:

....
var pageContent = document.documentElement.innerHTML;
....
Now pageContent contains everything from opening <HTML> to closing
</HTML> including <HTML> tags themselves

Feb 5 '06 #4

P: n/a

VK wrote:
Jake Barnes wrote:
The only thing that I don't see in the book is, how do I get all the
text and HTML that is in the page after that HTML has been extensively
changed through the use of createElement() and appendChild()? That is,
how do I capture all the material that I'd like to send to that PHP
script?


Presuming that you want to save the whole page after editing:

...
var pageContent = document.documentElement.innerHTML;
...
Now pageContent contains everything from opening <HTML> to closing
</HTML> including <HTML> tags themselves


Shoot, that is such a clean idea I should have thought of that.

Feb 5 '06 #5

P: n/a

Martin Honnen wrote:
Take note that the serialization might not be the form of markup you are
looking for in times of people serving XHTML as text/html to browsers
for instance.

Mozilla and Opera and Safari I think also provide an XMLSerializer which
you can apply to DOM nodes but as the name says it is meant mainly for
serializing in terms of XML and not of HTML. Nevertheless
new XMLSerializer().serializeToString(htmlDOMNode)
can be done in those browsers.


Thanks much. So the innerHTML for the HTML element might work for an
HTML page but not an XHTML page? I"ll play around with it some today
and see if it works. Thanks much.

Feb 5 '06 #6

P: n/a


Jake Barnes wrote:

So the innerHTML for the HTML element might work for an
HTML page but not an XHTML page?


innerHTML gives you a string whether that is an HTML or an XHTML
document. But the DOM tree built and its serialization
(outerHTML/innerHTML) depends on how you serve the document, if you
serve XHTML as text/html (and IE only understands text/html) then the
DOM is built and serialized according to HTML/SGML rules and not XHTML
rules so while your original markup might have
<input type="submit" />
the browser might serialize that as
<INPUT TYPE="submit">
or
<INPUT TYPE=submit>
--

Martin Honnen
http://JavaScript.FAQTs.com/
Feb 5 '06 #7

P: n/a
Jake Barnes wrote:
VK wrote:

<snip>
Presuming that you want to save the whole page after editing:
...
var pageContent = document.documentElement.innerHTML;
...
Now pageContent contains everything from opening <HTML> to
closing </HTML> including <HTML> tags themselves


Shoot, that is such a clean idea I should have thought of that.


Clear as it may be that statement is false. The - documentElement -
property of an HTML/XHTML document (where supported) is the HTML
element, and the - innerHTML - property of the HTML element (where
supported) will not include the opening or closing HTML tags (or any
attributes of the HTML element). In addition, the - innerHTML - property
of the - documentElement - will not include any DOCTYPE declaration the
page may have, making it even less of a 'whole page'.

Richard.
Feb 5 '06 #8

P: n/a
VK

Richard Cornford wrote:
The - documentElement -
property of an HTML/XHTML document (where supported) is the HTML
element, and the - innerHTML - property of the HTML element (where
supported) will not include the opening or closing HTML tags
True. Damn forgetting this is *inner*HTML
'<HTML>' + content + '</HTML>' will fix it easily.
(or any attributes of the HTML element).
The only attributes allowed for <HTML> are "lang" and "dir" (we are
going standard, are we? ;-)
These properties are readable easily, but truthfully I've never seen
them yet used *there*.
In addition, the - innerHTML - property
of the - documentElement - will not include any DOCTYPE declaration the
page may have


document.doctype property is ready to help in such situation.

Feb 5 '06 #9

P: n/a
VK wrote:
Richard Cornford wrote:
The - documentElement -
property of an HTML/XHTML document (where supported) is the HTML
element, and the - innerHTML - property of the HTML element (where
supported) will not include the opening or closing HTML tags
True. Damn forgetting this is *inner*HTML
'<HTML>' + content + '</HTML>' will fix it easily.


Since the HTML/html element has attributes and XHTML is case-sensitive,
certainly this will not suffice.
(or any attributes of the HTML element).


The only attributes allowed for <HTML> are "lang" and "dir" (we are
going standard, are we? ;-)


In an XHTML document, at least the `xmlns' attribute is required for the
`html' element.
These properties are readable easily, but truthfully I've never seen
them yet used *there*.


As I have begun to make my (X)HTML documents conforming to Web Accessibility
standards, I have recognized that the first attribute (and its xml:lang
equivalent) is necessary to achieve that.
In addition, the - innerHTML - property
of the - documentElement - will not include any DOCTYPE declaration the
page may have


document.doctype property is ready to help in such situation.


What about Processing Instructions? What about other markup declarations?
You cannot engineer HTML back to equivalent XHTML as you cannot really make
XHTML "HTML-compatible".
PointedEars
Feb 5 '06 #10

P: n/a
VK wrote:
Richard Cornford wrote:
VK wrote:
Now pageContent contains everything from opening <HTML> to
closing </HTML> including <HTML> tags themselves


The - documentElement - property of an HTML/XHTML document
(where supported) is the HTML element, and the - innerHTML
- property of the HTML element (where supported) will not
include the opening or closing HTML tags


True. Damn forgetting this is *inner*HTML

<snip>

That is hardly an excuse for posting yet another lie to the group. You
should have realised by now that your though process is fundamentally
error-prone and so by applying the simple safety measure of trying
things out before you post them. Of course your arrogant belief that you
are right and everyone else is wrong (regardless of all the evidence to
the contrary) is the fundamental flaw in your though process (baring
mental illness, which cannot be disregard) and that alone prevents you
from accepting the evidence of reality.

Richard.
Feb 6 '06 #11

P: n/a

Richard Cornford wrote:
Jake Barnes wrote:
VK wrote:

<snip>
Presuming that you want to save the whole page after editing:
...
var pageContent = document.documentElement.innerHTML;
...
Now pageContent contains everything from opening <HTML> to
closing </HTML> including <HTML> tags themselves


Shoot, that is such a clean idea I should have thought of that.


Clear as it may be that statement is false. The - documentElement -
property of an HTML/XHTML document (where supported) is the HTML
element, and the - innerHTML - property of the HTML element (where
supported) will not include the opening or closing HTML tags (or any
attributes of the HTML element). In addition, the - innerHTML - property
of the - documentElement - will not include any DOCTYPE declaration the
page may have, making it even less of a 'whole page'.


Good to know, but I guess I could add that stuff (doc type declaration,
etc) back in whatever server side script I hand the material to to save
it to disk? At least in this situation, where I know exactly what file
I'm dealing with, it would be easy to add the doc type declaration back
in the PHP.

Feb 6 '06 #12

P: n/a

Thomas 'PointedEars' Lahn wrote:
VK wrote:
The only attributes allowed for <HTML> are "lang" and "dir" (we are
going standard, are we? ;-)


In an XHTML document, at least the `xmlns' attribute is required for the
`html' element.


We could fix this by downshifting to a less strict standard?

Feb 6 '06 #13

P: n/a

Martin Honnen wrote:
Jake Barnes wrote:

So the innerHTML for the HTML element might work for an
HTML page but not an XHTML page?


innerHTML gives you a string whether that is an HTML or an XHTML
document. But the DOM tree built and its serialization
(outerHTML/innerHTML) depends on how you serve the document, if you
serve XHTML as text/html (and IE only understands text/html) then the
DOM is built and serialized according to HTML/SGML rules and not XHTML
rules so while your original markup might have
<input type="submit" />
the browser might serialize that as
<INPUT TYPE="submit">
or
<INPUT TYPE=submit>


Rough. How do I have to server the DOM, in the first place, to avoid
ending up with something like <INPUT TYPE=submit> ?????

If I build the page as strict XHTML (not that I have, but I could)
would it serialize correctly for strict XHTML?

Feb 6 '06 #14

P: n/a
Jake Barnes wrote:
Thomas 'PointedEars' Lahn wrote:
VK wrote:
> The only attributes allowed for <HTML> are "lang" and "dir" (we are
> going standard, are we? ;-)

In an XHTML document, at least the `xmlns' attribute is required for the
`html' element.


We could fix this by downshifting to a less strict standard?


What are you talking about? The whole point of this exercise was to show
the (im)possibility to use the proprietary `innerHTML' property to retrieve
XHTML document content.

And no, `innerHTML' cannot provide the real content of any SGML-based markup
document. However, you can use the `responseText' property of an XMLHTTP
request.
PointedEars
Feb 7 '06 #15

P: n/a
Jake Barnes wrote:
Martin Honnen wrote:
Jake Barnes wrote:
> So the innerHTML for the HTML element might work for an
> HTML page but not an XHTML page?
innerHTML gives you a string whether that is an HTML or an XHTML
document. But the DOM tree built and its serialization
(outerHTML/innerHTML) depends on how you serve the document, if you
serve XHTML as text/html (and IE only understands text/html) then the
DOM is built and serialized according to HTML/SGML rules and not XHTML
rules so while your original markup might have
<input type="submit" />
the browser might serialize that as
<INPUT TYPE="submit">
or
<INPUT TYPE=submit>


Rough. How do I have to server the DOM,

^^^^^^^^^^^^^^
Pardon?
in the first place, to avoid
ending up with something like <INPUT TYPE=submit> ?????
Your Question Mark key is broken.

And Martin did not suggest you use a submit button, he just tried to
show you what the outcome of XHTML submit button markup would be when
retrieved via `innerHTML'.

However, to avoid submit buttons in the first place, you will have to
do XMLHTTP and similar requests.
If I build the page as strict XHTML (not that I have, but I could)
would it serialize correctly for strict XHTML?


No, you did not understand. `innerHTML' never serializes anything
correctly (that is, as-is), not even HTML.
PointedEars
Feb 7 '06 #16

This discussion thread is closed

Replies have been disabled for this discussion.