Font Smoothing — It’s not just for Webkit anymore

by Stephanie Rewis on April 24, 2014

I ran into a very frustrating bug while using icon fonts on our site at Contatta. A bug I filed last April, and nurtured through the process of getting fixed, didn’t make the Mozilla release notes (though it was included in Firefox 28). Because I feel it’s a very useful solution, I wanted to bring some attention to it.

Font Smoothing for [most] Everyone

In a nutshell, if you’re using antialiasing for icon fonts and headings using -webkit-font-smoothing, you’ll want to be aware of -moz-osx-font-smoothing. I won’t take the time to go into the finer details of sub-pixel or grayscale antialiasing. If you’re interested, you can read this article about type rendering on different operating systems for more info. And though I initially filed the bug on Firefox, the issue is actually OSX. Here’s a summary from Jonathan Kew (a Mozilla engineer):

The “problem” in Firefox is simply how OS X renders the font when “LCD font smoothing” is enabled (which I think is the default). AIUI, it’s widely known among the font-design community that OS X tends to fatten glyphs somewhat compared to other rasterizers. For the usual case of black-on-white text, this works OK (though some people like it more than others); however, for white-on-black, the effect can be much too heavy-handed.

Aral Balkan posted an excellent example of light icon fonts on a dark background — one with -webkit-font-smoothing, one on Firefox. The web has been full of people trying to come up with creative ideas for making their fonts render consistently — opacity tricks, text-shadow tricks, etc. But those only work in some situations. In the end, many people have simply thrown their hands up in frustration—and changed to a different heading font/color scheme or moved away from icon fonts and back to sprites.

A while back, the Webkit team gave us a way to counteract the issue — -webkit-font-smoothing. It should be used responsibly and shouldn’t be used on everything. Certain fonts become too thin and less legible when it’s applied. But when needed, it’s a fontsaver (yeah, yeah, I know). This non-standard property got a lot of attention and caused many of us to accuse Firefox of being fat. I was one of them.

Jump forward to the bug I filed. After much passionate discussion, the exceptional Mozilla engineer David Baron agreed to grant us a property that provides a similar fix — -moz-osx-font-smoothing. While it has the similar effect of slimming fonts, instead of using the “antialiased” value Webkit uses, FFOX has chosen to use “grayscale”. (You can read the bug for the reasons why and the methods used.) It also appears from viewing in the FFOX Inspector that you can use the inherit | unset | auto values as well. (Though I haven’t experimented with those.) So far, anywhere I need the -webkit-font-smoothing:antialiased I now use -moz-osx-font-smoothing:grayscale with great results.

If you use Sass, you’re in luck. Maximilliano Firtman has created a [Sass mixin to turn the font-smoothing property on and off] (

So spread the news — FFOX is thin again!

A Sidenote on Bug Filing

Maybe it’s all the beta testing I’ve done over the years, but I come from the “don’t accept sub-optimal behavior” camp. If something in a browser doesn’t behave as expected, I believe it’s more productive for the Web and my end result to file a bug and help get it fixed.

For those of you that haven’t yet filed a bug or made a feature request for a browser, I’d like to offer a few suggestions I’ve found helpful:

  1. Be very clear in your initial report. Use the most accurate terms you can to illustrate what causes the bug (does it have a trigger, can it be affected by other interactions, etc). Create one or two simple demos that illustrate the bug so the engineers can test it more easily.
  2. Remember that you’re dealing with people—engineers have feelings (I swear, they do!). Yelling at them, in general, gets you no where fast. Clarity and politeness are the order of the day.
  3. Engineers are dealing with massive amounts of work and they have to prioritize. If they feel your bug is a small edge case, it will receive a lower priority. If your bug is one that affects a myriad of people, but the engineers don’t understand that, rally the troops to come vote for it and comment on it. Have them show more examples. It really makes a difference in helping them prioritize.
  4. Stay with your bug. Keep an eye on it. Provide more examples where needed. This is your baby, it’s your responsibility to see it delivered to the masses. It’s easy for it to accidentally get stuck in limbo where one engineer has worked on it and is waiting for another engineer to weigh in. But he’s working on other things and doesn’t know the first engineer is waiting, and — well, you get the picture. The occasional little ping or tickle doesn’t hurt.
  5. Once the bug is fixed, you may be the one that has to let people know. Don’t count on release notes and the browser’s dev center. It can be missed in the mass of things that occur in a release.

BTW, I have this other outline bug I’d love to see fixed. It’s been around for over three years. It could sure use your votes. ;)


