How do I get HTML sent to server?

Anyway, I repeat myself, your "need" is only due to a illogical slavery
on your part to your library.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Evertjan,

This is not an illogical slavery. The library is GREAT. Everybody is hung up
on why I want to do this and not the how.
DOES ANYONE KNOW HOW???

The why, is I want to construct an archival image of the view a user sees in
a client browser. This library can be used to construct an encrypted page
view image while maintaining inner data and it is easily renderable while
encrypted by most browsers. The archival image will be used as a legal
construct to document what a user saw in the browser and may be used in
court. Web sites do not come from a single server so reconstructing what the
server serves is inappropriate as the client view may get content from
dozens of servers to build a single client view.

MC

"MC" <mica[removethis]@aisus.com> writes:

Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

Sending the HTML won't give you that. It only gives you the structure
of the HTML, not what it *looks* like when displayed in a browser.
For that, you need a screenshot.

If you insist on converting the page's document structure back to HTML
and send that back to the server (including user-entered values in
form controls), you'll have to traverse the DOM structure and build
the HTML.

The non-standard innerHTML property only reads the original value
of input controls (i.e., "inputControl.originalValue", not the currently
entered value, "inputControl.value"). I.e., it misses the user entered
values.

This means that the HTML you generate is not what is currently being
shown, but *your* conversion of the DOM objects into a text
representation. If you are doing that anyway, why not just send
the values and build the structure on the server side.

Or, if you really, really need to be sure what the user sees,
accept his values as a normal form submit, and then generate
a bitmap image displaying those values along with a secret word,
and have the user submit the secret word to confirm that he
agrees with the data in the image.
That way you know what image was displayed, and that he can see
images.

/L
--
Lasse Reichstein Nielsen - lrn (AT) hotpop (DOT) com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

MC wrote on 16 jun 2008 in comp.lang.javascript:

Anyway, I repeat myself, your "need" is only due to a illogical
slavery on your part to your library.

[please do not quote signatures on usenet]

This is not an illogical slavery. The library is GREAT.

Wow, GREAT if you say so! I do not believe so.
That just means you are a willing slave to that greatness.

Everybody is

I wouldn't think everybody, as you did not ask or hear evrybody.
Are you a man or woman of superlatives?

hung up on why I want to do this and not the how.
DOES ANYONE KNOW HOW???

You cannot do this and you should not want to do this.
Wanting to do what is impossible is nice, but not productive.

The why, is I want to construct an archival image of the view a user
sees in a client browser.

1 html does only approximately show how different browsers, different sizes
and different OS'es show a window.

2 html is available on the server and can be directly taken from the server
by xmlhttp.

3 html does not show the changes made to the DOM on the browser.

[I wrote all these arguments before in this thread]

This library can be used to construct an
encrypted page view image while maintaining inner data and it is
easily renderable while encrypted by most browsers.

Impossible, if you mean "image" like most of us do.

What is "inner data", html being html?

What is "renderable" in the sense of a browser, a browser does not render
html, as html is the source as far as the browser is concerned?

What browser "encripts" the html?
Or do you mean parsing the html source to the DOM?

The archival image
will be used as a legal construct to document what a user saw in the
browser and may be used in court.

You must have a very naive judge to believe such.

Web sites do not come from a single
server so reconstructing what the server serves is inappropriate as
the client view may get content from dozens of servers to build a
single client view.

Could be true, but that is immaterial, only using clientside in-browser
javascript scripting.

You would need to conserve a screenview or a windowview, quite possible
with a seperate programme, but not just with browser scripting.

And even so, such view can be easily manipulated, so would not do for
juridical proof.

========================================

Remember you asked:
"How do I get HTML sent to server?"
[Which server, btw, since now you stipulate several servers?]

And not:
"How do I send a screenview to the server ?"

And I showed "sending html to a server" to be inappropriate for conserving
the view the user has seen on his or her screem.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

"Evertjan." <exjxw.hannivoort (AT) interxnl (DOT) net> wrote

MC wrote on 16 jun 2008 in comp.lang.javascript:


Anyway, I repeat myself, your "need" is only due to a illogical
slavery on your part to your library.

[please do not quote signatures on usenet]

This is not an illogical slavery. The library is GREAT.

Wow, GREAT if you say so! I do not believe so.
That just means you are a willing slave to that greatness.

Everybody is

I wouldn't think everybody, as you did not ask or hear evrybody.
Are you a man or woman of superlatives?

hung up on why I want to do this and not the how.
DOES ANYONE KNOW HOW???

You cannot do this and you should not want to do this.
Wanting to do what is impossible is nice, but not productive.

The why, is I want to construct an archival image of the view a user
sees in a client browser.

1 html does only approximately show how different browsers, different
sizes
and different OS'es show a window.

2 html is available on the server and can be directly taken from the
server
by xmlhttp.

3 html does not show the changes made to the DOM on the browser.

