[Webkit-unassigned] [Bug 181209] Incorrect handling of line-height on ::first-line

Thu Dec 29 08:11:26 PST 2022

https://bugs.webkit.org/show_bug.cgi?id=181209

--- Comment #7 from zalan <zalan at apple.com> ---
(In reply to Boris Zbarsky from comment #6)
> Created attachment 464240 [details]
> With the '.' inside the span
> 
> Moving the '.' inside the <span> does not change behavior in any way, either
It does change the behavior in both Safari(nightly) and Chrome (111.0.5496.0) in non-standards mode. The first line's height collapses to 0px on the second block.

What happens in _standards mode_ in the second block is
<div>
  <span>This is a first line.</span>
  This is a second line.
</div>
with the applied styles of
  span { line-height: 0px; color: purple }
Note that since ::first-line selector does not apply here anymore, we apply "line-height: 0px" only on the inline box triggered by the <span>.

Now this (first)line has 2 inline boxes.
- root inline box (every line has one)
- <span>'s inline box

The <span>'s inline box's line height is computed to 0px and the used value is also 0px.
The root inline box's line height is computed to normal and the used value is based on the relevant font metrics.

Both of these inline boxes stretch the line box as they both are considered contentful.
The <span>'s inline box stretches the line with the value of 0px, while
the root inline box stretches the line with the value of whatever the default font size here is.

While the root inline box does not have any content in the example, this is where _standards mode_ steps in.
In _standards mode_ 
1. we put an invisible strut inside every inline box
2. we measure this invisible glyph (zero width)
3. we set the inline box's height based on that measured size
4. we stretch the line box by the heigh of the (root) inline box

see https://www.w3.org/TR/css-inline-3/#inline-height
"To find the layout bounds of an inline box, the UA must first align all the glyphs 
directly contained in the inline box to each other by their dominant baselines. 
(See § 3.3 Baselines of Glyphs and Boxes.) If the inline box contains no glyphs at 
all, or if it contains only glyphs from fallback fonts, it is considered to contain 
a “strut” (an invisible glyph of zero width) with the metrics of the box’s first 
available font."

the simplest example is
<!DOCTYPE html>
<div style="border: solid">tall line<span style="font-size: 100px"></span></div>
vs.
<div style="border: solid">not so tall line<span style="font-size: 100px"></span></div>
where in _standards mode_ the "empty" inline box stretches the line due to this invisible strut. 

So in the last attached test case, 
the first block' first line is going to collapse to 0 as the root inline box's line height is computed to 0.
the second block' first line is _not_ going to collapse to 0 in _standards mode_ because of the root inline box height is computed to > 0 and it stretches the line.
In quirks mode, both the first and the second block's first line collapse to 0 (since we "ignore" the empty root inline box).

>Adding the span should not cause a difference in rendering.
The reason why it does is because the line-height is applied on the root inline box in the first block (div:first-of-type::first-line), while it is only applied on the span's inline box in the second block.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221229/1fe1e1d2/attachment-0001.htm>