Bug actually reported by chrisn@statecollege.com, faithful keeper of our beloved mozillazine: In the 11-07-98 nightly build of NGLayout, at this page: http://style.verso.com/boxacidtest/vd/ the "width" value in the <li id="bar"> tag shown below, when calculated from the percentage value, is supposed to be derived from the width of the containing block. The containing block is defined in the CSS2 spec as: "...unless the element is absolutely positioned, the containing block is formed by the content edge of the nearest block-level ancestor box." - http://www.w3.org/TR/REC-CSS2/visudet.html . However, it is being derived from the _compound_ width of the containing block - the content width, border width, and padding widths combined. Here's a description of how to test this for yourself: Pull up the source for the boxacidtest page above, and find this list element: <li id="bar"> <p> the world ends </p> <form action="./" method="get"> <p> bang <input type="radio" name="foo" value="off"> </p> <p> whimper <input type="radio" name="foo2" value="on"> </p> </form> </li> it utilizes these aspects of the style sheet... li { display: block; /* i.e., suppress marker */ color: black; height: 9em; width: 5em; margin: 0; border: .5em solid black; padding: 1em; float: left; background-color: #FC0; } #bar { background-color: black; color: white; width: 41.17%; /* = 14em */ border: 0; margin: 0 1em; } The list element's nearest container is the <UL>, but the stylesheet reference for the <UL> tag is this: ul { margin: 0; border: 0; padding: 0; } Since there are no width values there, we go to the next parent container, the <DD> tag, and its style sheet attributes: dd { float: right; margin: 0 0 0 1em; border: 1em solid black; padding: 1em; width: 34em; height: 27em; } So, the dd has a width (content width) or 34 (equivalent to 340px on this page). Since the nesting on this page goes dd>ul>li, and since the UL has no margin, border, or padding, the width for the <LI ID ="bar"> tag is anticipated correctly in the style sheet's comments to be 14em or 140px (41.17% of 340). This is not what we get in NGLayout, though... If we return to the <DD> tag, the width is 34em, with a padding of 1em and a border of 1 em, for a compound width of 38em (380px). Now, we go back to the li element and calculate 41.17% of 380 (the compound width)... and get 156.446, rounded down to 156. If you test the width of the NGLayout rendered <LI ID="bar"> element in an image app like Photoshop, you'll see that the content width is 156 (what we anticipate above from the compound width), and not the 140 that it should be. Here's a screenshot, showing the NGLayout rendering: http://www.mozillazine.org/problems/boxtest_percent.gif

Sounds like you just fixed this. I look at your bugs and couldn't find one that sounded the same. Maybe you can

% widths are now properly computed from the containing blocks content width, not the combined width.

Verified using 1999-03-23 Win32 build.