WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
19376
REGRESSION: Font rendering using 0 offset/blur text-shadow looks worse.
https://bugs.webkit.org/show_bug.cgi?id=19376
Summary
REGRESSION: Font rendering using 0 offset/blur text-shadow looks worse.
Jussi Hagman
Reported
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.
Attachments
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
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Matt Lilek
Comment 1
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.
Matt Lilek
Comment 2
2008-06-03 09:44:42 PDT
Created
attachment 21479
[details]
Testcase
Matt Lilek
Comment 3
2008-06-03 09:46:11 PDT
Created
attachment 21480
[details]
Testcase Bah, that was an old one, this one is slightly better
mitz
Comment 4
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.
Mark Rowe (bdash)
Comment 5
2008-06-04 16:03:03 PDT
***
Bug 19399
has been marked as a duplicate of this bug. ***
mitz
Comment 6
2008-06-06 17:15:42 PDT
<
rdar://problem/5992870
>
DanH
Comment 7
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.:
http://slashdot.org
http://www.subtraction.com
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.
Dave Hyatt
Comment 8
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).
DanH
Comment 9
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.
Matt Lilek
Comment 10
2008-07-20 10:50:30 PDT
***
Bug 20115
has been marked as a duplicate of this bug. ***
Matt Lilek
Comment 11
2008-08-19 16:05:59 PDT
***
Bug 20453
has been marked as a duplicate of this bug. ***
mitz
Comment 12
2008-11-06 22:06:48 PST
***
Bug 22114
has been marked as a duplicate of this bug. ***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug