Using the <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">, the following fragment shows just as plain text instead of an unordered list. <TABLE><TR><TD> <FONT> <UL> <LI> first bullet <LI> second bullet </UL> </FONT> </TABLE> This worked in previous mozilla builds (ie two months ago) but is not working no today's build (ie 2000-09-13-12) Removing the <FONT> and or <!DOCTYPE> tags makes the document render correctly.
The font tag is deprecated and not present in the strict dtd. This document does not adhere to the doctype it promises. Further more the font tag is even not allowed around an UL in transitional mode. IMHO this bug is invalid.
Agreed. This is invalid because under FONT cannot contain a list and the tag is deprecated under Strict DTD.
Verifying bug invalid.
I do not agree with this diagnosis. The <FONT> tag is not defined in the STRICT DTD, therefore its use in a document should not change the document's behaviour (i.e. it should be ignored because it has no meaning). Under the strict DTD, as implemented in mozilla, the behaviour of <FONT> is different inside a table than outside a table. This fundamentally makes no sense because IT SHOULD HAVE NO BEHAVIOUR AT ALL. Reference: http://www.w3.org/TR/1998/REC-html40-19980424/sgml/dtd.html
For absolute clarity, if I invent a tag called XFONT (just like I invented the tag FONT). Mozilla works correctly under the STRICT DTD. Here's an HTML fragment I used to test: <TABLE><TR><TD> <XFONT> <UL> <LI> first bullet <LI> second bullet </UL> </XFONT> </TABLE> The behaviour of the two undefined tags FONT and XFONT should be identical, but they're not.
I think (i may be wrong) that because the FONT tag cannot contain a list (per the Transitional DTD), then the parser will ignore the UL/LI tags and just render the contents, which happens to be text. But with your new example of using XFONT, I don't understand why Netscape 6 will render the contents as a list. I agree that the behavior should be the same but I will let Karnaze look at this. Attaching another testcase with TABLE v.s non-TABLE scenario and FONT v.s XFONT.
Testcase above uses Strict doctype
bug 48028 seems to be related.
I think this is a parser bug, the table code is more victim than the error source. the table code should never get the information that there was a font tag. I think this bug should be reassigned to rickg.
Harish, reassigning to you based on Bernd's comments.
Strict DTD will not be supported in Mozilla. This bug will become invalid once strict DTD is turned off.
Harish is right about the strictDTD. As far as the case goes, the fact that at is deprecated doesn't me it's "out". (There is another category for tags that are out). Deprecated tags may or may not be supported by a UA. We in fact support it. So the problem here (as the later testcase shows) is that <FONT> can't contain <UL> (inline doesn't contain block). So the testcase is invalid. In the case of user-defined tags, we allow them in the content model, and they adopt the content type of their parent.
Strict DTD has been turned off. Shouldn't see the bug anymore. Marking WORKSFORME.
QA contact update