New Directions

by Stephanie Rewis on March 2, 2012

In 1999, when I started my journey through the interwebs, I had no real idea where it would take me. I barely knew what was possible. I only knew that my brain loved puzzle-type thinking, detective work, research and figuring things out. And I suspected code would access the parts of my mind that love a work out—and so I pursued it. Vehemently. For the first 12 months, I did tutorials for 15 hours a day and got any friend that might possibly need a website to let me create theirs. (And for the very first customers, may I apologize for the frame and table-based layouts.)

And as I learned, I had questions—lots of them—and I inflicted every one of them on the unsuspecting, and gracious souls on a couple of web design lists. (The only stupid question is the one you don’t ask!) As my skills grew, I began answering the questions of people who knew less than I and continued to pick the brains of those who knew more. Within a couple of years, I had accidentally created a business via business owners who had planned to build their own web site only to find it wasn’t as easy as they expected. Due to the number of questions I answered on the list, they wrote me offlist for a quote to, “Please, just do it for me”.

It didn’t take me long to figure out that there’s a whole lot to this web design business. And some portions I enjoyed more than the others. In looking at where I thought the puck was going, I ventured into the world of CSS—that marriage of code and design—and I loved it. I gleaned great enjoyment from changing a designer’s beautiful comp into light-weight, web-ready markup (I’m too much of a tweak-a-holic to design). And so I moved into specialization in the portion of the industry we now call front-end development.

My desire to give back led me to accept requests to write articles and books (even though I really dislike writing). Writing led to speaking at industry events. Speaking led to doing training in corporations. Filing zillions of bugs to make Dreamweaver move into the realm of Web Standards led to my work with the Web Standards Project (WaSP) as well as working as a contractor for Adobe to create the CSS Layouts contained in Dreamweaver. And writing a book teaching both CSS and Dreamweaver while using those layouts as a base for each project led to discovering the other half of my brain—my co-author Greg Rewis. Now my husband, soul mate, and co-captain on Geeks4Sail. Every choice I’ve made to give—even when there wasn’t a guaranteed return—has come back from the universe in amazing ways I hadn’t envisioned. It’s been a great ride.

And even though I’ve loved every minute of sharing, learning and teaching others, and of working with awesome agencies, companies and start-ups—I still leave them with the code and walk away to start the next contract. I rarely get to see a product through to fruition or have any further affect on its development. I can’t continually help the code evolve as the web changes. I just hand it off and move to the “next thing”.

But all that’s gonna change…

I was recently approached by a start-up (oddly enough, right here in the Phoenix area). We initially discussed their need for a top notch front-end developer to build their web app—probably a six month contract. We discussed what they were building for about an hour—and I got this feeling in my gut. You know the one that hits you in the pit of your stomach and says, “I really, really feel like this is a thing“? That one. But having been taught by my parents never to trust my gut—always use your head—I did the obedient thing and went to the web for some Google research. As you do… That research made the feeling in my gut even stronger. And a series of meetings with the CEO, CTO and team over the past couple weeks has evolved into my decision to make a full-time commitment—forsaking all others. This is a big step for me after 12 years of independence. I should feel a twinge of sorrow. But I don’t! I’m as excited as I’ve been about anything in years.

I am now officially the VP of Interface Architecture for Contatta (Italian for “be in contact with”), helping to create a new era in Contact Management. And while a product related to CRM may not sound like a sexy start up to you, Pat Sullivan, the co-creator of ACT!, and founder of SalesLogix is a founder of this company. Along with Sunil Padiyar who was a founding member of SalesLogix as well. When the man that helped create an industry 25 years ago says he thinks it could be in a better place—and in fact has ideas about changing a currently stagnant industry—I listened. And in listening, I was impressed enough to get on board.

Not only am I excited about the product, I’m super excited about the team they’ve already assembled. I’m going to have the opportunity to work with some amazingly top-notch devs and we’ve already been exchanging ideas. I’m literally chomping at the bit to get started!

Lest any clients (or prospective clients) are concerned, I’ve got great back-up with good friends and co-contractors like Emily Lewis (of “Microformats Made Simple” and “HTML5 Cookbook” fame), Leslie Flinger (front-end developer and former Director of Marketing at EllisLab) and others. You’ll be in great hands!

