[css-text-decor] Dotted text decorations show partial dots on element boundaries
Categories
(Core :: Graphics: Text, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox97 | --- | fixed |
People
(Reporter: rego, Assigned: jfkthame)
Details
Attachments
(4 files)
Steps to reproduce:
Just open the next example:
data:text/html,<div style="font-size: 116px; text-decoration: dotted green underline;">foo<strong>bar</strong>baz</div>
Or the following codepen: https://codepen.io/mrego/pen/qBPpdKj
Actual results:
There are partial dots between "foo" and "bar".
In the codepen that has an animation based on letter-spacing, the issue is quite noticeable.
Expected results:
There shouldn't be partial dots.
The animation in the codepen should work like the ones for dashed and wavy text decorations.
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 1•2 years ago
|
||
Comment 2•2 years ago
|
||
Haven't dug if the issue is more on webrender's side or on layout, but this seems like a more appropriate component than CSS.
Assignee | ||
Comment 3•2 years ago
|
||
This is a change/regression from enabling webrender; if I run an older build where I can force-disable WR, that avoids the issue.
It occurs because of the code here, which aims to avoid painting a partial dot at the end of a line. While this might be desirable at the end of an entire decoration line, it has the unfortunate effect of creating gaps when (as in the examples here) the line is drawn in parts because it crosses multiple inline elements, and the frame boundaries fall mid-dot.
While avoiding a partial dot at end-of-line may be desirable, I think this result is visually more jarring, and so the result is a net negative. If we're going to do this kind of adjustment, it needs to be at a higher level where we know whether the "edge" being clipped is in fact the end of the entire line, rather than potentially a boundary between adjacent segments that should touch.
Assignee | ||
Comment 4•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
Incidentally, it's not even necessary to have element boundaries for this issue to show up; it also occurs at bidi boundaries, e.g. in
data:text/html;charset=utf-8,<div style="font: 99px Arial; text-decoration: dotted red underline;">foo%D7%A9%D7%9C%D7%95%D7%9Dbaz</div>
The exact font & size needed to exhibit bad rendering may vary depending on platform font rendering/metrics details; this example shows glitches at both direction-run boundaries for me on macOS.
(FWIW, these examples look even worse in Chrome, because it doesn't implement the "decorating box" concept but decorates each run independently.)
Reporter | ||
Comment 6•2 years ago
|
||
(FWIW, these examples look even worse in Chrome, because it doesn't implement the "decorating box" concept but decorates each run independently.)
Yeah Chromium and WebKit don't implement "decorating box" and have way worse issues than Firefox.
I just reported this Firefox issue, as the rest was working nicely and got surprised that dots had some special thing. But indeed other browsers have more problems.
Assignee | ||
Comment 7•2 years ago
|
||
The CSS-text-decoration spec doesn't explicitly say anything about maintaining the dotted-line pattern
continuously across direction-run or inline-element boundaries, which is what this is testing,
but I think that follows from the fact that in each example here, there is a single "decorating box"
involved (and not separate, independently-decorated boxes for each direction-run or span).
Depends on D134783
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1e61ce614f6d Don't adjust dotted-line rect in WebRender to try and avoid partial dots, because the line segment being painted may need to butt up against a continuation and we don't want a gap to appear. r=gfx-reviewers,lsalzman https://hg.mozilla.org/integration/autoland/rev/ecf8c388c151 Add WPT reftests. r=emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/32212 for changes under testing/web-platform/tests
Upstream PR was closed without merging
Comment 11•2 years ago
|
||
Backout by csabou@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/08444ec3d105 Backed out 2 changesets for wrench failures on decorations-suite.yaml. CLOSED TREE
Comment 12•2 years ago
|
||
Backed out for wrench failures on decorations-suite.yaml
Failure log: https://treeherder.mozilla.org/logviewer?job_id=362679158&repo=autoland
Backout link: https://hg.mozilla.org/integration/autoland/rev/08444ec3d105
Assignee | ||
Comment 13•2 years ago
|
||
Ah, there's a wrench test that is affected by the change. It should just need the reference .png updated, I think. Pushing a try job to check that makes it happy: https://treeherder.mozilla.org/#/jobs?repo=try&revision=896912a271d7c188b225d7f1596badb7600f5415.
Comment 14•2 years ago
|
||
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/deff91de3f89 Don't adjust dotted-line rect in WebRender to try and avoid partial dots, because the line segment being painted may need to butt up against a continuation and we don't want a gap to appear. r=gfx-reviewers,lsalzman https://hg.mozilla.org/integration/autoland/rev/d633ae4d5b6d Add WPT reftests. r=emilio
Assignee | ||
Comment 15•2 years ago
|
||
Comment 16•2 years ago
|
||
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8dc5511bb9ad followup, adjust fuzzy() number for wrench reftest.
Comment 17•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/deff91de3f89
https://hg.mozilla.org/mozilla-central/rev/d633ae4d5b6d
https://hg.mozilla.org/mozilla-central/rev/8dc5511bb9ad
Upstream PR merged by moz-wptsync-bot
Description
•