Raymond Irving wrote:
Hello,
I'm thinking that it's about time a saveXHTML() method be added to the DOM objects.
Not necessary.
saveXML() already does what is needed to provide valid xhtml output.
See the php source of http://www.clfsrpm.net/xss/dom_script_test.phps
to see how one can server-side detect whether or not to use saveHTML()
or saveXML()
XHTML is supported by all major browsers and libxml2
IE (still) does not properly support XHTML.
It will render an XHTML page sent with the text/html mime type - but
that's actually a standards violation.
so I can't see why we should be stuck with saveHTML() and saveXML(). While it's true that some developers are using saveXML(), it does not always comply with the XHTML standards.
Where does it deviate from xhtml standard?
xhtml is a subset of xml - if your DOMDocument is valid xhtml then the
output of saveXML() should be as well.
Another problem with saveXML() is the lack of support for HTML entities.
An xml document does not need HTML entities.
If the bro
There are many tricks out there to cleanup the output of saveXML()
What tricks are needed?
but I think having a native function would be much more efficient and faster.
What do you think?
I think it is not necessary.
There are some issues - IE
<a id="foo" />
is valid xml and I believe validates as xhtml - but (at least with older
versions of Mozilla) does not render correctly. Knowing that - I always do
$xmlAnchor = $myxhtml->createElement("a"," ");
$xmlAnchor->setAttribute("id","foo");
but that's a browser bug, not a saveXML() bug.
I'm really curious to know where saveXML() fails to produce valid XHTML
when the DOM structure is valid XHTML.
Rememver, XHTML is extendable - there's MathML and SVG that many
browsers already know what to do with, and I'm sure others will be
added. Unless a saveXHTML() function can be told what to do in those
cases, what's the point?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
