Trunks: Linux 2003021008; OS/2 2003021112; W32 2003021008 To reproduce: 1-Disable user stylesheet 2-Open testcase Actual result: 1-Space between heading and preceeding paragraph is taller when heading is shorter (H1=shortest space, H6=tallest space) Expected result: 1-Space between heading and preceeding paragraph is taller when heading is taller (H6=shortest space, H1=tallest space) OR 2-Space between heading and preceeding paragraph does not change when heading is taller (M$IE6 behavior)
Looks like we're maybe using the parent's font size, not ours, to compute the margin sizes?
No, we just have increasing margins in html.css to compensate for the smaller font size.
DB, why? I took all Hx margins back to 0 in today's build install and the testcase looks just like IE. Why would you want default top & bottom margins .67em for H1, or 2.33em for H6? If I reduce the testcase H4 margin to .8em or .9em, I can see a small decrease from 1em, but further reduction to .7em or below produces no visible change. What is stopping further reduction? Why can't I eliminate all space between P and Hx text?
The margin on the P is "stopping further reduction".
Created attachment 114277 [details] Reduced testcase Overrides to defaul P & Hx paddings and margins removed; errant semicolons replaced with colons. The inverse proportionality remains.
Attachment #114239 - Attachment is obsolete: true
Why is this a bug? The margins given in html.css are being followed. What's the problem?
Why are the margins set in html.css set to larger for smaller headings? Why should it not be the reverse, or equal? The current result is shown by the testcase, bizarre. IE does it better (equal).
> Why are the margins set in html.css set to larger for smaller headings? Why > should it not be the reverse, or equal? The margins have to be compatible with legacy UAs at the default sizes (when no CSS is involved). > The current result is shown by the testcase, bizarre. The testcase changes the font-size property without changing the margin properties. Authors should expect strange effects when changing the font-size value but not updating the properties whose values are given in ems. > IE does it better (equal). IE, however, can be shown to have silly results in other cases, such when the body font-size is increased. What do you propose?
Created attachment 114475 [details] Reduced further testcase (default heading sizes)
Attachment #114277 - Attachment is obsolete: true
Created attachment 114479 [details] modified x/mozilla/res/html.css I don't see how there is an inconsistency with "legacy UA's" except that they (sample of 1=Netscape 4.8 Win) display apparent margins equal without regard to Hx size, while Mozilla currently doesn't. I took a quick look with Netscape "2.02" for OS/2 at the reduced further testcase, and found the larger the heading size, the larger the margins, though not by much, probably about 20% or less of the opposite of the. current Mozilla margins. This attachment is my proposal, a refinement of the original html.css's Hx margins so that the apparent margins are equal without regard to Hx size when using the default Hx sizes. I tested 100DPI Linux and 120DPI W98 at 1024x768 at default 16px, and 120DPI W98 at 1280x1024 at 20px default (which scales at 1280x1024 approximately equivalent in absolute size to 16px at 1024x768). I did not spend time to seriously tweak the new margin em sizes for Hx, but they appear to be within .05em of equal from H1 to H6. I don't have a good way to measure small vertical onscreen distances.
Created attachment 114482 [details] html.css with correct mime type
Attachment #114479 - Attachment is obsolete: true
I'm puzzled why changing the margins in html.css produces rendering results opposite the change in the em value. In order to equalize the apparent margins regardless of Hx size, the specified margin needs to be larger the smaller the Hx size, like the original html.css. My changes were simply to reduce the >1em values to half the excess over 1, + 1, e.g. 2.33 became 1.667.
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline
You need to log in before you can comment on or make changes to this bug.