Testing on Linux/glibc with talkback nightly 2000-08-05-04-M17 (but also true of 20000721 and earlier builds). Mozilla renders extra blank lines (as if <P> tags are present) between the "Basic Introduction" and "Current Status" lines, the "Informal History" and "More Detailed History" lines, the "Technical Documentation" line and the subsequent UL, and the "PNG: The Definitive Guide" line and subsequent UL. The W3C validator reports that the HTML is correct.
adding 4xp (tested against NN 4.7)
This bug also occurs in build 2000-08-04-20 on Windows 98 SE. The testcase is so small I'll include it here: <DL> <DD><P>A Basic Introduction to PNG Features</DD> <DD>Current Status of PNG</DD> </DL> NN3.04, NN4.7 and IE5 collapses the bottom margin of the <P> above.
OS: Linux → All
Summary: inconsistent spacing of DL elements and nested ULs → inconsistent spacing of DD elements
This is either INVALID or WONTFIX. INVALID on the basis that the P element has 1em margins per our CSS rules in html.css, and we are thus correct per CSS, and that HTML does not specify rendering rules, and we are thus correct per HTML. WONTFIX on the basis that it is easy for authors to work around this difference in our rendering -- either remove the <P> or change the margins on the <P>.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Keywords: 4xp → compat
Resolution: --- → WONTFIX
Ian, would you care to explain why html.css is set up like this, or shall I open another bug? To put it another way, how do you (mozilla.org, Netscape, whoever) justify forcing me (and who knows how many other thousands of webmasters) to modify five years' worth of perfectly valid HTML simply so that it will render on this one browser reasonably closely to all the other browsers? I'm not trying to be belligerent; I just want to stress that there had better be some very good reasons for breaking product parity. I agree that the rendering is working correctly and that I can add a line of CSS to work around the problem. But that's begging the question, not solving the problem. Replacing compat with 4xp. As you say, HTML does not provide rendering rules, and therefore the behavior of older browsers cannot be considered "wrong." In fact, I claim that majority rules make it "right," de facto.
If you are relying on web pages to render the same on all browsers then you have fundamentally missed the point of HTML.
So that's your entire response? Inconsistency is perfectly OK with you, and you can't be bothered to change Mozilla's default stylesheet or even to justify why it should differ from everybody else when it could be trivially changed? (For what it's worth, I never said I expected it to render the same. I am, however, fully aware that HTML mixes content and style, CSS notwithstanding.)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
This quirky stuff is a royal pain to emulate when you actually build a content model and use a ua stylesheet rather than display on a tag-by-tag basis and use hardcoded rules. IE5 probably acts slightly differently from NN4, and in a way easier to emulate.
Summary: html.css causes inconsistent spacing of DD elements → [MARGIN-C]html.css causes inconsistent spacing of DD elements
OK, I investigated what's going on here, and I think we should wontfix this bug. I would guess it would take somewhere in the range 2 weeks - 2 months to fix (although I'm not the expert, so those who would implement it might know better). This would be to emulate a behavior that I've only seen a few pages depend on (this bug, the CVS diffs produced by bonsai). This is actually a bug that has more to do with parsing that with layout. The behavior of Nav4 and IE5 differs when the *optional* "</p>" is put in. That is, they break one of the clearest conformance requirements of HTML 4.0 -- that documents that produce the same content model should be handled the same way. (See http://www.w3.org/TR/html4/conform.html#h-4.1 .) To fix this would require storing in the content model which tags were omitted and implementing a method of changing style based on that information. With the amount of time we have left and the severity of existing bugs, I think that is way too much work for way too little gain (and it's questionable whether it's gain at all -- our taking the step to change this now would save future browser implementors lots of time and allow easier entry into the browser market).
Summary: [MARGIN-C]html.css causes inconsistent spacing of DD elements → html.css causes inconsistent spacing of DD elements
19 years ago
Summary: html.css causes inconsistent spacing of DD elements → P without end-tag inside DD should not have margin-bottom
19 years ago
Keywords: 4xp → compat
Whiteboard: recommend WONTFIX
So just to clarify for my own benefit: if I had been using close-paragraph tags in my content, I'd have been seeing bottom margins all along? IOW, the trivial fix I was suggesting would break other content? If that's the case, then I accept the WONTFIX resolution (reluctantly...). Thanks for digging into this, David.
Yes, if you used close tags all along you would see the bottom margins. See the testcase I attached in Nav4 or WinIE5. Changing html.css would definitely break other content. (Even if the problem were as I originally thought it was, it still couldn't be described in CSS.) I'll mark this WONTFIX then. However, cc:ing mats, waterson, attinasi, and harish so they know that this old behavior exists and that they need to watch for dependence on end-tags that could be confused with other issues when trying to simplify a bug.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → WONTFIX
Thanks David. As always, you did a better job than me! :-)
Status: RESOLVED → VERIFIED
So IE is still a better browser and Mozilla/Netscape is braking there own rules!
*** Bug 92692 has been marked as a duplicate of this bug. ***
15 years ago
Summary: P without end-tag inside DD should not have margin-bottom → some elements lose margin-bottom when end tag omitted at end of TD or DD
*** Bug 256044 has been marked as a duplicate of this bug. ***
*** Bug 256354 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.