DOMDocument->saveHTML()
берет ваш информационный набор XML DOM и записывает его в формате старой школы, а не XML. Не следует использовать saveHTML()
вместе с типом документа XHTML, так как его вывод не будет правильно сформированным XML.
Если вместо этого вы используете saveXML()
, вы получите правильный XHTML. Хорошо, если этот вывод XML предоставляется совместимым со стандартами браузером, если вы задаете ему заголовок Content-Type: application/xhtml+xml
. Но, к сожалению, IE6-8 не сможет это прочитать, поскольку они по-прежнему могут обрабатывать только HTML старой школы под типом text/html
.
Обычное компромиссное решение - обслуживать text/html
и использовать «HTML-совместимый XHTML», как описано в Приложении C спецификации XHTML 1.0. Но, к сожалению, не существует PHP DOMDocument->saveXHTML()
метода для генерации правильного вывода для этого.
Есть несколько вещей, которые вы можете сделать, чтобы убедить saveXML()
создать совместимый с HTML вывод для некоторых распространенных случаев. Основным является то, что вы должны убедиться, что только элементы, определенные в HTML4 как имеющие модель содержимого EMPTY
(<img>
, <br>
и т. Д.), Действительно имеют пустой контент, что приводит к самозакрывающемуся синтаксису (<img/>
) использоваться. Другие элементы не должны использовать самозакрывающийся синтаксис, поэтому, если они пусты, вы должны поставить пробел в их текстовом содержимом, чтобы они не были такими:
<script src="x.js"/> <-- no good, confuses HTML parser and breaks page
<script src="x.js"> </script> <-- fine
Еще одна вещь, на которую стоит обратить внимание, - это обработка встроенных элементов <script>
и <style>
, которые являются обычными элементами в XHTML, но специальными CDATA
-контентными элементами в HTML. Некоторая обтекание /*<![CDATA[*/.../*]]>*/
требуется, чтобы любые <
или &
символы внутри них вели себя в основном согласованно, хотя учтите, что вам все равно следует избегать последовательностей ]]>
и </
.
Если вы действительно хотите сделать это правильно, вам придется написать свой собственный сериализатор HTML-совместимых XHTML. В долгосрочной перспективе это, вероятно, будет лучшим вариантом. Но для небольших простых случаев взлом вашего ввода, чтобы он не содержал ничего, что могло бы выйти на другой конец сериализатора XML как несовместимое с HTML, - это, вероятно, быстрое решение.
Это или просто смириться с этим и жить с не-XML HTML старой школы, очевидно.