RE: Strange ouput with pretty print on

At 10:42 AM 11/28/2003 -0500, you wrote:
> > >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.
>
> As a suggestion, maybe we should rename to XMLCDOMWriter, and then create a
> DefaultDONWriter that just extends from this. This would clear up the naming
> issues, while still providing backwards compatibility for existing code.
>
> Thoughts?
>
> Christian

Maybe, although I'm not sure it would make things any more clear.  People 
might then ask "Why is there an 'XMLCDOMWriter' and a 'DefaultDOMWriter' 
that both do the same thing"?  Hmmm...  I'll have to mull that over a 
bit.  We could always ask the Barracuda users what they think.  Anyway, any 
more conversation on this should take place on the BarracudaMVC list (which 
seems down at the moment, BTW).

Jake


> ----------------------------------------------
> Christian Cryder
> Internet Architect, ATMReports.com
> Project Chair, BarracudaMVC - http://barracudamvc.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
>
>
> > -----Original Message-----
> > From: xmlc-admin@xxxxxxxxxxx [mailto:xmlc-admin@xxxxxxxxxxx]On Behalf Of
> > Jacob Kjome
> > Sent: Friday, November 28, 2003 8:35 AM
> > To: xmlc@xxxxxxxxxxx
> > Subject: Re: Xmlc: 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
> >
> > _______________________________________________
> > XMLC mailing list
> > XMLC@xxxxxxxxxxx
> > http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc