WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
278788
text-shadow is affected by text stroke
https://bugs.webkit.org/show_bug.cgi?id=278788
Summary
text-shadow is affected by text stroke
EPRC
Reported
2024-08-28 06:20:33 PDT
Created
attachment 472325
[details]
Rendering issue on webkit’s annoucement of the feature support (left: Firefox, right: Safari) Hi, I noticed two rendering issues with -webkit-text-stroke: one on webkit’s annoucement of the feature support (
https://webkit.org/blog/85/introducing-text-stroke/
, see the text-shadow mixed with text-stroke) and the other in a current project of ours where I noticed the stroke had some sort of "bias" towards the right of the letters. See attachments for a comparison between Firefox (left) and Safari (right) I’m on a Mac Mini M2 Pro with MacOS 13.6 and Safari 17.6
Attachments
Rendering issue on webkit’s annoucement of the feature support (left: Firefox, right: Safari)
(1.51 MB, image/png)
2024-08-28 06:20 PDT
,
EPRC
no flags
Details
Stroke bias on the left. Two different fonts (left: Firefox, right: Safari)
(884.47 KB, image/png)
2024-08-28 06:23 PDT
,
EPRC
no flags
Details
testcase
(541 bytes, text/html)
2024-09-03 22:05 PDT
,
Karl Dubost
no flags
Details
rendering in safari, firefox, chrome
(148.46 KB, image/png)
2024-09-03 22:08 PDT
,
Karl Dubost
no flags
Details
Illustrative test case
(701 bytes, text/html)
2024-09-04 10:27 PDT
,
Simon Fraser (smfr)
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
EPRC
Comment 1
2024-08-28 06:23:41 PDT
Created
attachment 472326
[details]
Stroke bias on the left. Two different fonts (left: Firefox, right: Safari) I forgot to mention in my initial post that this “bias” is occuring when using the css property paint-order with the value “stroke fill”
Karl Dubost
Comment 2
2024-09-03 22:05:47 PDT
Created
attachment 472435
[details]
testcase For references, these are defined in
https://compat.spec.whatwg.org/#text-fill-and-stroking
A simplified test case.
Karl Dubost
Comment 3
2024-09-03 22:08:40 PDT
Created
attachment 472436
[details]
rendering in safari, firefox, chrome The difference I see in between the three browsers is that Safari has a stronger shadow than others. Probably it would be better to define a unique font too for this test.
Karl Dubost
Comment 4
2024-09-03 22:12:08 PDT
I have the feeling this is more a rendering issue than a text issue. I have tested on Safari Technology Preview 202 20620.1.4.8 Firefox Nightly 131.0a1 13124.8.29 Google Chrome Canary 130.0.6696.0 6696.0
Radar WebKit Bug Importer
Comment 5
2024-09-04 06:21:14 PDT
<
rdar://problem/135268743
>
Simon Fraser (smfr)
Comment 6
2024-09-04 10:22:39 PDT
I think the question here is what should get shadowed. Should we just be rendering the shadow based on the stroked forms, or on the filled forms, or on both stroked and filled forms?
Simon Fraser (smfr)
Comment 7
2024-09-04 10:27:01 PDT
Created
attachment 472448
[details]
Illustrative test case
EPRC
Comment 8
2024-09-04 10:53:24 PDT
(In reply to Karl Dubost from
comment #4
)
> I have the feeling this is more a rendering issue than a text issue.
There are indeed two bugs in one, should I file another bug regarding the paint-order stroke “bias”? (see
attachment 472326
[details]
) (In reply to Simon Fraser (smfr) from
comment #6
)
> I think the question here is what should get shadowed. > > Should we just be rendering the shadow based on the stroked forms, or on the > filled forms, or on both stroked and filled forms?
Chrome/Firefox seem to both render the shadow based on the filled forms regardless. Personally I would assume it should be based on the stroked forms if -webkit-text-fill-color is transparent and then both stroked and filled forms when it’s not
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug