Bug 267185 – Incorrect lh (line-height) value used unless set on parent

• Component: Layout and Rendering
• Status: RESOLVED DUPLICATE

[Ana Tudor]

Created attachment 469314 [details]
screenshot illustrating the problem

Set the `font` property, including the `line-height` on an element:

```
font: 5rem/ 1.25 monospace
```

Also give this element a gradient `background` whose size depends on the `lh` unit:

```
background: linear-gradient(#00f 2px, #0000 0) 0 -1px/ 1% 1lh;
```

I would expect to see those thin blue lines in between the lines of text, perfectly aligned with them. This is what happens in Chrome and in Firefox.

What actually happens is they're misaligned.

Setting the background on an absolutely positioned pseudo covering its entire pattern works fine however. And so does setting the `font` property on the element's parent.

Live test https://codepen.io/thebabydino/pen/PoLNpPz?editors=1100

I've only tested this myself via Epiphany, but it's been confirmed it also happens in actual Safari: https://twitter.com/SelenIT2/status/1743669359606714834 & https://www.smashingmagazine.com/2023/11/css-responsive-multi-line-ribbon-shapes-part1/

[alan]

Created attachment 469316 [details]
Test reduction

[Radar WebKit Bug Importer]

<rdar://problem/120593921>

[Tim Nguyen (:ntim)]

I think it's getting the line-height of the parent element instead of the current one.

[Tim Nguyen (:ntim)]

The code for this unit is here if anyone wants to TAL: https://searchfox.org/wubkat/rev/c22ca98693565713efde37e8311190dd00e165ef/Source/WebCore/css/CSSPrimitiveValue.cpp#933-939

[Tim Nguyen (:ntim)]

It doesn't seem to be hitting the code that calls `parentStyle()` from quick local testing.

[Tim Nguyen (:ntim)]

Oh the issue here seems to be that WebKit computes the `lh` unit for the background (`CSSToLengthConversionData::computedLineHeightForFontUnits()`) _before_ the line-height actually gets applied (in `BuilderCustom::applyValueLineHeight`.

[Tim Nguyen (:ntim)]

"line-height" needs to become one of the "high-priority" properties in CSSProperties.json so it computes before background and friends, ... but also line-height needs to compute after `font-size` since `line-height` depends on font properties.

[Tim Nguyen (:ntim)]

I'll take this, I think what I'll do is remove the concept of high/top priority properties since it's more complicated than just 3 buckets of properties. Then rework StyleBuilder code to apply properties in the needed order.

[Tim Nguyen (:ntim)]

Maybe a quick fix for this that doesn't involve refactoring most of this code is to use:
```
"high-priority": true,
"sink-priority": true,
```

So it's high-priority, but still at the end of the bucket. If this works, I'll land this first and file a new bug for the refactoring.

[alan]

bug 265287

[Tim Nguyen (:ntim)]

(In reply to Tim Nguyen (:ntim) from comment #9)
> Maybe a quick fix for this that doesn't involve refactoring most of this
> code is to use:
> ```
> "high-priority": true,
> "sink-priority": true,
> ```
> 
> So it's high-priority, but still at the end of the bucket. If this works,
> I'll land this first and file a new bug for the refactoring.

This seems to fix both:
https://bugs.webkit.org/attachment.cgi?id=468741
https://bugs.webkit.org/attachment.cgi?id=469316

I'll dupe this bug to bug 265287.

*** This bug has been marked as a duplicate of bug 265287 ***