Re: Strange ouput with pretty print on

Hi Mark,

At 10:56 AM 11/28/2003 +0100, you wrote:
> Hello,
>
> For development I use pretty printed output in the DefaultDOMWriter (will 
> it be renamed to XMLCDOMWriter as Jake stated in the Barracuda Mailing 
> list on 19-11-2003?).

Probably not.  I wanted to do this a while ago, but it wasn't approved by 
all committers.  Too many people directly reference it as well to change 
the name now.  Unless we have an outcry for it to be renamed, it probably 
won't be.  Just know that the DefaultDOMWriter really provides XMLC-based 
dom writing (and JTidy pretty printing, currently).  Other DOMWriter 
implementations should be named for the library they back such as the 
JivanDOMWriter that Arno Schatz wrote (which isn't in CVS yet).  Anyway, 
enough about that.  This isn't the Barracuda list, after all.

> But the output gets wrong in case of a text area with default value:
> If my mockup contains:
>
> <textarea>Default value</textarea>
>
> it got outputed as:
>
> <textarea>
>    Default value
> </textarea>
>
> Nice for html source readability, but it definitely changes something in 
> the browser, as I now have a lot of spaces before the "Default value" text 
> inside the text area. Could this be considered a bug, as pretty printing 
> should in my opnion not change the user visible output? (Guess the same 
> applies with </td> on the next line, but haven't tested it.

It is possible that <textarea> (and <pre>?) should be treated as a special 
case in pretty printing.  However, since Barracuda uses JTidy to implement 
pretty printing, the bug (?) is in JTidy, not XMLC or Barracuda.  Of 
course, I don't think XMLC's pretty printing output would be any different 
anyway since it doesn't treat any tags as special cases, but you'd have to 
test it out.  To do that, just set the pretty printing OutputOptions 
(DefaultDOMWriter takes an OutputOptions object in its constructor) and 
turn off pretty printing in DefaultDOMWriter.

That said, pretty printing is strictly for source readability and shouldn't 
be used in production as it will decrease performance and will fetter out a 
few unexpected bugs like this.  You might do well to asking on the Mozilla 
lists as to what proper browser behavior is.  Should <textarea> be paying 
attention to white space like this?  That is problematic since it forces 
the developer to pay attention to the HTML code structure which, normally, 
shouldn't be an issue.  I suppose it is for elements treating white space 
as "pre" (is CSS terms).  If you can report back as to your findings, it 
would be helpful.

Jake