Closed Bug 1747690 Opened 2 years ago Closed 2 years ago

[css-text-decor] Dotted text decorations show partial dots on element boundaries

Categories

(Core :: Graphics: Text, defect)

defect

Tracking

()

RESOLVED FIXED
97 Branch
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.

Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core

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.

Status: UNCONFIRMED → NEW
Component: CSS Parsing and Computation → Graphics: Text
Ever confirmed: true

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: nobody → jfkthame
Status: NEW → ASSIGNED

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.)

(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.

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
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

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.

Flags: needinfo?(jfkthame)
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
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8dc5511bb9ad
followup, adjust fuzzy() number for wrench reftest.
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: