Have a look at this fragment: --begin-- <h1>This is H1</h1> this is normal. this is normal. this is normal. this is normal. this is normal. this is normal. this is normal. this is normal. --end-- Look in Netscape 4.x, or IE , then Mozilla, and you'll see that the H1 has more space after it than it should. It's only trivial, but it does look off. dan

This one is for you.

Changed Component to Style System. Did some quick testing on different browsers and here's some results: On IE4/Win, the space between Hx and P seems to be fixed to 19 pixels, regardless of the browser settings and page author's CSS. On Nav 4.x/Win, this space is somehow calculated from the browser's font size setting. A font size of 12 points results in 19 pixels of whitespace, while a font size of 24 points results in 36 pixels. The sample HTML 4.0 stylesheet in the CSS2 spec (http://www.w3.org/TR/REC-CSS2/sample.html and http://style.verso.com/corestyle/base.html) suggests the following margins and font-sizes in ua.css: H1 { font-size: 2em; margin: .67em 0 } H2 { font-size: 1.5em; margin: .83em 0 } H3 { font-size: 1.17em; margin: 1em 0 } H4 { margin: 1.33em 0 } /* no font-size specified, so defaults to 1em */ H5 { font-size: .83em; line-height: 1.17em; margin: 1.67em 0 } H6 { font-size: .67em; margin: 2.33em 0 } How about putting these to ua.css? IMHO, they are more reasonable than either IE4's or Nav4's behaviour - but still look very much the same on default browser font sizes. Todd Fahrner (fahrner@pobox.com) could probably help with the details (eg. I'm not exactly sure what the "line-height: 1.17em" on H5 is for).

ok, I looked at the proferred style sheet and its kind of nice. However, I really don't have a stronge sense of (a) it's correctness (b) it's appropriateness. I'm looking for opinions...david? troy? ian? thanks...

Nobody cares so I'm checking in the revised style sheet changes (I had to manually merge them because things have changed since 10/14).

Which did you check in? Sorry I didn't comment earlier (I thought I did...). The line-height on the H5 is BAD BAD BAD BAD BAD. Other than that, I think the size on the H6 is too small, and the legacy rendering might have bottom margins (I'm not sure), but other than that they're probably OK.

Well, I saw you checked it in... the line-height on the H5 should either be changed from "1.17em" to "1.17" or (preferably) removed entirely. I think inheritance should be the default. Should I reopen this?

Yes - the line-height on H5 should be stripped out completely.

The 'line-height: 1.17em' on H5 *is* very peculiar. However, since it's been included in the sample HTML 4.0 style sheet, which is supposed to be "based on extensive research into current UA practice", there ought to be a good reason for it. Maybe it should read 'line-height: 1.17'? (I'm not sure if that makes any more sense, though.) I've e-mailed Todd Fahrner for comments.

Even if it is the current UA practice to override a line-height given on BODY for the H5 element and no other elements, I think that's a bad practice.

When gathering the data for appendix A of CSS-2, it was not my intent to rationalize the system, but to describe it as closely as possible within CSS-1. I no longer recall distinctly, but I must have measured a a different line height for h5. I agree with David and Ian that this, even if true in some legacy UA contexts, is superfluous. I think there is less danger in rationalizing the UA default sheet than in overprecise emulation of an irrational model. I would write the UA default stylesheet very differently myself. It is patently screwy to have h5 and h6 smaller than "medium"/1em on the root, for instance. More significant, I think, is the fact that the H# sizes in legacy UAs cannot adequately be described in em units. The actual scaling intervals vary with the size of the font chosen by the user as a default. Only the keyword system (xx-small - xx-large) can handle this sort of thing. You should consider also whether you want the heading sizes to be relative in the sense that their size is affected by the size of their parent. I don't think they should be. So I would vote for: h1 { font-size: xx-large } h2 { font-size: x-large } h3 { font-size: large } h4 { font-size: medium } h5 { font-size: small } h6 { font-size: xx-small } This scheme and proposed keyword scaling values for varying base (medium) values is given here: http://style.verso.com/font_size_intervals/altintervals.

