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

J

Jake Barnes

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?
 
J

Jake Barnes

I should have added, to my original post, that when you go that page
you should click on something to start playing.
 
M

Martin Honnen

Jake said:
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.
 
V

VK

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
 
J

Jake Barnes

VK said:
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.
 
J

Jake Barnes

Martin said:
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.
 
M

Martin Honnen

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>
 
R

Richard Cornford

Jake said:
VK wrote:

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.
 
V

VK

Richard said:
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
' said:
(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.
 
T

Thomas 'PointedEars' Lahn

VK said:
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.
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.
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
 
R

Richard Cornford

VK said:
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.
 
J

Jake Barnes

Richard said:
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.
 
J

Jake Barnes

Thomas said:
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?
 
J

Jake Barnes

Martin said:
Jake Barnes wrote:



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?
 
T

Thomas 'PointedEars' Lahn

Jake said:
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
 
T

Thomas 'PointedEars' Lahn

Jake said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top