A recommendation on Contatta’s Facebook wall says – “With Pat behind it … here’s hoping for a real game changer for the industry!” I agree with that and I’ll take it a step further and say, “With the team behind Pat, we’re gonna work to make awesomeness—and maybe a ding in the Universe.”

EDIT 3/7: Some have emailed to ask whether I’ll still be speaking. Yes, on a more limited basis—but not once a month as I have been. Feel free to send requests. :)


CSS3: spread value and box-shadow on one side only

by Stephanie Rewis on September 8, 2011

This morning I awakened with a question in my twitter stream from @deebeefunky. He was frustrated by the fact that when he sets a blur on box-shadow, it shows on two sides of the box. He wants it to show on only one side. Of course, that got me thinking. I did come up with one solution—it won’t work in every situation—but it may work in yours.

The spread value

There’s a little talked about value in the box-shadow property called “spread”. That value, when used, comes after the blur value and moves the shadow away from the box equally all the way around. It doesn’t add a blur, it simply spreads out in all directions. You’ll get different effects based on whether the blur value is a greater than the spread value or whether the spread is greater than the blur. The color defined will be solid right next to the box, and then blur for the rest (based on the difference between the two values). Before it gets too confusing, let’s have a look at the property:

box-shadow: (inset) x-value y-value blur spread color;

