Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jfkthame opened this issue Feb 14, 2023 · 2 comments

Comments

@jfkthame
Copy link
Contributor

jfkthame commented Feb 14, 2023

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

@longsonr
Copy link

longsonr commented Feb 7, 2024

Presumably if you set a color to be non-opaque and the shadow colour to also be non-opaque the shadow's actual opacity would be the product of those opacities.

@tabatkins
Copy link
Member

tabatkins commented Feb 8, 2024

Using color: transparent + a text-shadow with blur is a not-uncommon effect for drawing blurry text. Applying the text color's alpha to the shadow would break those existing usages (making the text entirely invisible).

Similarly, box-shadow doesn't care about the appearance of the box, just its geometry (and this effect is explicitly taken advantage of).

If we did want shadows to be more visual-based rather than geometry-based, it would need to be an opt-in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants