User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030120 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030120 The text in the auction description overlaps to the point of unreadability. Reproducible: Always Steps to Reproduce: 1. Go to URL. Actual Results: Text displayed overlapping itself and unreadable. Expected Results: Text displayed readably in separate lines, albeit a bit tightly packed. Searching through Bugzilla located a number of similar bugs, all tech evang issues related to fixed-position divs. This page does not use fixed-position divs. The problem is probably in this CSS code: div { font-family: verdana,tahoma,arial; font-size: 9.5pt; line-height: 8pt; } This works in IE6, although the lines are a bit closely-packed because the font size is 1.5pt higher than the font height. In Mozilla everything is out of whack because the font is displayed at a size much larger than 9.5pt, more like 16pt or so (the font zoom is set to 100% and I'm running at 1024x768). The CSS is valid according to the W3C validator.

Here's a copy of the page so it will still be available when the auction item expires from eBay's database.

CONFIRMING, I see this on 2003012005, Win98. Problem does not occur on NS 4.x. Probably a dupe of one of the many overlapping font issues, but I don't know which.

Well, real source of trouble is <font size="5"> tag before this text. For uncertain reason IE ignore it.

I wouldn't think <font> tags are supposed to carry through to a new <div>...

Well, look at this testcase. You could see that <font size=5> apply.

More exactly> If there is wrong html code as: <font size="5"><div style="font-size:10px"></font></div>, than mozilla apply inner <font> properety.

Here's the source code that makes this bug invalid (8pt line height with 9.5pt text is a guarantee of overlapping text): <style type="text/css"> <!-- body { background-color: #FFFFFF; } div { font-family: verdana,tahoma,arial; font-size: 9.5pt; line-height: 8pt; } .title { font-size: 9pt; line-height: 10pt; font-weight: bold; } // --> </style> <div align="left">Here is a Working Irem Green Beret Cocktail Arcade Machine. It is in

It is true that the CSS guarantees some overlap, however in IE most of it is eaten up by the space between lines, leaving readable text. In Mozilla the overlap is much more pronounced, to the point that the text is unreadable. This seems to be because the text is too big due to Mozilla giving more priority to the <font> tag outside the <div> than the stylesheet properties for it. I'm not sure what the proper behavior should be in such a case, but it isn't (IMO) INVALID merely on account of the overlapping stylesheet sizes.

Also, re: comment #5 and #6: Obviously Mozilla does things that way (that's the entire point of bug), the question is whether it *should* do so.

Clearly it should not. Mozilla offers the option of forcing fonts to be at least a certain size for accessibility purposes. When this option is invoked (as I have done), Mozilla will render about 70% or so of pages on on the web incorrectly from Tom's Hardware to the error pages of a certain Redmond company's poor excuse for a webserver. If font sizes are forced in Mozilla, it will try to render them in the fixed sizes specified in the document, even though there is not enough room. This seems to only be a problem when CSS is involved. As more and more pages move to CSS, fewer and fewer of them can be viewed with Mozilla. If this bug is not going to be fixed in Mozilla, then another approach should be taken: OpenOffice works around the accessibility issue by allowing you to scale the entire program up or down. If Mozilla were able to scale everything, then the need to specify a minimum font size would not exist and pages would, in theory, be laid out correctly even if they needed to be scrolled horizontally. All the same, I think the overlapping text thing is indeed a bug. Gecko should not reserve space to render text at one size and then render it at another.

The issues (and component) here appear similar to those in invalid bug 201751. When CSS is used to size text, <font> should not be.

Comment 12 does not make sense to me. Comment 10 seems to be referring to bug 4821 as well as this bug. Problems looking like the screenshot in attachment 113056 [details] may be caused by bug 158868.

The basic issue is that <div> is not allowed inside <font> but authors expect the font styles to be applied to the <div>. Further, tags need to be nested... So the HTML parser fixes up <font><div></font></div> to the following DOM: <font></font> <div> <font></font> </div> If you now consider how this interacts with styling the div, the result is what this bug is about. Marking dup of the general bug on residual style changing the dom, but there is really no good solution in the case of totally broken content -- we went with the solution that makes most pages work. *** This bug has been marked as a duplicate of 166597 ***