The obvious: What is the stacking order of inset shadows wrt stroke?

As an author, I agree with @smfr that putting the inset shadows between stroke and fill would be the expected stacking order. The reason is that the shadows are used to style the inner part of the text while the stroke is an outline for the text.

• Less obvious: Are text decorations composited with their text before being shadowed?

Here's a fun test case. From an authoring perspective, I think I'd expect the shadow to have a consistent color throughout...

But if we composit the text and the decorations together for shadowing, we can't say that the inset shadows are between the stroke and fill since text and decorations are stroked independently.

Again, from an author's perspective, you'd expect the inset shadows to be between fill and stroke. And I agree that outset shadows are expected to not overlap.
That means, from a specification and implementation perspective inset and outset need to be handled differently. For inset shadows, they'd need to be drawn before compositing text and decorations and their fills and strokes and for outset shadows, text and decorations including their fills and strokes should be composited first.

Having said that, current implementations (tested your example in Chrome 101 and Firefox 100) obviously do not composite text and decorations - and are thus not following the spec. - and ignore the stroke for outset shadows (tested with -webkit-text-stroke because browsers don't implement stroke yet).

Sebastian

The CSS Working Group just discussed composition of inset shadows.

In discussing this with @fantasai after the call, this mental model struck me — for strokes, strikethroughs , insets & other such shadows.

Imagine we are making signs to carry in a protest or parade. We decide to cut out giant letters in cardbaord (to be carried separately by separate people or something). For some reason, we've got strikethroughs (cut out of the same cardboard, not separate pieces taped on later). We decide to paint these letters in bright yellow with a neon blue stroke. Then we go out into the sun. And there's a shadow. What does that shadow do? That's what we should do.

My understanding from discussing with @jensimmons was that it made the most sense from an authoring perspective to composit text, including its decorations and stroke, and then to shadow that, both for outset shadows and for inset shadows. So I think this is the proposal.

The CSS Working Group just discussed [css-text-decor-4] Composition of inset shadows.

Idle thought - could/should we add decoration and shadow to paint-order?

I workmate created a mockup for me showing two different approaches regarding text decorations.

It shows several things:

• The paint order is fill, then shadow(s), then stroke. But SVG defines a paint-order property which lets you change the order of fill and stroke. (This property seems to apply to HTML elements as well.) In that case the order would be stroke, fill, shadow(s).
• The point above emphasizes that the text shadow should start at the edge of the fill and not be influenced by the stroke's edge. If people want the shadow to start at the stroke's edge, they can specify a spread radius.
• The upper example shows what I meant in my previous comment. I.e. first the shadows are painted, then the compositing happens. Or more precisely, the paint order and composition steps (for line-through) are
    1. fill of text
    2. inset text shadows of text
    3. stroke of text
    4. fill of decoration
    5. inset text shadows of decoration
    6. stroke of decoration
    7. composite everything
  The order of 1-3 and 4-6 varies between decorations as some are painted below the text, others above. And as noted earlier, the order may also be influended by the paint-order property.
• The lower example composites first and then applies the shadows. The steps for that are
    1. fill of text
    2. fill of decoration
    3. composite those two
    4. inset text shadows of composition
    6. stroke of composition
    7. composite everything
  Here, the order of 1 and 2 vary depending on the type of decoration. And again, the paint-order property might change the order of the steps, too.

The mockup doesn't show an outset shadow but that would be painted in an eighth step. Though the order would be first the shadow then the composition.
I know this would complicate the rendering and goes against the current definition of the painting order, though I believe that's what authors expect and what provides the best results.

@jensimmons I can't completely follow your example but I assume you mean the lower one. Please correct me if I'm wrong.
Though after bringing up this real life example, a photo of you standing in the sun and holding some giant letters cut out of a cardboard to illustrate what you wrote would make my day! 😆

Sebastian

@SebastianZ That's helpful, thanks! However, the problem is that stroke is implemented on each letter and each text-decoration separately, not on the whole thing. So we can't actually get the second rendering you have. If you remove the stroke, or if you overlay the shadow on the stroke and fill together, then that's a rendering that's actually possible. Jen Simmons and I were arguing that this, while not what you have exactly, is still a better option than the first one.

I have been playing around with this a bit today, and I am not sure it makes sense to create inset shadows from a combination of glyphs and decorations. It is certainly hard to do (beyond my skills, at least) in Illustrator. I have asked for help.

Here are separate shadows:

For a combined effect I guess there would be more shadowing in the yellow areas off the top of the strikethough? I don’t think I would want that.

Dumb smudging of shadows on it:

I have to admit I read through last call's discussion just now.

fantasai: Prop: Composite the text, stroke, and decoration and then shadow it for both types of shadow
fantasai: I think that' b/c when you have no stroke then you want to composite and that's more common than stroking text
jensimmons: Agree without stroke everything composites together and then shadow

I am strongly opposed to first compositing fill and stroke before shadowing. That would mean the shadow is painted above the stroke, covering it.
Authors definitely expect the stroke to be above fill and shadows. And it looks like @smfr and others agree with that.

smfr: Text stroke doesn't apply to decorations?
+1 to smfr adding inset shadow between fill and stroke
fantasai: Can't remember. I think text stroke...I can't remember

Checking using -webkit-text-stroke, Chromium and WebKit do apply the color of the text stroke to decorations but not the stroke itself. Gecko doesn't apply it to decorations. See this example.
In my opinion, strokes should apply to decorations as well.

However, the problem is that stroke is implemented on each letter and each text-decoration separately, not on the whole thing. So we can't actually get the second rendering you have. If you remove the stroke, or if you overlay the shadow on the stroke and fill together, then that's a rendering that's actually possible. Jen Simmons and I were arguing that this, while not what you have exactly, is still a better option than the first one.

I don't have a strong opinion on which rendering is better. @astearns' examples obviously match my first rendering (with text and decoration being separated). My second rendering is definitely more legible, though that's probably just because of the font used and the position of the strike-through.

@fantasai @jensimmons As far as I know, stroke as doesn't have any standards compliant implementations yet. So are your statements about what's possible based on -webkit-text-stroke?

Sebastian

@SebastianZ You have to consider what's more common: using text-shadow on text with a stroke and no decorations, or on text with decorations and no stroke. You're trying to optimize the former at the expense of the latter, but I think the latter is far more common.

And for decorated, unstroked text, I think the right answer is pretty clear: we want the decoration and the text composited before being shadowed. Drawing the shadows independently over the text and the line decoration looks weird and wrong.

Since text stroke is sandwiched between the decoration (which is drawn over it) and the text fill (which is drawn under it), getting the common cases right requires compositing the stroke with the text before shadowing it.

As for whether for stroked, undecorated text the shadow should be inside the stroke or over it: @jensimmons asserts that both renderings could be desirable. But only one of them is compatible both with handling decorations and with how we handle outer shadows, so by default I think that's what we have to do.

@SebastianZ You have to consider what's more common: using text-shadow on text with a stroke and no decorations, or on text with decorations and no stroke. You're trying to optimize the former at the expense of the latter, but I think the latter is far more common.

I can't tell what will be used more often. Of course, text with decorations is far more common than text with strokes. Though I assume that strokes will be much more common in combinatino with other stylistic ways to emphasize text like inset shadows.

And for decorated, unstroked text, I think the right answer is pretty clear: we want the decoration and the text composited before being shadowed. Drawing the shadows independently over the text and the line decoration looks weird and wrong.

I don't agree with you that there's a clear preference for one of the variants. Especially when the decoration has a different color than the text, it might look better the to shadow text and decoration independently. And again, this is for inset shadows. Outset shadows should definitely be drawn after compositing text and decorations to avoid the overlapping shown in the example of your initial post.

Though I believe we should provide some more renderings for that to show the differences. With them it will probably be easier to decide on that.

Since text stroke is sandwiched between the decoration (which is drawn over it) and the text fill (which is drawn under it), getting the common cases right requires compositing the stroke with the text before shadowing it.

From that and the previous paragraph, I guess the rough rendering steps you suggest are

1. fill of text
2. stroke of text
3. fill of decoration
4. stroke of decoration
5. composite everything
6. outset shadows and above them everything composited
7. inset shadows

Is that correct? (Note that these steps don't fully reflect the paint order. They outline the order in which rendering happens.)

As for whether for stroked, undecorated text the shadow should be inside the stroke or over it: @jensimmons asserts that both renderings could be desirable.

And I assert that only that only the rendering with stroke above the shadow is desirable.
Though we should provide some renderings for that as well, so the differences become obvious.

Sebastian

One way to move forward here would be to declare that inset shadow interactions with text decorations is unspecified. Indeed, https://www.w3.org/TR/fill-stroke-3/#text-decor says that text decoration fill and stroke (may) get their own properties, so it might be reasonable to say that text decorations don't affect inset shadows on text, or are shadowed independently.

it might look better the to shadow text and decoration independently

For inset shadows, this will look very unnatural. Try it.

Fundamentally shadows is about creating a "cut-out" effect, where the text is lifted above or shifted below the canvas. It doesn't work if you shadow text and its decorations independently, whether for inset shadows or for outset shadows.

Including the stroke in the cutout may or may not be what you want, but it's at least consistent with that model. Shadowing decorations independently is not.

The CSS Working Group just discussed Composition of Inset Shadows.

I think this is what @fantasai was proposing in the meeting this morning, but I could be wrong.

I think this is what @fantasai was proposing in the meeting this morning, but I could be wrong.

The interruptions in the shadow along the line-through really bug me. I’d almost prefer the inverse, which would give the impression of the letter forms casting shadows onto the line-through.

Some discussion in the WebKit rendering team came to the conclusion that anything other than the top line in #7251 (comment) would be very hard to implement. I think we either leave this undefined (and see if any browser does something more complex), or we specify that inset shadows for glyphs and text decorations do not interact.

In addition, the issue was raised that large shadow offsets can cause the inset shadow to "leak" into adjacent glyphs, adjacent inline elements, or adjacent lines. That implies that we may need some spec text that describes whether any of those things should happen.

I think we either leave this undefined (and see if any browser does something more complex), or we specify that inset shadows for glyphs and text decorations do not interact.

As the results differ a lot and inset shadows for texts will probably mostly be used on large text, it should probably be defined. Though I also assume we are actually discussing some edge cases here with decorations overlapping the text (significantly) because authors will presumably rather use inset text shadows on undecorated text. Or, if it's decorated, they'll rather use underlining which has ink skipping applied by default. So maybe it would be fine to leave this undefined. Though that are just assumptions from my side.

@smfr Can you also share some insights on whether it's easier to draw the shadow above the stroke or between stroke and fill?

In addition, the issue was raised that large shadow offsets can cause the inset shadow to "leak" into adjacent glyphs, adjacent inline elements, or adjacent lines. That implies that we may need some spec text that describes whether any of those things should happen.

Of course, from an author's point of view, the inset shadows should stay within the glyph even with large offsets. If that's technically feasible is the question here. It would probably mean that the inset shadow needs to be rendered for each glyph individually and then be clipped.

Sebastian