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)

defect

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: pierre → troy
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.
Assignee: troy → kipp
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.
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]
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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
It's in. Thanks you both.
Status: RESOLVED → VERIFIED
Verified fixed.
You need to log in before you can comment on or make changes to this bug.