Bug 274790 – REGRESSION (268128@main): Floating elements can be split across columns

• Component: Layout and Rendering
• Status: NEW

[Brad Andalman]

Created attachment 471529 [details]
HTML that shows a drop cap split across two columns

We use “float: left” and a large font-size to implement drop caps. Recently, we’ve noticed that these drop caps can sometimes be split across a column, which looks quite bad.

I’ve attached some HTML that exhibits the bug in Safari 17.5. I’ll also attach a screenshot that shows the failure in Safari, contrasted with Chrome, which renders it correctly.

This bug also appears in Safari Technology Preview Release 195, but does *not* appear in Safari 17.2.1. So, this appears to be a relatively recent regression.

[Brad Andalman]

Created attachment 471530 [details]
Render of the HTML in Safari 17.5 and Chrome

[Radar WebKit Bug Importer]

<rdar://problem/128881044>

[Karl Dubost]

Brad, Thanks a lot for the testcase. Very useful.
I can confirm this is a regresssion.
I'm starting a regression testing.

[Karl Dubost]

This has been regressed by bug 261683
https://github.com/WebKit/WebKit/commit/c28da984b5ca8fb4bf7941f1b932dd6dd92c0724

[Brad Andalman]

Created attachment 471557 [details]
HTML for same underlying bug, but different appearance

I’m attaching new HTML that looks like the same underlying bug. This HTML is almost the same, but 1) uses a more “reasonable” line-height and 2) changes the column height slightly.

When you open this in Safari 17.5, the drop cap appears entirely in the first column, but there is still an incorrect space in the second column (presumably where WebKit layout thinks the drop cap should appear).

I’ll attach screenshots shortly.

[Brad Andalman]

Created attachment 471558 [details]
Rendering of new HTML in Safari 17.5 and Chrome

Here is a comparison of Safari 17.5 and Chrome. I’ve highlighted the incorrect behavior in Safari. And you can see that, in Chrome, the drop cap fits in the first column and doesn’t affect the second column.

[Brad Andalman]

Created attachment 471559 [details]
Rendering of new HTML in Safari 17.2.1

In this screenshot, you can see the old behavior in Safari. It’s preferable to the current behavior, but this version of Safari deems the drop cap too large to fit in the first column and moves it to the second.

It feels like the Chrome behavior is correct (though the old Safari behavior seems justifiable).

[Brad Andalman]

Since this regression is a big deal for our application, we were wondering if there is a way to detect this bug and workaround it (until a real fix is available).

Is there any way you can tell me how the height for the drop cap is calculated currently (in this broken state)? For instance, I tried getting the bounding rect of the span that contains the drop cap, but that doesn’t equal the height of the letter. I’ve tried to figure out the height by using some combination font-metrics and font-size, but I haven’t figured it out exactly yet (and am worried that might be going down the wrong path).

Any advice would be much appreciated!

[Karl Dubost]

I don't think there's an easy way to detect this unfortunately. :(

[Brad Andalman]

I was afraid you might say that! Oh well.

I also found another case (involving widows) that seems related to this bug. To be sure, I’ll attach some example HTML shortly.

[Brad Andalman]

Created attachment 471580 [details]
Bad layout in second column due to widows

If you comment out the “widows: 5” CSS in the attached HTML, you can see that two lines fit below the drop cap. With that “widows: 5”, though, those two lines move to the second column. And while there are five lines in the second column now, the inset due to the (phantom) drop cap persists.

In Safari 17.2.1 (and in Chrome), that drop-cap indentation doesn’t appear.

[Brad Andalman]

Created attachment 471581 [details]
Rendering of bad layout due to widows in Safari 17.5

[Karl Dubost]

Thanks a lot for all the test cases. That will help to solve the issue.

[Antti Koivisto]

The issue in first case appears to be paint, not layout. Overflowing content wrongly paints in the first column while clipping in the second but everything is in a right place.

[Antti Koivisto]

Basically this used to avoid visual split because the layout was wrong. We pushed the first line on second column down so there was no overflow. Now we have correct layout but the overflowing part shows up on the previous page.

[Brad Andalman]

Thanks for taking a look at the first case (https://bug-274790-attachments.webkit.org/attachment.cgi?id=471529).

Since that failure is due to an issue with paint, should I file a separate bug? Because the second issue (https://bug-274790-attachments.webkit.org/attachment.cgi?id=471557) feels like it might actually be a layout issue.

Lastly, the third issue (https://bug-274790-attachments.webkit.org/attachment.cgi?id=471580) — the one related to widows — must also be different. It’s now fixed in Safari Technology Preview, while the other two cases are not.

Apologies for lumping these three cases together. From my perspective, they certainly appeared to be related!

[Antti Koivisto]

I think we can keep them here for now until I figure out how to handle this.

[Brad Andalman]

Comment on attachment 471580 [details]
Bad layout in second column due to widows

Marking this obsolete, as this no longer happens in Safari 18.1.

[Brad Andalman]

Comment on attachment 471581 [details]
Rendering of bad layout due to widows in Safari 17.5

Marking this obsolete, as this no longer happens in Safari 18.1.

[Brad Andalman]

I obsoleted two attachments, since the case they were hightlighting (see comment #11) no longer occurs in Safari 18.1.

However, the issue with the split drop cap still persists in Safari 18.1. You can even see it in Apple Books (version 7.1) on Sequoia 15.1. This does not happen on Ventura, in Apple Books 5.2.

[Brad Andalman]

Created attachment 473090 [details]
Screenshot of Apple Books 7.1 on Sequoia showing split drop cap