He's right, you know. The font-sizes should indeed not be specified using relative (em) values. This page may come in useful to whoever cares: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/h%5b1-6%5d.html BTW: Margins, as specified, appear to be ok. I believe only the way of specifying font-size needs some work.

The URL I cited got chopped off somehow. Here it is again: http://style.verso.com/font_size_intervals/altintervals.html#st In case this also gets chopped, it's the "synoptic table" of the document entitled "Toward a standard font size interval system", linked from the index of style.verso.com

Updating to default Style System Assignee...kipp no longer with us :-(

Updating summary to match current problem. Pierre: html.css should be changed so that it uses generic absolute units for the H1..H6 elements, and line-height should be stripped from the H5 rule. Something like this: h1 { font-size: xx-large; font-weight: bold; margin: .67em 0; } h2 { font-size: x-large; font-weight: bold; margin: .83em 0; } h3 { font-size: large; font-weight: bold; margin: 1em 0; } h4 { font-size: medium; font-weight: bold; margin: 1.33em 0; } h5 { font-size: small; font-weight: bold; margin: 1.67em 0; } h6 { font-size: xx-small; /* or x-small? */ font-weight: bold; margin: 2.33em 0; } ...to replace the current equivalent rules which use 'em' units. For more details see: http://style.verso.com/font_size_intervals/altintervals.html#st http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/h%5b1-6%5d.html

Troy wrote "Please don't muck with Kipp's bug list. Even though he's no longer here, we still use his buglist as a placeholder for block and inline related bugs. Once we have an owner for that code we'll re-assign the bugs to the new owner." Reassign back to kipp.

Wait a minute... Ian just offered a fix for that one. I'll take care of it.

Tod Fahrner wrote "You should consider also whether you want the heading sizes to be relative in the sense that their size is affected by the size of their parent. I don't think they should be". Why is that? If you use absolute sizes for H* and go to http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/h%5b1-6%5d.html, the result doesn't seem natural. People expect a H1 to be displayed larger than the surrouding text, however big that text is.

That makes perfect sense to me, but I suspect it's not what legacy browsers do (I could be wrong). I'd be very happy to see that changed (and also to see H6 be slightly larger than normal text!). If you want to do that, you should use em instead of absolute size keywords.

Nav4 and IE4 set the size of H* elements relatively to the parent, with the quirk in Nav4 that we don't display really big fonts (>48pt?) and in Nav4-Mac that we don't display the really small ones (<7pt?). That's how Mozilla works, without the quirks. Overall, the only change I can agree with is to remove the 'line-height' from H5.

Aah. Interesting. I just checked, and IE5 acts differently to Nav4. IE5 has absolute sizes for H[1-6] elements, NN4 has relative sizes based on parent, with, as pierre pointed out, some peculiarities (it clips big and small sizes). Since legacy browsers disagree on this, we can basically do what we like. I therefore agree with David and Pierre and suggest we use this: h1 { display: block; font-size: 2em; font-weight: bold; margin: .67em 0; } h2 { display: block; font-size: 1.5em; font-weight: bold; margin: .83em 0; } h3 { display: block; font-size: 1.17em; font-weight: bold; margin: 1em 0; } h4 { display: block; font-size: 1em; font-weight: bold; margin: 1.33em 0; } h5 { display: block; font-size: 0.83em; font-weight: bold; margin: 1.67em 0; } h6 { display: block; font-size: 0.67em; font-weight: bold; margin: 2.33em 0; } Points to note: + no line-height specified + font-size: 1em explicitly given on h4 + the H5 and H6 sizes are less than 1em -- this is so only because of backwards compatability This is very similar to what we currently have (what Kipp put in) except for the line-height on H5 and font-size on H4. We could even try to use this for H[4-6]: h4 { display: block; font-size: 1em; font-weight: bold; font-style: italic; margin: 1.33em 0; } h5 { display: block; font-size: 1em; font-weight: bold; margin: 1.33em 0; } h6 { display: block; font-size: 1em; font-style: italic; margin: 1.33em 0; } This makes h4 bold italic, h5 just bold, and h6 just italic, and all are 1em so they don't go smaller than the surrounding text. If we do this, then expect some complaints -- if any show layout problems (as opposed to just "this page now looks different" when it really looks better) then we should probably stick with the legacy settings.

Ian's latest suggestions sounds mostly fine to me -- but I think that the proposed bold-italic/bold/italic rendering of H4-6 might be too radically different from legacy behaviour. I agree that it's logically much better, though. Maybe we should implement that in Strict mode only and use the backwards-compatible H4-6 styles in "Legacy" mode? Any thoughts? (Pierre and others: if you need clarification for Todd's previous comments, note that he's currently not cc'd on this bug. Add him to the cc field or send a private E-mail if necessary.)

Antti: that would be great, but we are not having any method of including different ua.css rules for quirks mode vs strict mode. At least not so far. So I suggest we just stick with the backwards compatible styles first.

I think that if nobody disagrees, Ian's proposed H1-H6 styles (_not_ the alternate H4-H6 styles) can be applied to html.css. Also changing summary, changing platform & OS to All/All - and moving to M13 since this isn't really a very time-consuming fix.

Legacy behavior for sizing h1-h6 can't be described using relative units, especially XP, hence my recommendation to use keyword sizes. The rub is that you must then implement the keywords using legacy HTML 1-7 as a model, rather than any single interval (1.5 or 1.2) suggested by CSS. That's what the cited "scaling intervals" article is about. Here's a test showing why relative units (a) can't describe legacy and (b) are inferior: 1. Fire up Nav 4.x (Win32). 2. Confirm that your preferred font size is the default 16px (12pt@96ppi). 3. Do a screen grab of h4 and h6, as well as HTML font size "3" and "1". 4. Note that h6 and "1" are .60 of h4 and "3", and that h6 and "1" are barely legible (10px). If you use the proposed .67, the result rounds to 11px - not matching legacy. 5. Fire up Nav 4.x (MacOS). 6. Confirm that your preferred font size is the default 12px (12pt@72ppi). 7. Do a screen grab of h4 and h6, as well as HTML font size "3" and "1". 8. Note that h6 and "1" are .75 of h4 and "3", and that this is the minimum legible size (9px). If any larger interval were used (such as the proposed .67), h6/1 would be illegible. Different intervals are used depending on the base size chosen by the user. This, I assert, is how xx-small - xx-large and HTML 1-7 should be implemented. If you use any single scaling interval between h4-h6 and "3" and "1", you will effectively prohibit user selection of any preferred font size below 15px, so designers will continue to undertake to set the base font size for the user (to something "smaller"), which is really out of whac

But as mentioned above, absolute font sizes for H[1-6] means that if the base font size is set (by the author) to something large, then the headers will be minute in comparison. That, surely, is silly. Communicator 4.x does the relative thing in that case (although, again as mentioned above, in a rather strange and quirky way). So what we really want is to use relative sizes, but make the exact measurement dependent on the user's default font-size selection... Eek. :-( The problem with that of course is that if the user selects 10px base font-size, and we make our increments reflect that (e.g. h6 only 0.9em) then if the base font size is set by the _author_ to some larger value, the H[1-6] elements will have very little difference in size between each other. Pierre: Is there any likelyhood that the absolute font sizes (medium, large, xx-small, and so on) will be internally set based on what the user selects as a base font-size? What about user stylesheets -- is there any way the UI which selects the base font-size can change the user stylesheet so that we still use relative font-sizes (em units) but change what exactly the relation is depending on the user's default size? Todd: Do you see any clean way out of this hole?

Isn't it a requirement of CSS that the absolute size keywords depend on the user's selected font size (so the default is medium)?

No, I don't see a clean way out of the hole, and no, CSS does not explicitly require that the absolute size keywords depend on the user's selected font size (mapping to medium). In fact, in IE, the user's chosen size maps to "small", which is absurd, but this way MS was able to use the HTML 1-7 code to produce the 7 keyword (and H1-6) sizes with no interpolation, and there's something to be said for that. If Mozilla's rendering of H1-6 sizes does not correspond exactly to the anaologous range of HTML font sizes (font size="1" - font size="6"), many naively authored pages will break. So my question is: what is the relation, if any, between the HTML font sizes and the absolute size keywords in the Mozilla codebase? I think they must be coordinated. In quirks mode, the user-chosen value can map to HTML's 3 and CSS's small, as in IE, and in strict mode the user's value can map to CSS's medium. "Strict" documents don't use font tags anyway, so the compat issue is null unless we're talking bogus strict documents, and that's where I'd dra

What does the user's chosen font size map to in NN 4.x? Is it 'medium'? If so, it might be better to map to medium in both quirks and strict.

dbaron: Yep, it's 'medium' in Nav4.x. Todd: some of your last comment's text apparently got cut out for some reason.

Moving crufty m14-m15 bugs out to m16 for proper triage.

It's an old bug, I'm not sure it's still valid after having implemented Todd's font algorithm 2 months ago. I'll check it later unless someone wants to do it in the meanwhile. Pushed to M18.

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

The original bug regarding compatibility with legacy browsers is still valid, even though it's rather trivial. Attaching a screenshot of the 10/29/99 test case on three different browsers (default settings) to illustrate the problem. Clearing status whiteboard and adding '4xp' keyword.

Now that we have quirk.css (hooray!), we could apply Ian's proposed H4-H6 styles in strict mode only. If we do that, no heading is sized less than 1em - wouldn't it be mostly OK to use relative sizes for headings then? To avoid illegibly small text, we should probably stick with absolute size keywords in quirk.css. So, in html.css: h1 { display: block; font-size: 2em; font-weight: bold; margin: .67em 0; } h2 { display: block; font-size: 1.5em; font-weight: bold; margin: .83em 0; } h3 { display: block; font-size: 1.17em; font-weight: bold; margin: 1em 0; } h4 { display: block; font-size: 1em; font-weight: bold; font-style: italic; margin: 1.33em 0; } h5 { display: block; font-size: 1em; font-weight: bold; margin: 1.33em 0; } h6 { display: block; font-size: 1em; font-style: italic; margin: 1.33em 0; } (We should probably discuss other possibilities of styling H1-H6 without going below 1em size, too. Would it be safe to use eg. small-caps for one of the H's?) ...and in quirk.css: h1 { font-size: xx-large; margin: .59em 0; } h2 { font-size: x-large; margin: .79em 0; } h3 { font-size: large; margin: 1.06em 0; } h4 { font-size: medium; margin: 1.19em 0; } h5 { font-size: small; margin: 1.46em 0; } h6 { font-size: x-small; margin: 1.9em 0; } (I calculated those margins to match Nav4 heading margins at default font size.) Comments?

Antti: before changing the margins, we need to understand what's going on in the FontMetrics on different platforms. That's the other bug you opened (bug 43717). Marking dependency.

What is the status of this bug? Antti's suggestion works on windows.

adding quirks keyword as this is quirk mode only

Dependency is fixed now. Status?

Moved to mozilla1.0 but could be fixed cooner. I'm waiting for the font issues from rbs to be settled.

oops... 'sooner' not 'cooner'!

Moving to mozilla1.1. Engineers are overloaded!

Bulk moving from Moz1.1 to future-P1. I will pull from this list when scheduling work post Mozilla1.0.

cc'ing myself

Assigning pierre's remaining Style System-related bugs to myself.

What is the state here? Is this still relevant?

If no one on the CC list I'm going to mark this WORKSFORME in 2 weeks. The last comment was posted 2 years ago, asking if the bug was still relevant. Since then nobody replied.

If no one on the CC list responds,*

The line-height thing was fixed. The rest is WONTFIX since it works fine as is.