1323317 - vertical-align: text-bottom allocates 1 pixel below element in container

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Stuart P. Bentley]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36

Steps to reproduce:

See test case at https://bugs.webkit.org/attachment.cgi?id=197626

The red one-pixel gap between the top and bottom square should not be present.





Actual results:

vertical-align: text-bottom results in one additional pixel of height in the element's container. See https://bugs.webkit.org/attachment.cgi?id=197628

This issue is also present in WebKit: http://wkbug.com/114449

This issue is also present in Blink: http://crbug.com/331018


Expected results:

Using vertical-align: text-bottom should work like vertical-align: bottom, in that it doesn't calculate additional space beneath the element. See https://bugs.webkit.org/attachment.cgi?id=197629

This is the exhibited behavior in Microsoft Edge, where this issue is NOT present.

Comment 1

[Stuart P. Bentley]

So as to not rely on WebKit's foreign issue tracking attachments, I've mirrored the test case to https://testcases.github.io/text-bottom-space/index.html along with the expected/actual screenshots:

- Expected: https://testcases.github.io/text-bottom-space/expected.png
- Actual: https://testcases.github.io/text-bottom-space/actual.png

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

While I don't see the gap, I also don't think your assumption is valid.

As described in https://drafts.csswg.org/css2/visudet.html#inline-non-replaced , inline elements have two concepts of height:
  (1) a visual height where the content height is derived from the font, and then padding/border/margin go around that.  This is used for background, border, etc.

  (2) a logical height, used for placement.  The height of this one comes from 'line-height'.  If 'line-height' is different from (1), then half the difference (the half leading) is added on each side of the box for (1).  This is used to determine the extents that contribute to the height of the line.

Note that in your testcase the line height is 'normal', which can mean almost anything, and in many cases derives from metrics in the font.  Given that your testcase uses system fonts, I would expect different results for 'normal' depending on the OS and on the default fonts.

The definition of text-bottom aligns to the type (1) height of the parent inline.  Since the SVG (the black square) is taller than the text (by a lot, given the default 16px font size), the top of the line box is even with the top of the SVG, but the bottom of the line box is the bottom of the logical height of the text derived from height (2), while the bottom of the SVG is even with height (1).

Thus I don't see a reason to think there's a bug here.  The fact that the issue is also present in Blink and WebKit agrees with that assessment.