If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Heading leading inversely proportional to heading size

NEW
Unassigned

Status

()

Core
Layout: Block and Inline
15 years ago
8 years ago

People

(Reporter: Felix Miata, Unassigned)

Tracking

({testcase})

Trunk
x86
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: INVALID?)

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

15 years ago
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)
(Reporter)

Comment 1

15 years ago
Created attachment 114239 [details]
testcase
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.
(Reporter)

Comment 4

15 years ago
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".
(Reporter)

Comment 6

15 years ago
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?
Whiteboard: INVALID?
(Reporter)

Comment 8

15 years ago
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?
(Reporter)

Comment 10

15 years ago
Created attachment 114475 [details]
Reduced further testcase (default heading sizes)
Attachment #114277 - Attachment is obsolete: true
(Reporter)

Comment 11

15 years ago
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.
(Reporter)

Comment 12

15 years ago
Created attachment 114482 [details]
html.css with correct mime type
Attachment #114479 - Attachment is obsolete: true
(Reporter)

Comment 13

15 years ago
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.