[css-text-decor-4] Text Shadow Spread Corners

[fantasai]

The current spec for text-shadow states:

unlike box-shadow, the spread distance is strictly interpreted as outset distance from any point of the glyph outline, and therefore, similar to the blur radius, creates rounded, rather than sharp, corners.

@smfr writes:

I don't think we can say that spread results in rounded corners. As an implementor I'd implement spread by increasing the stroke width, so the corners will still respect the miter limit that's used to render the glyph outlines, which could result in long spikes. This probably needs to be informed by some implementation experience.

Do we want to spec anything particular here, or leave it up to the UA for now?

[css-meeting-bot]

The CSS Working Group just discussed text shadow spread corners, and agreed to the following:

• RESOLVED: Leave text-shadow spread details undefined right now, with possibility of specification later after impl experience.

The full IRC log of that discussion

<TabAtkins> Topic: text shadow spread corners
<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7250
<TabAtkins> smfr: Issue here is that when you specify spread on a text shadow, the only way UA can implement is by stroking a line with a wider width and shadowing the result.
<TabAtkins> smfr: That has implications for corners and miters
<TabAtkins> smfr: So we need impl experience, need to implement spread on text shadow and see if there are any problems, not sure if there are right now.
<TabAtkins> astearns: I remember we specified increasing the padding of shapes to avoid these kind of spikes
<TabAtkins> astearns: Do you think having a similar algo for shadows might make sense?
<TabAtkins> smfr: Would have to see what that algo is
<TabAtkins> smfr: Concern is that the font might be the one to specify the miter limit, but I don't think it does
<TabAtkins> smfr: If you have a path, maybe the UA can decide the miter limit when drawing the path. Just want confirmation that it's implementable.
<TabAtkins> Without examples of what's up, no opinion here since I don't have enough context.
<TabAtkins> astearns: Anyone with opinions, or people we shoudl tag?
<TabAtkins> fantasai: I'm happy to leave it udnefined, just want to know what to put in the spec.
<TabAtkins> astearns: Lacking opinions, thinkw e should leave it undefined
<TabAtkins> smfr: Might be okay to specify you get rounded corners. If we find it's impossible we can come back to it
<TabAtkins> fantasai: Might be opinions on better ways to do it, looking at miter-limit prop or whatever.
<TabAtkins> fantasai: Think I specced it as rounded corners because, at the time, seemed easiest to implement.
<astearns> shape-margin solution: https://drafts.csswg.org/css-shapes-1/#shape-margin-property
<TabAtkins> astearns: So maybe see if that's an implementable thing for shadows.
<TabAtkins> smfr: Think it might be a little mor ecomplex than that description. Prefer ot have it specified the way impls would do it, which is to stroke a path with a wide stroke width and use that edge to shadow
<TabAtkins> astearns: I think there was an issuea bout shape-margin property too; if there's a better way to specify we can do it in both places
<TabAtkins> astearns: I was trying in that section to be slightly vague to not restrict the particular algo
<TabAtkins> smfr: Briefly playing with it, sometimes in some fonts you'd get a hole due to winding rules.
<TabAtkins> smfr: Reason for impl experience, fonts have weird data.
<TabAtkins> fantasai: So maybe we just make it undefined fo rnow, and can define it with more impl experience
<TabAtkins> smfr: Fine with that.
<TabAtkins> astearns: proposed resolution is to leave it undefined for now, open to specifying it with experience later
<TabAtkins> RESOLVED: Leave text-shadow spread details undefined right now, with possibility of specification later after impl experience.