[I wrote all these arguments before in this thread]

This library can be used to construct an
encrypted page view image while maintaining inner data and it is
easily renderable while encrypted by most browsers.

Impossible, if you mean "image" like most of us do.

What is "inner data", html being html?

What is "renderable" in the sense of a browser, a browser does not render
html, as html is the source as far as the browser is concerned?

What browser "encripts" the html?
Or do you mean parsing the html source to the DOM?

The archival image
will be used as a legal construct to document what a user saw in the
browser and may be used in court.

You must have a very naive judge to believe such.

Web sites do not come from a single
server so reconstructing what the server serves is inappropriate as
the client view may get content from dozens of servers to build a
single client view.

Could be true, but that is immaterial, only using clientside in-browser
javascript scripting.

You would need to conserve a screenview or a windowview, quite possible
with a seperate programme, but not just with browser scripting.

And even so, such view can be easily manipulated, so would not do for
juridical proof.

========================================

Remember you asked:
"How do I get HTML sent to server?"
[Which server, btw, since now you stipulate several servers?]

And not:
"How do I send a screenview to the server ?"

And I showed "sending html to a server" to be inappropriate for conserving
the view the user has seen on his or her screem.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Look,
This is not helping and its not constructive. Yes, the main html is served
by a single page but the inner content may come from dozens of servers. We
are trying our best to approximate and document the client view. And yes, I
can construct an encrypted image that is comprised of data elements using
this library. I don't care if you have a problem with that. The how is what
I am interested in. It seems that if you can't offer a solution, then the
problem is criticized. I thought pointy ears was the only one being
unfriendly in that manner here.
MC

"Lasse Reichstein Nielsen" <lrn (AT) hotpop (DOT) com> wrote

"MC" <mica[removethis]@aisus.com> writes:

Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

Sending the HTML won't give you that. It only gives you the structure
of the HTML, not what it *looks* like when displayed in a browser.
For that, you need a screenshot.

If you insist on converting the page's document structure back to HTML
and send that back to the server (including user-entered values in
form controls), you'll have to traverse the DOM structure and build
the HTML.

The non-standard innerHTML property only reads the original value
of input controls (i.e., "inputControl.originalValue", not the currently
entered value, "inputControl.value"). I.e., it misses the user entered
values.

This means that the HTML you generate is not what is currently being
shown, but *your* conversion of the DOM objects into a text
representation. If you are doing that anyway, why not just send
the values and build the structure on the server side.

Or, if you really, really need to be sure what the user sees,
accept his values as a normal form submit, and then generate
a bitmap image displaying those values along with a secret word,
and have the user submit the secret word to confirm that he
agrees with the data in the image.
That way you know what image was displayed, and that he can see
images.

/L
--
Lasse Reichstein Nielsen - lrn (AT) hotpop (DOT) com
DHTML Death Colors:
URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html
'Faith without judgement merely degrades the spirit divine.'

THANK YOU!
I appreciate someone trying to help rather than criticize!

Just sending the data back will not work, as the client view may have html
content from other sources in its view.

I understand that a screenshot would work...any ideas on sending one back to
the server based on a .js event? I would really prefer to have a data image
as I can encrypt that and still retrieve the data from it. This will allow
me to pull data from it and index it to a database while storing the image.
The image does not need to be perfect as a client view but as good as
possible.

Is there any way to traverse and build the HTML and get the user entered
data? This is the real question no one seems to be able to answer.

MC

On Jun 16, 7:43 am, "MC" <mica[removethis]@aisus.com> wrote:

The why, is I want to construct an archival image of the view a user sees in
a client browser. This library can be used to construct an encrypted page
view image while maintaining inner data and it is easily renderable while
encrypted by most browsers. The archival image will be used as a legal
construct to document what a user saw in the browser and may be used in
court. Web sites do not come from a single server so reconstructing what the
server serves is inappropriate as the client view may get content from
dozens of servers to build a single client view.

Other posters have been making this point, but if you need to store
exactly what was viewed, storing the HTML will not do that, even if
you could accomplish that.

You might consider encapsulating the "legal" information into PDF and
archiving that. That would be a more reliable rendering of what "they
saw", because PDF rendering is less variable between browsers.

MC wrote on 16 jun 2008 in comp.lang.javascript:

This is not helping and its not constructive.

Showing you the errors of your thought must be constructive and helpful,
even if you do not like the answer.

On usenet, you can ask questions, but you can not dictate the answers.

Yes, the main html is
served by a single page but the inner content may come from dozens of
servers.

A strange way to define "inner content of html".

The page as shown in a browaser window can have inner content in an
iframe or as a change in the DOM. but that is not part of the html.

You could reconstruct a form of html from the DOM, using innerHTML,
but it would not do the job and certainly not convince the judge.

We are trying our best to approximate and document the client
view.

I showed you it was impossible to do, using a send back of html.

