1748496 - Padding of inline elements within a pre tag is ignored

Status: UNCONFIRMED

(Core :: Layout: Block and Inline, defect)

Description

[max]

Attachment: screenshots.zip

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

I created a table with a <pre> tags as values. I tried to add padding within the <pre> tag, which did not work as expected.
Here is an example which yields different results in Firefox in Chrome: https://jsfiddle.net/spyczxg7/11/

Actual results:

The padding to the right of the <span> is completely ignored.

Expected results:

I would have expected that there is a padding on the left as well as on the right to the <span>. This would increase the width of the table. Adjusting the padding-right does not change the table width.

Comment 1

[max]

It only seems to happen if padding-left = padding-right.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Tables' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[max]

Here is an even more minimal example: https://jsfiddle.net/9jvpecbo/1/

Comment 4

[Daniel Holbert [:dholbert]]

It looks like we're honoring the newline character, and applying the padding at the right edge of the new line. (Though the new line ends up being zero-height, so it's not obvious that it's there.)

(In reply to max from comment #1)

It only seems to happen if padding-left = padding-right.

Rather, the padding exactly cancels out if padding-left == padding-right. II padding-right is a bit larger, then it looks superficially like we're adding the difference between them as right-padding (but really I think we're adding the full right padding, at the beginning of the second line, after the newline).

jfkthame, do you know who's right here?

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: reference for reduced testcase 1 (maybe?)

Here's a reference case; in Chrome, the reduced testcase renders like this. In Firefox, the reduced testcase renders with less padding than this (though as I noted above, I think really we're just applying the testcase's padding at the start of the second line, or something like that).

Comment 7

[Jonathan Kew [:jfkthame]]

I suspect what's actually happening may not quite be as comment 4 suggests. Consider this example:

data:text/html,<pre style="display:inline-block; border:1px solid gray;"><span style="padding-right:10px; outline:1px solid red">foo&%23xa;</span></pre>

The outline here shows that the padding is actually present on the first (only) line, but it projects beyond the border of the <pre> element. Inspecting the layout with the DevTools inspector agrees with this.

A similar issue would apply with border, which is :

data:text/html,<pre style="float:left;border:3px solid gray;"><span style="border-right:10px solid yellow;">foo&%23xa;</span></pre>

So it seems that the intrinsic size of the <pre> block doesn't take this border or padding into account when the inline element that has the border or padding ends with a preserved newline character.

The same also occurs with a trailing <br> in the inline:

data:text/html,<pre style="float:left;border:3px solid gray;"><span style="border-right:10px solid yellow;">foo<br></span></pre>

Comment 8

[Jonathan Kew [:jfkthame]]

Here's an example that doesn't involve any text or non-default white-space settings, but exhibits the same issue:

data:text/html,<div style="float:left; border:5px solid gray;"><span style="border-right:20px solid yellow;"><div style="display:inline-block; width:30px; height:20px; background:silver"></div><br></span></div>

I think this belongs more to Block & Inline Layout than to Text & Fonts.

It would take some study to find whether the spec explicitly discusses this precise situation; it's unclear to me what is "most correct". Interestingly, Safari's behavior seems to agree with us in these examples, so it's Blink that is the odd one out.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: (OLD version of testcase 2; disregard)

Here's a live testcase, with two different versions of the data URI from comment 8 (colors slightly tweaked for readability).

The first part of this testcase is straight from comment 8. In the second part, I've added a space character after the br.

For some reason, this whitespace makes a difference for the rendering in Firefox (introducing a visible linebreak between the two colorful rectangles). It does not make a difference in Chrome or in Safari.

(As jfkthame noted, Safari agrees with us on the top part of this testcase, but nobody agrees with us on the bottom part of this testcase; and Safari/Chrome are each in agreement with themselves about the rendering for the top vs. bottom of this testcase.)

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a new testcase, with four different versions of the data URI from comment 8 (colors slightly tweaked as well, for readability).

The first part of this testcase is essentially straight from comment 8. In the second part, I've added a space character after the br. In the third part, I've added a space character after the </span> close tag. In the fourth part, I've got space characters in both of those spots.

Interestingly:

• the space character after the br makes a difference (it introduces a linebreak) in Firefox, but not in other browsers.
• the space character after the span makes a difference (it causes the yellow border to disappear) in WebKit but not in other engines.

So:

• Chrome renders all four sections the same in this testcase.
• Firefox has two renderings here; it renders sections #1 and #3 on one way, and sections #2 and #4 a different way.
• Safari has two renderings here; it renders sections #1 and #2 on one way, and sections #3 and #4 a different way.
• Safari agrees with Firefox on section #1 here; beyond that, there's no agreement among any pair of browser engines on how any of the other sections look in this testcase.