Closed
Bug 20260
Opened 25 years ago
Closed 25 years ago
html.css: <sup> and <sub>.elements need explict line-height
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Core
CSS Parsing and Computation
Tracking
()
VERIFIED
FIXED
People
(Reporter: dr, Assigned: pierre)
References
()
Details
(Whiteboard: fix included [TESTCASE])
The URL for this bug is a simple testcase demonstrating a problem with line-heights in the presence of superscript and subscript tags. It is reasonable that when line-height is default, extra space should be added to account for the <sup> and <sub> tags, but when line-height is more than sufficient to accomodate for these tags, no extra space should be added. The baseline distance should be calculated from the baseline of the normal text, and not from that of the superscripted or subscripted text.
Assignee | ||
Updated•25 years ago
|
Assignee: pierre → troy
Assignee | ||
Comment 1•25 years ago
|
||
I agree: subscript and superscript should not modify the line height when there is plenty enough space. This is a layout issue: reassigned to Troy.
Did you guys actually read the CSS spec, or are you just stating your personal preference? Kipp tried very hard to make sure he did exactly what the spec defined
I'm pretty sure I understand the relevant stuff in the CSS spec, but here it is just in case: From 5.4.4, regarding vertical-align which I assume is where the <sup> and <sub> elements have their defaults: "They raise the baseline of the element (or the bottom, if it has no baseline) the specified amount above the baseline of the parent." So, to clarify my reading of this, the baseline of a superscript element is in fact higher than the baseline of surrounding text. From 5.4.8, regarding line-height which is the real issue here, "The property sets the distance between two adjacent lines' baselines." It does not specify here what two adjacent lines actually are, so it seems to assume that the baseline of a line is uniform throughout (which is false in this case). It then goes on to clarify this ambiguity by referring to section 4.4, "The height of lines." This section says some things which seem to both confirm and deny what Troy says: "If a line of text contains sections with different 'line-height' values (because there are inline elements on the line), then each of those sections has its own half-leading above and below. The height of the line-box is from the top of the highest section to the bottom of the lowest one." This seems to directly confirm what Troy says and indicate that Mozilla's current behavior is correct, except that the superscript element in the provided test case has no line-height value (the clause in the above statement), so the jury seems to still be out. It also says, "Note that any padding, border or margin above and below non-replaced inline elements does not influence the height of the line. In other words: if the 'line-height' is too small for the chosen padding or border, it will overlap with text on other lines." This is slightly odder, because it seems to say that even in the normal case when styles are at their default, there should be no extra space given for superscripts and subscripts... My personal opinion is this: the spec seems to be ambiguous in its definition, and the current behavior of Mozilla is pretty disturbing to the eye. Other systems using superscripts (such as TeX, the typesetting system) does not add extra space in their presence, and this choice results in a much smoother readability. Also, given that the majority of superscripts and subscripts will be either footnote indicators, or mathematical or chemical symbols, we shouldn't be offsetting the whole line for these few characters. This, of course, is just my opinion. The CSS spec may contradict it, although it seems ambiguous to me. But regardless of the spec, I very much stand behind this opinion. I'm putting David Baron, who seems to be the resident CSS geek, on the CC list for this bug; I'm hoping he'll have something to say.
Summary: css line-height does not account for <sup> and <sub>. → [ua.css]css line-height does not account for <sup> and <sub>.
The implementation is correct. The subscripts and superscripts have their inline boxes that need to be given room within the line box. This is, however, a ua.css issue. I would recommend that the sub and sup properties have line-height: normal (explicitly) by default so that they don't mess up large line-heights. (Ian, is this reasonable?) (In fact, if fonts didn't overflow the font-size, this could be 1.0 instead of normal. cc:ing erik just so he knows this would be an advantage... For those who don't know what I'm talking about, see the thread covering most of the latter half of the month called "font-size and accents, again" in http://lists.w3.org/Archives/Public/www-style/1999Nov/ . The basic problem is that fonts (according to some people) overflow their own font-size, so a line-height of 1 can lead to overlapping.) P.S. LaTeX does add space for superscripts if it's needed.
Updated•25 years ago
|
Assignee: kipp → pierre
Summary: [ua.css]css line-height does not account for <sup> and <sub>. → html.css: <sup> and <sub>.elements need explict line-height
Whiteboard: fix included [TESTCASE]
Comment 5•25 years ago
|
||
david: Yeah, you would indeed want to have "line-height: normal;" for the sup and sub elements, otherwise as you say the inherited line-height value would cause all sorts of strange problems. The file that actually needs changing is html.css, the change is that the rules for the "sup" and "sub" elements which currently read: sub { display: inline; vertical-align: sub; font-size: smaller; } sup { display: inline; vertical-align: super; font-size: smaller; } ...should be changed to read: sub, sup { display: inline; font-size: smaller; line-height: normal; } sub { vertical-align: sub; } sup { vertical-align: super; } [Reassigning to pierre, who will probably fix this quicker than kipp could...]
Just confirmed that this works (compiled the latest source and made the changes to html.css). Anybody with two seconds of time on their hands could apply this fix.
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•25 years ago
|
||
It's in. Thanks you both.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 8•25 years ago
|
||
Verified fixed.
You need to log in
before you can comment on or make changes to this bug.
Description
•