div {
-webkit-box-shadow: 0 0 6px 4px black;
   -moz-box-shadow: 0 0 6px 4px black;
        box-shadow: 0 0 6px 4px black;
Blur larger than spread

Blur larger than spread

If the spread value has a higher value, you get a different effect with the full spread and only a little blur.

div {
-webkit-box-shadow: 0 0 4px 6px black;
   -moz-box-shadow: 0 0 4px 6px black;
        box-shadow: 0 0 4px 6px black;
Spread value greater than blur

Spread value greater than blur

Though the differences above are subtle, you can actually create some really interesting effects with this value. If you don’t move the box-shadow on the x or y axis and provide no blur value at all, you can create one, or more, multiple borders for your element.

Create the look of multiple borders

div {
border: 3px solid orange;
-webkit-box-shadow: 0 0 0 3px black, 0 0 0 6px red;
   -moz-box-shadow: 0 0 0 3px black, 0 0 0 6px red;
         box-shadow: 0 0 0 3px black, 0 0 0 6px red;
Spread radius with no blur

Spread radius with no blur

Notice it appears there are three borders on this element. A single (orange) border was added, then a black border (created with the 3px of spread) and then a red border (the 3 px border is created by 6px of spread since you must allow for the first box-shadow). It’s unlikely you’d actually need more borders than this, but you can create an unlimited number this way. Remember that when using multiple box-shadows, the first one is applied closest to the element.

How does this apply to @deebeefunky’s question?

I’m glad you asked! Sometimes I get off track (you know, that simple little blog post you were gonna write…). The issue with box-shadow is, even if you only move the shadow on the x or y axis, you’ll see a hint of the shadow on at least two sides of your element.

div {
-webkit-box-shadow: 1px 0 2px black;
   -moz-box-shadow: 1px 0 2px black;
        box-shadow: 1px 0 2px black;
2px blur moved 1px on the x-axis

2px blur moved 1px on the x-axis

I came up with an idea that works as long as A) the element is a solid color and B) you’re not also using border on the element. It involves applying two box-shadows, one with spread in the same color as the box itself and another without. Like so:

div {
background: white;
-webkit-box-shadow: 0 0 0 4px white, 0 6px 4px black;
   -moz-box-shadow: 0 0 0 4px white, 0 6px 4px black;
        box-shadow: 0 0 0 4px white, 0 6px 4px black;
Use two box-shadows for a single side effect

Use two box-shadows for a single side effect

Why does this work?

In a nutshell, what you’re doing is creating the first box-shadow (0 0 0 4px white) which doesn’t move on the X or Y axis, doesn’t provide any blur, and has the 4px of spread set in the same color as the background of the element. This basically renders it invisible but makes the element 4px wider than it was (box-shadow does NOT add to the box model, so you’re element will appear 4px closer to the elements around it as well). Remember the order I mentioned before? The first box-shadow is placed on top—or closest to the element? That’s what helps us here. The second box-shadow (0 6px 4px black) is moving 6px on the Y-axis, has 4px of blur, no spread and is black. We’ve moved this vertically—though you could use the same technique on the X-axis.

Where is the real border?

Just to illustrate why you can’t use a border with this technique, here’s a look at the addition of a red border to our previous example.

Red border shown on actual outside of box

Red border shown on actual outside of box

The thing to remember when using this technique is A) you can only move on one axis— X or Y and B) your blur value cannot exceed the spread value given in the first box-shadow. If it does, you’ll start to see it peek out on the sides (an effect we were avoiding in the first place). You can, however, move as much or as little on either the X or Y axis as your effect requires. And as always, using RGBA or HSLA color values will give you a more realistic shadow if that’s what you’re after.

Update: Method Two

If you have a patterned background on the element or need to use a border, Joseph Silber had another idea in the comments below. Use a negative spread radius. Nice thinking, Joseph! Playing with this method, I came up with the following:

div {
	-webkit-box-shadow: 0 8px 6px -6px black;
	   -moz-box-shadow: 0 8px 6px -6px black;
	        box-shadow: 0 8px 6px -6px black;
Negative spread radius with equal blur value

Negative spread radius with equal blur value

The issue to be aware of with this method is, the negative spread value should be equal to, or greater than, the blur value or you’ll end up with a slight blur on the other two sides of the element. Also, very little of the box-shadow will show if you don’t give the X or Y a value equal to, or greater than, the blur. Otherwise, the blur is slightly hidden behind the edge of the element since the spread value is negative.

With the negative spread value, a border can be added

With the negative spread value, a border can be added

Notice the element isn’t “expanding” like it did using the first method (the box size is what you’d expect), but the shadow doesn’t quite go to each edge due to the negative spread value. Based on the interaction with other elements on your page, one of these two methods might just work for you!

Update Oct 2

Due to an Android bug when the box-shadow has no blur, you’ll likely want to use the second method if you want the shadow to appear on an Android device. Let’s hope they fix this one soon. (Thanks, Luís Carmona!)

Do you have a method you use to create the same effect? Share it in the comments. Happy coding!


Firefox multi-column layout bug… and a unicorn

May 4, 2011

Last night, I was getting a file ready to share with Estelle Weyl, one of my co-presenters for our CSS3 workshop at SXSW11. The page was a silly little demo that used media queries, multiple backgrounds, transitions, generated content, multi-column layout and, well, a unicorn. I had only viewed the file in Chrome since that’s [...]

Read the full article →

Changing a Background-image with CSS3 Transitions

March 1, 2011

As you may have read, outside of gradients, you can’t change a background-image with CSS transitions. Or can you? At InControl Conference last week, Greg Rewis spoke about Transitions, Transforms and Animations. A question was asked about showing one background-image on load and transitioning to another in a subsequent pseudo-state. You can always change the [...]

Read the full article →

CSS3 Flexible Box Model…Layout Coolness…also Oddities & Confusion

February 25, 2011

In August, due to a twitter discussion with Molly, and of course while partying on a Saturday night, Dave Gregory and I were looking at whether the Flexible box layout module (still a working draft) is getting close to ready for prime time yet. Our hope was that it will solve some of the frustrations [...]

Read the full article →

HTML5 and Video: 4 part video series

January 10, 2011

I’ve had a couple people ask me to link on my blog to my four part video series on HTML5 and video. Currently, it’s a feature on the AdobeTV home page, but I reckon that will be for just a little while. After that, you can link directly to Part 1 (7:18), Part 2 (10:31), [...]

Read the full article →

Mangled smiley in @font-face

January 5, 2011

Recently, I noticed that sometimes, when uploading a stylesheet using @font-face, my cute little smiley (thank you Paul Irish!) gets turned into some kind of garbledygook instead of the smile character. Last week, I decided to try an experiment. It cleared it right up. To the top of your stylesheet, add this: @charset “UTF-8″; Be [...]

Read the full article →

HTML5: Native Video, DRM and Plugins

October 13, 2010

I was reading a discussion on the W3C Bug tracker about native video and whether it should, or should not, provide DRM to protect video content. In the process, the point was made by John Foliot that Apple is presenting their own answers in their browsers and devices to the DRM issue (emphasis mine): > [...]

Read the full article →

Inner border (content or padding edge) quirk in webkit?

October 12, 2010

Today on Twitter, Keith Clark (@keithclarkcouk) mentioned he was struggling with creating an element with rounded corners and rgba borders because the background color of the element was showing through. That sounded silly. I mean, modern browsers have background-clip. We can clip to the content, the padding or the border. That should fix it. But [...]

Read the full article →