And yes, I can construct an encrypted image that is comprised of
data elements using this library. I don't care if you have a problem
with that.

I is not about if you care or do not.
I seem to remember you are the asking party.

The how is what I am interested in. It seems that if you
can't offer a solution, then the problem is criticized. I thought
pointy ears was the only one being unfriendly in that manner here.

You are just incontent with the answer,
because it does not follow your preconceived ideas.

Not liking my answer does not change the fact
that if it is impossible, it just is.

How are you so sure it is possible?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

On Jun 16, 9:57 pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:

The problem is that the browser - any browser - does _not_ have access
to the HTML source used to render the current page. Yes, sounds crazy.
Yes, anyone can click View > Page Source or equivalent to see the
source: anyone can but browser cannot. What browser can "see" is the
DOM Tree resulted from the parsing algorithms and error correction
mechanics of this particular browser applied to the server HTML
source. Respectively by getting document.documentElement.innerHTML
(the whole page) or document.body.innerHTML (body only) you are not
getting the original source. Instead the browser is "reverse
engineering" for you the current DOM Tree into some HTML code which
is, being reused by this particular browser, should result to a copy
of the current DOM Tree which is by itself is a browser-specific
result of parsing the original HTML source.

This is why btw the infamous Gecko's "phantom nodes" bug #26179
https://bugzilla.mozilla.org/show_bug.cgi?id=26179
remains a sample of unjustified silliness and stubbornness: because it
fights for a careful preservation of sorry leftovers of something that
doesn't exist in the browser's runtime nor accessible from within the
browser.
Someone just wanted to save its time on parse-adding extra spaces in
text/plain paragraphs like
<p>Lorem ipsum
dolor sit amet</p>
and to justify its laziness he brought W3C, traditions, standards and
nearly the Lord himself as a witness to prove himself right. :-\ :-)
An old story but still upsetting and still seriously influencing to
many coding paradigms...

MC a écrit :

Anyway, I repeat myself, your "need" is only due to a illogical slavery
on your part to your library.

Evertjan,

This is not an illogical slavery. The library is GREAT. Everybody is hung up
on why I want to do this and not the how.

I think you'll have to copy-paste(*) all the DOM in an hidden field sent
to the server when submitting (or on leaving the page).
But it's the user who decides to send that. Will he do it ?

DOES ANYONE KNOW HOW???

Evertjan told +/- how to do a copy, but certainly not how to receive it
without user's agreement.

The why, is I want to construct an archival image of the view a user sees in
a client browser.

I do not understand
(how to get a snapshot of the screen on the user's PC?)

This library can be used to construct an encrypted page view image

by 'image' you mean a picture ?
or just a representation (some code to show the expected view)

while maintaining inner data and it is easily renderable while
encrypted by most browsers. The archival image will be used as a legal
construct to document what a user saw in the browser and may be used in
court.

??? really ? are they mad ?

How do you reflect what did NC4 saw and what did Fx 3 or IE 8 ?
(NC4 doesn't know the DOM, IE 5 or 6 do what they want, no activeX on
Mac, and so on (plug-ins, java ... etc))
What about JS and Ajax (how to know if the user pressed this or this
button launching an XHR function that modified the page?)

But perhaps you want to illustrate what your server send to users ?
Why not to do the snapshots (for each environment and browser) by yourself?
<http://browsershots.org/>

Web sites do not come from a single server so reconstructing what the
server serves is inappropriate as the client view may get content from
dozens of servers to build a single client view.

You forget Ajax, Flash and certainly more.
An image will not show the hidden javascript nor what the Flash can do.

(*) the copy-paste of DOM isn't so easy
it seems to be the alone way because the DOM of a displayed page
can be modify at any time, changing the view

The real question is : how to get it, if the user doesn't send it.

--
sm

On Jun 16, 7:27 am, Lasse Reichstein Nielsen <l... (AT) hotpop (DOT) com> wrote:

"MC" <mica[removethis]@aisus.com> writes:

[snip]

The non-standard innerHTML property only reads the original value
of input controls (i.e., "inputControl.originalValue", not the currently
entered value, "inputControl.value"). I.e., it misses the user entered
values.

This means that the HTML you generate is not what is currently being
shown, but *your* conversion of the DOM objects into a text
representation. If you are doing that anyway, why not just send
the values and build the structure on the server side.

InnerHTML may "reflect" current values.

To see if value of document.title is reflected in your browser, try
the following, in order:

javascript:alert(document.title=1)
javascript:alert(document.getElementsByTagName("ti tle")[0].innerHTML)

Try a similar experiment with form elements, too.

javascript:alert(document.forms[0].elements[0].value="jp")
javascript:alert(document.forms[0].elements[0].parentNode.innerHTML)

Would show the innerHTML reflecting in Firefox and IE (but not
Safari).

Garrett

/L
--
Lasse Reichstein Nielsen - l... (AT) hotpop (DOT) com