w3c / w3c/csswg-drafts

[css-text-decoration] Clarify interaction between text-shadow, stroke, (partial or complete) color transparency, and element opacity

Open
#8,449 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

css-text-decor-4
Dominant language
Bikeshed
Stars
4.9k
Forks
816
PR merge metrics
PR metrics pending

Description

The spec for text-shadow doesn't go into much detail about how text-shadow behaves with respect to other painting effects that may be present. Currently, there's a lack of interoperability between browsers here.

In particular, if the text uses color: transparent and [-webkit-]text-stroke to paint an "outline" font instead of solid glyphs, it seems natural to me that any text-shadow in effect should cast a shadow of the glyph outlines, not of the (invisible) solid shapes.

Currently, none of Firefox/Chrome/Safari appear to do this for HTML text; the invisible glyphs cast a solid shadow. I think this is wrong/unexpected. (Note that for SVG text that is stroked and not filled, both Chrome and Safari do shadow only the stroke; Firefox is currently quite buggy in this area.)

(Interestingly, Safari does include the geometry of the stroke in what's shadowed for HTML text, so a thick stroke will result in an enlarged shadow, whereas Chrome and Firefox appear to ignore the stroke altogether and shadow only the original glyph geometry. So in this regard, Chrome and Firefox are interoperable, but I think their result is not what an author would expect.)

Given that (in my view) it is "clearly right" (what an author would want/expect) to shadow only the stroke when the fill color is transparent, I think it also follows that if the fill color has partial transparency, that same transparency should apply to the shadow. The shadow color could, of course, be partially transparent itself; but the transparency of the thing being shadowed should also be taken into account. This would be particularly necessary if, for example, we have text with a solid stroke (which will thus get a "solid" shadow) and a fill that is transitioning between transparent and opaque colors. The shadow cast by the fill should intuitively follow the same transition: as the shape casting the shadow becomes opaque, so its shadow intensifies.

I've put a few examples at https://codepen.io/jfkthame/pen/LYJYRPd. In each line here, there are two copies of the text: the first uses text-shadow, and then it is followed by a version where I have simulated the rendering that I believe would be expected.

My assessment of current browser behaviors on each of the examples in the codepen:

     Firefox  Chrome  Safari
(1)  fail     fail    fail
(2)  fail     fail    fail
(3)  fail     fail    fail
(4)  pass     pass    fail*

*I think Safari's rendering of (4) would be a correct result for (3).

So my primary question here is whether we can agree on the expected behaviors here; in particular, that stroked text should cast a shadow of the stroke (and not of its transparent fill). If so, we all have some bugs to fix. (And the spec should be explicit about the interactions.)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked text-shadow specification and the CodePen examples, then compare the reported Firefox, Chrome, and Safari behavior for stroked and transparent text. Done means the expected interaction between text-shadow, text-stroke, fill transparency, and element opacity is agreed and documented explicitly in the specification.

Written by the indexing model from the issue text.

Assessment

Tech stack
css, html
Domain
documentation, web-dev
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.