Bug 1866828 Comment 11 Edit History

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

Here's a reduced testcase to help illustrate what's going on here:
```
data:text/html,<!DOCTYPE html><div style="font-size: 60px; border: 1px solid black"><span style="font-size:16px; background: orange">Text</span>
```

The outer `div` here is similar to the body in your attached testcase; it has a font that happens to be larger than the child's font (explicitly so due to a large font-size in this reduced testcase.  In your testcase, it depends on the metrics of the browser's chosen default font).

The inner `span` here is similar to the inline-grid in your attached testcase; it's an inline-level element with a relatively smaller font (though really the distance-from-the-top-to-the-baseline is what matters).

This results in the `span` being shifted down by some arbitrary-ish amount in order to snap to the baseline of the line box that it participates in.  We can avoid that by making its container use the same font/font-size, or by giving the span `vertical-align:top`.
Here's a reduced testcase to help illustrate what's going on here:
```
data:text/html,<!DOCTYPE html>
<div style="font-size: 60px; border: 1px solid black">
<span style="font-size:16px; background: orange">Text</span>
```

The outer `div` here is similar to the body in your attached testcase; it has a font that happens to be larger than the child's font (explicitly so due to a large font-size in this reduced testcase.  In your testcase, it depends on the metrics of the browser's chosen default font).

The inner `span` here is similar to the inline-grid in your attached testcase; it's an inline-level element with a relatively smaller font (though really the distance-from-the-top-to-the-baseline is what matters).

This results in the `span` being shifted down by some arbitrary-ish amount in order to snap to the baseline of the line box that it participates in.  We can avoid that by making its container use the same font/font-size, or by giving the span `vertical-align:top`.
Here's a reduced testcase to help illustrate what's going on here:
```
data:text/html,<!DOCTYPE html>
<div style="font-size: 60px; border: 1px solid black">
<span style="font-size:16px; background: orange">Text</span>
```

The outer `div` here is similar to the body in your attached testcase; it has a font that happens to be larger than the child's font (explicitly so due to a difference in `font-size`, in this reduced testcase.  In the WPTs and in your testcase, the `font-size` is presumably the same and the difference is not as severe; it's just dependent on the metrics of the browser's chosen default font, as compared to Ahem).

The inner `span` here is similar to the inline-grid in your attached testcase; it's an inline-level element with a relatively smaller font (though really the distance-from-the-top-to-the-baseline is what matters).

This results in the `span` being shifted down by some arbitrary-ish amount in order to snap to the baseline of the line box that it participates in.  We can avoid that by making its container use the same font/font-size, or by giving the span `vertical-align:top`.
Here's a reduced testcase to help illustrate what's going on here:
```
data:text/html,<!DOCTYPE html>
<div style="font-size: 60px; border: 1px solid black">
<span style="font-size:16px; background: orange">Text</span>
```

The outer `div` here is similar to the body in your attached testcase; it has a font that happens to be larger than the child's font (explicitly so due to a difference in `font-size`, in this reduced testcase.  In the WPTs and in your testcase, the `font-size` is presumably the same and the difference is not as severe; the line-box sizing mismatch just dependent on the metrics of the browser's chosen default font, as compared to Ahem).

The inner `span` here is similar to the inline-grid in your attached testcase; it's an inline-level element with a relatively smaller font (though really the distance-from-the-top-to-the-baseline is what matters).

This results in the `span` being shifted down by some arbitrary-ish amount in order to snap to the baseline of the line box that it participates in.  We can avoid that by making its container use the same font/font-size, or by giving the span `vertical-align:top`.
Here's a reduced testcase to help illustrate what's going on here:
```
data:text/html,<!DOCTYPE html>
<div style="font-size: 60px; border: 1px solid black">
<span style="font-size:16px; background: orange">Text</span>
```

The outer `div` here is similar to the body in your attached testcase; it has a font that happens to be larger than the child's font (explicitly so due to a difference in `font-size`, in this reduced testcase.  In the WPTs and in your testcase, the `font-size` is presumably the same and the difference is not as severe; the line-box sizing mismatch just dependent on the metrics of the browser's chosen default font, as compared to Ahem).

The inner `span` here is similar to the inline-grid in your attached testcase; it's an inline-level element with a relatively smaller font (though really the distance-from-the-top-to-the-baseline is what matters).

This results in the `span` being shifted down by some arbitrary-ish amount in order to snap its baseline to the baseline of the line-box that it participates in.  We can avoid that shift by giving it and its container the same font styling, or by giving the span `vertical-align:top`.
Here's a reduced testcase to help illustrate what's going on here:
```
data:text/html,<!DOCTYPE html>
<div style="font-size: 60px; border: 1px solid black">
<span style="font-size:16px; background: orange">Text</span>
```

The outer `div` here is similar to the body in your attached testcase; it has a font that happens to be larger than the child's font (explicitly so due to a difference in `font-size`, in this reduced testcase.  In the WPTs and in your testcase, the `font-size` is presumably the same and the difference is not as severe; the line-box sizing mismatch just dependent on the metrics of the browser's chosen default font, as compared to Ahem).

The inner `span` here is similar to the inline-grid in your attached testcase; it's an inline-level element with a relatively smaller font (though really the distance-from-the-top-to-the-baseline is what matters).

This results in the `span` being shifted down by some arbitrary-ish amount in order to snap its baseline to the baseline of the line-box that it participates in.  We can avoid that shift by giving it and its container the same font styling, or by giving the span `vertical-align:top` to opt out of baseline alignment within its line-box.

Back to Bug 1866828 Comment 11