NEW 230339
tab width is computed incorrectly for inline elements with font changes 
https://bugs.webkit.org/show_bug.cgi?id=230339
Summary tab width is computed incorrectly for inline elements with font changes
Jonathan Kew
Reported 2021-09-16 04:00:10 PDT
The CSS spec (https://drafts.csswg.org/css-text-3/#tab-size-property) for tab-size is clear that > A <number> represents the measure as a multiple of the advance width of the space character (U+0020) of the nearest block container ancestor of the preserved tab, but webkit appears to be using the advance width of the inline element's own space character, not the block container's. See testcase at https://codepen.io/jfkthame/pen/JjJMoqN. Firefox renders this correctly per spec.
Attachments
Add attachment proposed patch, testcase, etc.
Kevin Neal
Comment 1 2021-09-21 10:33:02 PDT
Thank you for filing. The appropriate engineers have been notified.
Radar WebKit Bug Importer
Comment 2 2021-09-21 10:33:17 PDT
<rdar://problem/83358190>
Myles C. Maxfield
Comment 3 2021-09-21 11:07:17 PDT
I wonder why... 🤔
Ahmad Saleem
Comment 4 2022-08-29 07:22:13 PDT
I am able to reproduce this bug in Safari Technology Preview 152 using CodePen from Comment 0 and it does not align "A" in one line and it matches with Chrome Canary 107. Only browser (Firefox Nightly 106) show all "A" aligned in one line. Just wanted to share updated test results. Thanks!
zalan
Comment 6 2023-09-28 08:02:49 PDT
(In reply to Myles C. Maxfield from comment #3) > I wonder why... 🤔 It's because tab width is resolved against the current FontCascade and not what the (nearest) block container specifies. e.g. <div style="tab-size: 10; font-size: 100px;"><span style="font-size: 1px"> In WidthIterator we use the [span]'s font to resolve the tab-size value of 10. At WidthIterator we don't have the context of containing blocks we just have a font (whatever the inline box has) and the specified tab-size value.
Note You need to log in before you can comment on or make changes to this bug.