php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #40359 DOMDocument's saveHTML() ignores formatOutput property
Submitted: 2007-02-05 01:09 UTC Modified: 2007-02-05 20:30 UTC
From: gmtfn at yahoo dot com Assigned:
Status: Not a bug Package: DOM XML related
PHP Version: 5.2.0 OS: Linux and Windows
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: gmtfn at yahoo dot com
New email:
PHP Version: OS:

 

 [2007-02-05 01:09 UTC] gmtfn at yahoo dot com 
Description:
------------
The saveHTML() method of DOMDocument reformats input HTML contents (from an HTML file or a string in a PHP file) despite that formatOutput property is set to false.

Setting preserveWhiteSpace to true or false before or after loading the HTML input doesn't seem to make a difference.

This may not seem important, but it breaks a third party menu software I am using on Mozilla based browsers.

I've tried this with PHP 5.2 on Linux and PHP 5.1.x on Windows, with the same results.

Reproduce code:
---------------
<?php
$myhtml = <<<EOF
<html>
<body>
<ul><li><a href="http://site.com">site</a></li><li><a href="http://site.com">another site</a><ul><li><a href="http://site.com">third site</a></li></ul></li></ul>
</body>
</html>
EOF;

$doc = new DOMDocument();
$doc->loadHTML($myhtml);
$doc->formatOutput = false;
echo $doc->saveHTML();
?>

Expected result:
----------------
I expected to see NO changed at all done to the input HTML. That's what the "formatOutput = false" is for, isn't it?

By the way, setting this property to true doesn't seem to produce anything different from what happens the property is set to false.

Actual result:
--------------
It reformats some fragments but leaves others in tact. Less important (for me) changes are: body and html opening and closing tags are put on 2 lines even though in the input they occupy 4 lines. But the important changes are:
the anchor tag is moved on a new line if it is a part of a <LI> that contains an <UL> as well. See the code: the second <a> element is move to a new line, away from its parent <LI>.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-02-05 01:14 UTC] gmtfn at yahoo dot com 
Your system changed my input. Before you test it, put everything between opening and closing UL tags on one line.
 [2007-02-05 07:02 UTC] chregu@php.net 
use saveXML instead of saveHTML and you get, what you expect (maybe also try loadXML, instead of loadXML, depending on what's your input)

Besides that, it's not a PHP, but a libxml2 issue, since PHP only uses the functions from there (and I assume, they do the correct thing regarding whitespaces, html and the specs)

load/saveHTML should only be used, if you want to use HTML 4.0, for xhtml, you're supposed to use the load/saveXML stuff.
 [2007-02-05 20:30 UTC] gmtfn at yahoo dot com 
I don't know why you assume that "they do the correct thing
regarding whitespaces, html and the specs", considering that I've shown to you that public description of the functionality isn't delivered.

So, is it your official recommendation that customers take it upon themselves to track down producers of third-party modules PHP providers use to deliver functionality and ask them to fix bugs? If I have to do that, I will. I just want to know if I've understood you correctly. If so, please give me their contact info if you have it.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon Apr 29 19:01:30 2024 UTC