47793 - some elements lose margin-bottom when end tag omitted at end of TD or DD

Status: VERIFIED WONTFIX

(Core :: Layout, defect, P3)

Description

[Greg Roelofs]

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.

Comment 1

[Greg Roelofs]

adding 4xp (tested against NN 4.7)

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 3

[Mats Palmgren (inactive)]

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.

Comment 4

[Hixie (not reading bugmail)]

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>.

Comment 5

[Greg Roelofs]

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.

Comment 6

[Hixie (not reading bugmail)]

If you are relying on web pages to render the same on all browsers then you have
fundamentally missed the point of HTML.

Comment 7

[Greg Roelofs]

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.)

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: clearer testcase (in Nav4)

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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).

Comment 11

[Greg Roelofs]

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.

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.

Comment 13

[Hixie (not reading bugmail)]

Thanks David. As always, you did a better job than me! :-)

Comment 14

[HJ]

So IE is still a better browser and Mozilla/Netscape is braking there own rules!

Comment 15

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

*** Bug 92692 has been marked as a duplicate of this bug. ***

Comment 16

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

*** Bug 256044 has been marked as a duplicate of this bug. ***

Comment 17

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

*** Bug 256354 has been marked as a duplicate of this bug. ***