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-decor-4] Disallow negative spread values on text-shadow #6971

Closed
smfr opened this issue Jan 20, 2022 · 9 comments
Closed

[css-text-decor-4] Disallow negative spread values on text-shadow #6971

smfr opened this issue Jan 20, 2022 · 9 comments

Comments

@smfr
Copy link
Contributor

smfr commented Jan 20, 2022

This thread describes some difficulties in implementing spread on text-shadow. The gist is that spread on box-shadow can be implemented via changing rectangle sizes and adjusting corner radii, but spread on text-shadow would have to be implemented by shadowing the text rendered with an enlarged stroke, which could lead to unexpected shadowing of parts of glyphs in some fonts (I saw issues with Zapfino).

In addition, the stroke-enlarging implementation doesn't allow for negative spread, so I suggest we disallow negative spread on text-shadow.

@LeaVerou
Copy link
Member

I'm fine with that, most use cases for text-shadow spread are to add outline-like things, which require positive spread.

@smfr
Copy link
Contributor Author

smfr commented Jan 20, 2022

Then the question is "parse as invalid" or "clamp to 0". I suggest "clamp to 0".

@LeaVerou
Copy link
Member

LeaVerou commented Jan 20, 2022

If we clamp to 0, we can never change that behavior, nor can it be tested via @supports. It also makes it harder to debug. What's the argument for clamping to 0?

@smfr
Copy link
Contributor Author

smfr commented Jan 20, 2022

Less surprising than parsing as invalid (esp if you copy a value from box-shadow) but I don't feel strongly.

@tabatkins
Copy link
Member

I'm in favor of making it a non-negative range, for the reasons Lea gives. Negative numbers should be invalid if they aren't going to do anything, rather than being silently clamped to a different behavior.

@bradkemper
Copy link
Contributor

Couldn't you stroke the alpha channel with a white stroke to create the choke?

Or could you use an erode filter on it?

@bradkemper
Copy link
Contributor

Also, Wow! That thread is 10 years old. I'm happy we are returning to this.

Are you also looking at supporting the inset keyword in text-shadow?

@SebastianZ
Copy link
Contributor

Are you also looking at supporting the inset keyword in text-shadow?

Just for reference, adding inset to the spec. is discussed in #6074.

Sebastian

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Text Shadow Negative Spread, and agreed to the following:

  • RESOLVED: Negative spread values on text-shadow are invalid
The full IRC log of that discussion <fantasai> Topic: Text Shadow Negative Spread
<fantasai> github: https://github.com//issues/6971
<fantasai> fantasai: Proposal is to disallow negative spread values on text-shadow by making them invalid
<emeyer> +1 from me on making them invalid
<fantasai> astearns: Any objections?
<TabAtkins> +1
<fantasai> smfr: Minor suprise for authors, because box shadow and text shadow have different behavior, but I'm OK with it
<fantasai> RESOLVED: Negative spread values on text-shadow are invalid

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

7 participants