Phlip wrote:
<snip>
The pipeline goes
HTTP ->
XHTML or HTML ->
DOM
That last line should be XHTML DOM or HTML DOM respectively, as the two
types of DOM are distinct.
DOM is a tree of objects in memory.
It is.
They no longer have a script representation.
What is that supposed to mean?
When you call createElement() , it creates one of these
objects directly, so the question whether the object
"came from" XHTML or HTML is irrelevant.
If you are creating an element in an XHTML document then it should be
the createElementNS method that is used as XHTML is namespace
qualified. Of course in reality most who think they are using XHTML are
actually using tag soup HTML with lots of errors in it, and so
scripting an HTML DOM in reality.
Next, by "the code that shows up in the browser", you might mean the
return value of innerHTML. It would be nice if this were indeed XHTML,
but nobody will ever parse and consume this HTML (unless you tell them
to). The DOM might be recreating its HTML from its data objects, and
you might be witnessing this recreation.
The - innerHTML - property is largely unsupported in XHTML DOMs.
Next, if you switch your HTTP document type from HTML to XHTML, with code
like this...
def set_encoding
if request.env["HTTP_ACCEP T"] &&
request.env["HTTP_ACCEP T"].index('applica tion/xhtml+xml')
headers["Content-Type"] = "applicatio n/xhtml+xml; charset=utf-8"
This is going to try to send application/xhtml+xml content type headers
to any UA that asserts its rejection of application/xhtml+xml. That is
irrational, and based upon a superficial understanding of HTTP accept
headers.
But given that XHTML DOMs and HTML DOMs need to be scripted
differently for anything beyond the utterly trivial, having served
alternative content-type headers how does this handle the problem of
needing to serve alternative scripts with the two content types?
else
headers["Content-Type"] = "text/html; charset=utf-8"
end
end
(borrowed from Rails),
Oh dear. I knew that the 'rails community' was deficient in their
understanding of javascript but I was not expecting such ignorance of
HTTP to be so evident.
then your innerHTML might change its story. Or maybe
not.
Yes, whenever the browser is sent the application/xhtml+xml content
type header with a valid XHTML document, and it supports XHTML, and is
scriptable, it will create an XHTML DOM and the odds are that -
innerHTML - will not be supported.
Next, if you switch your document type, you might break support for
browsers that have not caught up with this millenium.
If you use that server code for the switch you may end up breaking the
site for fully HTTP 1.1 conforming browser regardless of their age.
That's important to some people, so I bring it up here to avoid the
inevitable tilting at windmills...
There is a great deal to be said for people understanding the
implications of what they are doing.
Try inserting a single space into the createElement() , with
createTextNode( ) or some other browser-specific equivalent. Then the
system might have no choice but to close the tag correctly with
a </script>.
You point out that createElement creates the DOM representation of the
HTML element post mark-up, and then suggest that adding a text node
might have "the system" "close the tag correctly", when tags are parts
of the mark-up, and so not parts of the DOM.
Richard.
