Bug 290125 Comment 43 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Historically, Gecko implemented the behavior allowed by CSS2 whereby a floated ::first-letter is "boxed"
tightly around the glyph shape, rather than using constant font-ascent and -descent metrics which may
leave a lot of blank space depending whether the character has any ascender/descender or not.

However, neither webkit nor blink do this, which leads to webcompat pain when sites are constructed
assuming their behavior.

Eventually, I think we should ideally reimplement ::first-letter entirely at frame-construction time,
rather than during reflow. But in the interest of minimizing risk here, and making it easy to flip
between our existing "legacy" behavior and the new "compatible" behavior, this patch leaves the
overall implementation unchanged and just alters the metrics used for the resulting first-letter
frame.

This patch creates an integer pref layout.css.floating-first-letter.tight-glyph-bounds to allow us
to choose between three behaviors:

    1: Use tight glyph bounds, and ignore line-height; the baseline of the floated letter automatically
       adjusts to wrap text around the "ink box" of the glyph. This is the existing Gecko behavior.

    0: Don't use tight glyph bounds, respect line-height: the floated letter acts like a normal <span>
       with float positioning; baseline position and vertical size are based on font metrics but not
       the specific shape of the individual glyph. This gives a similar result to webkit/blink.

   -1: Automatically choose between (1) and (0) based on heuristics to try and detect whether the page
       was written with the webkit/blink behavior (0) in mind; specifically, if there is a line-height
       of less than 1em, or a negative block-start margin, we assume the author was trying to eliminate
       excess blank space that behavior (0) tends to produce, and so we use that model.

Initially, this patch leaves the behavior unchanged for Beta/Release builds, but enables option -1 (use
heuristics to choose which layout model to apply) on Nightly so we can see how that works in practice.

Depends on D165007
Historically, Gecko implemented the behavior allowed by CSS2 whereby a floated ::first-letter is "boxed"
tightly around the glyph shape, rather than using constant font-ascent and -descent metrics which may
leave a lot of blank space depending whether the character has any ascender/descender or not.

However, neither webkit nor blink do this, which leads to webcompat pain when sites are constructed
assuming their behavior.

Eventually, I think we should ideally reimplement ::first-letter entirely at frame-construction time,
rather than during reflow. But in the interest of minimizing risk here, and making it easy to flip
between our existing "legacy" behavior and the new "compatible" behavior, this patch leaves the
overall implementation unchanged and just alters the metrics used for the resulting first-letter
frame.

This patch creates an integer pref layout.css.floating-first-letter.tight-glyph-bounds to allow us
to choose between three behaviors:

> 1: Use tight glyph bounds, and ignore line-height; the baseline of the floated letter automatically
>    adjusts to wrap text around the "ink box" of the glyph. This is the existing Gecko behavior.

> 0: Don't use tight glyph bounds, respect line-height: the floated letter acts like a normal <span>
>    with float positioning; baseline position and vertical size are based on font metrics but not
>    the specific shape of the individual glyph. This gives a similar result to webkit/blink.

> -1: Automatically choose between (1) and (0) based on heuristics to try and detect whether the page
>    was written with the webkit/blink behavior (0) in mind; specifically, if there is a line-height
>    of less than 1em, or a negative block-start margin, we assume the author was trying to eliminate
>    excess blank space that behavior (0) tends to produce, and so we use that model.

Initially, this patch leaves the behavior unchanged for Beta/Release builds, but enables option -1 (use
heuristics to choose which layout model to apply) on Nightly so we can see how that works in practice.

Depends on D165007

Back to Bug 290125 Comment 43