The antialiasing on each of these h3 elements looks fine with local fonts or @font-face fonts applied.
We add a leading span set in 10px Courier to the beginning of each h3. In webkit, the antialiasing on the local font h3 looks OK, but no antialiasing is applied to the h3s with @font-face fonts.
It looks like this is because 10px Courier renders with no antialiasing, and then this mode gets "stuck" on for the rest of the block level element.
Highlighting the text with @font-face fonts will cause good antialiasing to appear, but the effect disappears as soon as the page is scrolled.
We add a leading span set in 11px Courier to the beginning of each h3. This size of Courier is rendered with antialiasing, so the antialiasing looks fine in each of the h3 elements. We don't see the same effect as with 10px Courier.
Same thing as the first trigger case, but we use 4px Arial instead of 10px Courier to trigger the sticky lack of antialiasing.
5px Arial, which renders with antialiasing, looks fine. We don't see the same effects as with 4px Arial.
Instead of a leading span in 10px Courier, which would always trigger the bug, we add a trailing span set in 10px Courier. The behavior is unpredictable. Sometimes the @font-face fonts are rendered with antialiasing and sometimes without. Scrolling this test case in and out of view can change how the fonts are rendered.
It appears that if this test case is onscreen when the page is refreshed, antialiasing will not be applied. If it is scrolled into view from out of view, then antialiasing applies correctly.
Since this is a problem with antialiasing, it makes sense that we might be able to fix it with -webkit-font-smoothing: antialiased;
Unfortunately, applying that style to the h3 elements doesn't seem to fix the problem.
Even when the styles are applied to different block-level elements, the antialiasing is sticky, continuing into the @font-face fonts.
This test case exhibits the same inconsistent behavior as the traling span test case above. Refreshing while the example is onscreen means the text renders without antialiasing. Scrolling it off and then back on the page makes the rendering switch to antialiased.
What happens if we add some characters set in a local font at a size that renders with aliasing in-between the span that triggers the problem and our @font-face font text? The problem is fixed! So the antialiasing setting really is sticky for @font-face fonts. There appears to be no default, so the renderer uses the antialiasing setting of the previously rendered text.
We can also fix the rendering by flipping the renderer back to antialiased mode using the :after CSS pesudo-selector. If you write a rule to insert a space of content in an antialiased font/size after the element that renders without antialiasing, then the subsequent @font-face text will render with antialiasing on.
.tiny-courier {
font-family: Courier;
font-size: 10px;
}
.tiny-courier:after {
/* Flips the renderer back to antialiased text */
content: " ";
font-family: Arial;
font-size: 16px;
}