Hello Community,
I'm afraid we'll have to reconsider the XHTML conformance of CMSimple_XH. The problem is not so much the markup, but the JavaScript. Try to request the following code in a file:
Code: Select all
<?php
header('Content-Type: application/xhtml+xml');
?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script>
<script type="text/javascript">
function test() {
$("#test").html("<p>testing</p>")
}
</script>
</head>
<body onload="test()">
<div id="test"></div>
</body>
</html>
Nothing happens. Now comment out the line where header() is called and request the file again! The problem is not specific to jQuery; you'll get the same result with the following definition of test():
Code: Select all
function test() {
document.getElementById("test").innerHTML = "<p>testing</p>";
}
"innerHTML" is simply not defined for X(HT)ML documents. And if I'm not mistaken, this is only the tip of the iceberg. Having a simple API which produces valid HTML
and XHTML probably requires a bloated compatibility layer + several restrictions. Of course it's possible to simply neglect the "web standards" (in this case
http://www.w3.org/TR/xhtml-media-types/#media-types) and deliver XHTML as "text/html", but actually there's no point in doing so except satisfying the W3C validator...
Currently I'm
tending towards dropping support for XHTML, even if it's much cleaner and less demanding for the parsers; but it seems to place quite some additional burden upon the developers. I may be mistaken here, so I suggest to examine this issue further.
But even if we don't support "real" XHTML in the future, we might stick with the name "CMSimple_XH" by just redefining the meaning: "e
xtremly
HTML conforming"
And I'm quite sure somebody else could come up with something better...
Christoph