Closed Bug 3457 Opened 21 years ago Closed 21 years ago
weird dependence on floats for box size
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.
THis page reflows properly now; however, the HR at the bottom causes a horizontal scroller and shouldn't (see bug #4286 for that problem)
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.
Assignee: kipp → peterl
Severity: critical → major
Status: ASSIGNED → NEW
Target Milestone: M4 → M5
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" (firstname.lastname@example.org) 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
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.
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)
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
We now fully compute font informaiton before anything else. Thanks, good catch.
Verified fixed (both problems).
You need to log in before you can comment on or make changes to this bug.