3457 - weird dependence on floats for box size

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

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

If you remove the vertical pixel ruler in the second test in the above URL,
http://www.fas.harvard.edu/~dbaron/csstest/linebox4 ,
the third stripe (the grey text under the yellow) shrinks back to the size it
should be (well, not quite "should" - see bug 1278), that is, the same size as
the other such stripes.

Comment 1

[kipp]

THis page reflows properly now; however, the HR at the bottom causes a
horizontal scroller and shouldn't (see bug #4286 for that problem)

Comment 2

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

I think you've just moved the problem.  Now the space *above* the div
class="two" changes if you add/remove the image.  I don't think this space
should depend on the image, so one or the other is wrong.

Comment 3

[kipp]

After another clarifying conversation with david baron, we determined that other
than the wrong collapsed margin values for div #2, the test is laying out
properly. The bug is that the top/bottom margin values for div#2 are based on
the wrong font-size value. Here is email from dbaron explaining all:

On Wed, 07 Apr 1999 02:50:54 +0000, "Kipp E.B. Hickman"
([e-mail]) wrote:
>
> What is the margin-top computed value? In other words, what does "1em"
> equal for div.two?

em's refer to the font size of the element in question, unless they
are on the font-size property, in which case it is the parent.

> nglayout is for some reason (is this correct?) using the font-size of
> the parent element for the "1em" value...

You just found one of the most basic bugs in NGLayout's CSS engine that
I have seen since September, when I first started testing NGLayout.  I
am astounded that this has not been caught yet:

NGLayout is not completely cascading the rulesets before computing the
values.  THE COMPUTED VALUES FOR EM UNITS ARE BEING FOUND AT THE END OF
THE RULESET IN WHICH THEY OCCUR.  FONT SIZE CHANGES THAT OCCUR IN LATER
RULESETS DON'T AFFECT THEM.

See:

http://www.fas.harvard.edu/~dbaron/misc/3457-2.html (bad)
http://www.fas.harvard.edu/~dbaron/misc/3457-3.html (OK - one ruleset)
http://www.fas.harvard.edu/~dbaron/misc/3457-4.html (OK - one ruleset)
http://www.fas.harvard.edu/~dbaron/misc/3457-5.html (OK - ruleset order
from #2 switched)
http://www.fas.harvard.edu/~dbaron/misc/3457-6.html ( bad - identical
selectors)

Aargh.  I didn't think this kind of bug would still exist.  I'm glad
we caught it now, though.

This is not a recent regression.  The behavior is exactly the same in
the build from 98-09-02, the oldest one I have.  (I assume it wasn't
fixed and un-fixed in between.)

David

Comment 4

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

The problem where the behavior was changed by the presence of the image did go
away (it did exist in the 99-04-02 build, but not 99-04-05).  However, there
are other remaining problems about the image triggering a horizontal scrollbar
(they may be new).  I filed these problems as bug 4615.

Comment 5

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

Those URL's are changed.  "misc" is my temporary public web directory.  Nothing
stays there.  They are now:

http://www.fas.harvard.edu/~dbaron/tests/nglayout/3457-2.html (bad)
http://www.fas.harvard.edu/~dbaron/tests/nglayout/3457-3.html (OK - one ruleset)
http://www.fas.harvard.edu/~dbaron/tests/nglayout/3457-4.html (OK - one ruleset)
http://www.fas.harvard.edu/~dbaron/tests/nglayout/3457-5.html (OK - ruleset
order
from #2 switched)
http://www.fas.harvard.edu/~dbaron/tests/nglayout/3457-6.html ( bad - identical
selectors)

Comment 6

[Peter Linss]

We now fully compute font informaiton before anything else. Thanks, good catch.

Comment 7

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

Verified fixed (both problems).