Bug 19376 - REGRESSION: Font rendering using 0 offset/blur text-shadow looks worse.
Summary: REGRESSION: Font rendering using 0 offset/blur text-shadow looks worse.
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.5
: P1 Normal
Assignee: Nobody
URL: http://madebysofa.com
Keywords: InRadar, Regression
: 19399 REG_Fuzzy_Text 20453 22114 (view as bug list)
Depends on:
Reported: 2008-06-03 09:17 PDT by Jussi Hagman
Modified: 2009-07-06 21:13 PDT (History)
9 users (show)

See Also:

Testcase (1014 bytes, text/html)
2008-06-03 09:44 PDT, Matt Lilek
no flags Details
Testcase (863 bytes, text/html)
2008-06-03 09:46 PDT, Matt Lilek
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jussi Hagman 2008-06-03 09:17:13 PDT
WebKit Nightly and Safari 3.1.1 are rendering the text on page differently. 

When not using sub pixel anti-aliasing (selected from System Prefs > Appearance) the difference is quite subtle, Nightly is a tad more edgy and has lighter color (or bigger weight).

When the system wide setting for sub pixel anti-aliasing is enabled WebKit uses it, but Safari 3.1.1 does not. The rendering of Webkit is almost illegible and very heavy.
Comment 1 Matt Lilek 2008-06-03 09:44:33 PDT
I'm not 100% sure this is actually a bug so I'll defer this to Dan.  If you take a look at the testcase, the middle lines are really the important ones.  The MadeBySofa site has text shadows with 0px values other than the color. To me, passing all 0's to text-shadow shouldn't change anything, but perhaps I'm wrong and there's a good reason for this.
Comment 2 Matt Lilek 2008-06-03 09:44:42 PDT
Created attachment 21479 [details]
Comment 3 Matt Lilek 2008-06-03 09:46:11 PDT
Created attachment 21480 [details]

Bah, that was an old one, this one is slightly better
Comment 4 mitz 2008-06-03 11:13:15 PDT
Two things have changed since 3.1.1:
1. Specifying a zero-blur text-shadow no longer disables subpixel antialiasing.
2. Zero-offset text-shadows are rendered just like any other shadow.

Because of anti-aliasing, (2) results in the shadow showing behind the text near the edges even when it is has a zero offset. I am not sure why anyone would specify a zero-blur, zero-offset text-shadow for opaque text, but the current behavior seems correct to me.
Comment 5 Mark Rowe (bdash) 2008-06-04 16:03:03 PDT
*** Bug 19399 has been marked as a duplicate of this bug. ***
Comment 6 mitz 2008-06-06 17:15:42 PDT
Comment 7 DanH 2008-06-09 01:31:51 PDT
Using "text-shadow: 0 0 0 #000" is a very common trick to avoid Safari's terrible rendering of light text on dark backgrounds. See for example http://24ways.org/2006/knockout-type for some explanation.

For real-world examples see e.g.:


These look quite broken in WebKit nightly, and just fine in Safari 3.1.1. Please, please, please revert to the previous behavior.

Of course it would be even better if the underlying problem could be fixed so that the trick wasn't needed.
Comment 8 Dave Hyatt 2008-06-13 22:52:01 PDT
The current behavior seems correct to me also.  The sites in question were clearly relying on a "hack" side effect related to text-shadow (the disabling of subpixel AA).

If disabling subpixel AA is really necessary, then perhaps we should just provide a CSS extension to do this directly (so that authors don't have to rely on hacks).
Comment 9 DanH 2008-06-18 02:22:25 PDT
Isn't a CSS extension to disable subpixel AA just as much of a hack as the zerooffset-zeroblur text-shadow thingy?

IMHO, light text on dark backgrounds should be legible by default - either by fixing the subpixel AA code, or by automagically disabling subpixel antialiasing when needed. No hack should be needed.

But until that bug is fixed, the current (text-shadow) hack seems as good a way as any to temporarily solve the problem. Replacing one hack with another doesn't seem very useful. Again IMHO of course.
Comment 10 Matt Lilek 2008-07-20 10:50:30 PDT
*** Bug 20115 has been marked as a duplicate of this bug. ***
Comment 11 Matt Lilek 2008-08-19 16:05:59 PDT
*** Bug 20453 has been marked as a duplicate of this bug. ***
Comment 12 mitz 2008-11-06 22:06:48 PST
*** Bug 22114 has been marked as a duplicate of this bug. ***