Re: Content-type for XHTML (was: XMLC, setEnab: msg#00031 java.enhydra.xmlc

At 01:44 PM 10/8/2003 -0400, you wrote:

On Wednesday 08 October 2003 12:38, Jacob Kjome wrote:
> In essence, you are right that Mozilla should be picking up the default
> namespace when parsing an XHTML document (with the XML parser) which
> provides the XHTML dtd, without requiring it to be specified in the <html>
> element. Given this buggy behavior, you should probably provide it anyway
> and the overall solution that I documented in my previous email still
> stands.

Fair enough, but I can also submit a Mozilla bug report...

Please post the link to the reported bug here. Don't forget to search bugs already reported on this issue.

As for the fix to XMLC, I have, locally, implemented a fix to the XMLFormatter where when opts.setEnableXHTMLCompatibility(true) is set and the options are passed to the writer, any element that doesn't match the following will be written out with an explicit end tag....
"br","area","link","img","param","hr","input","col","base","meta"

These are all elements that the HTML401 dtd reports as having an EMPTY content model. I think I got them all. If I missed anything, let me know. The only problem I see is that the code makes no distinction between these elements being in an XHTML document and these elements being in an arbitrary XML document. However, since users much explicitly state the desire to use the XHTML compatibility options, the chances that the document isn't an XHTML document are nil and would probably be categorized as user error if it wasn't an XHTML document. Hence, I don't see this as a big deal.

At the same time, (again, if opts.setEnableXHTMLCompatibility(true) is set) I also made empty elements be written out as <br /> instead of <br/> to comply with http://www.w3.org/TR/xhtml1/#C_2 .

Note that when using pretty printing and using opts.setEnableXHTMLCompatibility(true), the end tag of elements with a forced end tag will not have the same indentation as the rest of the markup. I'm not going to try to change that. Actually, it makes it perfectly clear which elements are being affected by forcing the end tag, so I tend to see this as a feaure :-)

Anyway, if this all sounds good, I'll check this in soon. Oh, and Petr, by "soon", I mean the next day or so at which time I'll make the release.... that is, if I hear no objections from other XMLC developers or users. Given this, please make sure to send in any bug reports you've been holding onto if you want the fixes to get into XMLC-2.2.3.

Jake

Previous by Date:	Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty), David Corbin
Next by Date:	Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty), David Corbin
Previous by Thread:	Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty), David Corbin
Next by Thread:	Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty), David Corbin
Indexes:	[Date] [Thread] [Top] [All Lists]

Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty): msg#00031

java.enhydra.xmlc