Re: XMLC or Tidy DOM Bug
Jacob Kjome <[email protected]> Sat, 18 Feb 2006 10:40:17 -0600
| Newsgroups | gmane.comp.java.enhydra.barracuda.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format... ------------=_1140280869-26506-22 Content-Type: text/plain; charset="us-ascii"; format=flowed This is a much reported issue. JTidy seems to have problems dealing with empty elements which use the XML <input /> syntax. Now, technically, <input> in HTML is not supposed to have an end tag. Then again, JTidy ought to deal with invalid markup, since that's its whole purpose in life. In any case, the JTidy bug is not likely to be fixed, especially since JTidy development is not so active. It had started up again, but the latest source is quite incompatible with the JTidy version that XMLC uses and development seems to have stalled as far as I can tell. Sounds like you are using XHTML? Or, at least, you are using some amalgam of HTML and XHTML. My advice now is the same as in the past; use the XHTML DOM provided by XMLC. In fact, you should read the release notes for the latest release, 2.2.8.1. I've made the XHTML DOM compatible with existing HTML DOM usage. So, where you have code that has been extensively using the HTML DOM, you can now drop in the XHTML DOM without issues. You just have to update your markup to be valid XHTML. Again, see the xmlc-2-2-8-1-release-note.html for more details. The advantages of this are: 1. Compile-time validation of markup 2. No more JTidy unpredictability 3. Able to define the encoding of the markup in the <?xml?> header, which overrides any default encoding set in the metadata (inclusion of the <?xml?> header upon output to the browser can be controlled via outputOptions.setOmitXMLHeader(boolean)) 4. DTD is included automatically in the output to the browser unless specified not to in outputOptions. Using the HTML DOM, you'd have to tell OutputOptions which DTD to include, since the HTML DOM does not store the DTD 5. XPath's can be written to look up elements using lower-case. So, the XPath's will always match the markup, since XHTML defines all elements to be lower-case. The HTML DOM stores elements in upper case, so the markup might use lower-case, the DOM stores it internally as upper-case making XPath usage confusing. 6. All the other benefits of XHTML If you haven't use XHTML much before, I suggest you use the Transitional doctype for pages with forms and the strict doctype for pages with no forms. Or just use Transitional for everything if you just want to be consistent across all your pages Jake At 06:33 PM 2/17/2006 -0800, you wrote: >I've come across an insidious bug with either XMLC or tidy. It is unclear >which. > >Given the following HTML: > ><html> ><body> ><table> > <tr> > <td> > <input type="hidden" name="xxxx" value="xxx"> > </td> > </tr> ></table> > ><div id="sibling"> >Sibling to table. ></div> > ></body> ><html> > >Compiling with XMLC properly results in the following DOM tree: > >[xmlc] DOM hierarchy: >[xmlc] LazyHTMLDocument%[T]: >[xmlc] HTMLHtmlElementImpl: HTML >[xmlc] HTMLHeadElementImpl: HEAD >[xmlc] HTMLTitleElementImpl: TITLE >[xmlc] HTMLBodyElementImpl: BODY >[xmlc] HTMLTableElementImpl: TABLE >[xmlc] HTMLTableRowElementImpl: TR >[xmlc] HTMLTableCellElementImpl: TD >[xmlc] HTMLInputElementImpl: INPUT: >name="xxxx" type="hidden" value="xxx" >[xmlc] LazyText: >[xmlc] HTMLDivElementImpl: DIV: id="sibling" >[xmlc] LazyText: Sibling to table. > > >If you add a '/' to the input element <input type="hidden" ... />, the DOM >will be incorrect, with what should be sibling elements ending up as child >elements of the table: > >[xmlc] DOM hierarchy: >[xmlc] LazyHTMLDocument%[T]: >[xmlc] HTMLHtmlElementImpl: HTML >[xmlc] HTMLHeadElementImpl: HEAD >[xmlc] HTMLTitleElementImpl: TITLE >[xmlc] HTMLBodyElementImpl: BODY >[xmlc] HTMLTableElementImpl: TABLE >[xmlc] HTMLTableRowElementImpl: TR >[xmlc] HTMLTableCellElementImpl: TD >[xmlc] HTMLInputElementImpl: INPUT: >name="xxxx" type="hidden" value="xxx" >[xmlc] LazyText: >[xmlc] HTMLDivElementImpl: DIV: id="sibling" >[xmlc] LazyText: Sibling to table. > >Note that the sibling DIV element is now a child of the table element. > >Using either <input> or <input></input> works, but <input/> will cause the >problem. > >The result is that when rendering, elements that should have been sibling >(same level) as the table will be added to the table as new rows. > >I don't believe the <input/> syntax is in any way invalid, so this seems >to be a bug. > >The command line version of tidy doesn't seem to care which way the input >element is terminated... > > > > > > > > >-- >Barracuda mailing list >[email protected] >http://www.objectweb.org/wws/lists/projects/barracuda ------------=_1140280869-26506-22 Content-Type: text/plain; name="message-footer.txt" Content-Disposition: inline; filename="message-footer.txt" Content-Transfer-Encoding: 8bit -- Barracuda mailing list [email protected] http://www.objectweb.org/wws/lists/projects/barracuda ------------=_1140280869-26506-22--