There are countless advantages to building sites in this way, but arguably the most compelling reason is the ability to share one layout across both desktop and mobile browsers. However, if you’re new to mobile development there are a couple of tricks you’ll need to use in order to make this work. It wasn’t really in the scope of Marcotte’s article to cover the mobile-specific aspects of his technique, so I figured a quick post was in order to fill in the gaps.

The example site we’ll be looking at is a hypothetical site for foodies called Fork’d. When you look at it in a normal sized desktop browser, It’s got a vertical navigation list and three columns of content. If you resize the window to be a fair bit narrower, you’ll see that the floats disappear, and the navigation as well as all of the content is lined up in a single column. This is the layout we want our mobile users to see. However, what they’re actually going to see is this:

Fortunately, we just need a tiny sprinkling of pixie dust to make this work the way we expect it to. We’ll just add this meta tag to our page:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

(For way more info on viewports, check out Apple’s documentation on the subject.)

Once we put that in place, the Fork’d site renders like this:

Perfect! We now have one layout that works across different desktop screen resolutions as well as (high-end) mobile devices, and the only extra trick we had to employ was to add a single meta tag.

League Gothic doesn’t have its own small caps variant. So what happens when you tell the browser to give you one anyway? Here it is with font-variant: small-caps applied as rendered in Firefox:

So far, so good. But here’s what you get when you add small caps to League Gothic in Webkit:

Whoops! Webkit-based browsers (I tested this in Safari, Webkit Nightly, and Chrome for OSX), when they don’t find the specified variant in the font itself, just go to the next font in the stack. In this case, it’s the browser’s default font.

So which behavior is correct? The CSS2 spec essentially left it up to implementors to decide whether or not they would dynamically scale the font to implement small caps. CSS3 removes the ambiguity:

If a genuine small-caps font is not available, user agents should simulate a small-caps font, for example by taking a normal font and replacing the lowercase letters by scaled uppercase characters. (CSS fonts module level 3)

Although a typographic purist might take issue with this behavior (Bringhurst rails against the practice of “rolling your own” variants by dynamically scaling the existing face), this is what the spec says browsers are supposed to do. And in fact, this is what Firefox does. Webkit, on the other hand, checks each font in the stack in order until it finds one that supplies the desired variant. As in the example above, if there’s nothing else in the stack, it will fall back on the browser’s default font.

Unfortunately, there aren’t really any workarounds for this bug. But it should serve to remind you yet again that it’s super-important to put a good deal of thought into your font stack. Always try to build a stack where all of the fonts are as similar as possible, so when something like this happens, your design doesn’t break too badly.

For reference, or if you’d like to see how your browser of choice handles these cases, here are some test cases together on a separate page.

The CSS is here, and be sure to check out the example buttons.

The one thing I’m not crazy about when you use these styles on an actual device is that the normal :active state doesn’t get triggered, so I kind of had to half-ass it with a :hover so you’d see the “active” style as the button sheet eases out (if you’ve wired the transitions together).

Enjoy, and please let me know if you find them useful.

If you pay even a little attention to emerging trends in Web Standards, you’re no doubt familiar with the explosion in interest in the CSS @font-face property. This property goes back to CSS2, and has been supported in IE as far back as 5.5, but @font-face support is being added at a rapid pace to other browsers, hence the recent surge of interest.

As someone who spends his days developing for mobile platforms, I wanted to check on how @font-face support was progressing in mobile browsers. Read on to see what I found out.

Methodology

I put together a test page I used to check the extent of @font-face support.

I made test elements and separate font families for each font format being tested (e.g. there’s a font family called “ChunkFive SVG” that will only be applied to the span#SVG test element. View source on the sample page for more details). I checked for @font-face support with three criteria (two automated):

1. Ask each test element what font-family it thinks it is being rendered with. This is done via the window.getComputedStyle() method (and why I’m sticking with testing W3C compliant browsers at the moment). If all goes well, the return value should be some variant of ChunkFive.
2. Check to see if the rendered text is wider than text rendered in the browser’s default font. For the test to pass, it has to be wider, since there are font size bugs in Mobile Safari (see below).
3. Eyeball it. In some cases, the criteria above aren’t met, so the @font-face implementation is incorrect, but it’s close enough to be saved with some extra TLC.

I also included a test case based on Paul Irish’s Bulletproof @font-face syntax as a bit of a sanity check and for the sake of having a less contrived example. Lastly, I threw in samples of Cufon and sIFR text, just for comparison.

All that said, here’s what I came up with.

Results

Mobile Safari 3.0

Support for @font-face in Mobile Safari is currently broken in several frustrating ways:

1. Certain formats (e.g. TTF & OTF), when applied, falsely report that they have been successfully applied. That is, if you check the value of font-family from getComputedStyle() on that element, it will return the @font-face value, even though it doesn’t render as such. (Update 11/13: As Paul Irish correctly pointed out in the comments to this post, Opera is actually the only browser that returns the font that’s actually used when getComputedStyle() is called.)
2. What’s worse, is that when this situation occurs, if no fallback font-family is specified, the text will render with the browser’s default font-family (as you’d expect), but it does so at less than the default font size. Fortunately, if you specify a fallback value in the font-family declaration, it will render the fallback typeface at the correct size, so always remember to pick a degradation path for your fonts.
3. Another issue with text size arises if you use the SVG format to get around the lack of support for other formats on the iPhone. While you can indeed use SVG fonts in your font-face rules on the iPhone, text rendered in SVG fonts will render at smaller than expected sizes. So if you opt for this strategy, just plan for this consequence, and correct the font sizes accordingly. Desktop browsers that support SVG fonts (Safari & Chrome) don’t exhibit this bug, so you need to target this font-size fix to mobile browsers. You can easily handle this case with a @media query in your stylesheet. Users of the Bulletproof Syntax will see this bug, since it will fall through to SVG on Mobile Safari.
   SVG fonts on Mobile Safari render too small out of the box.
4. Another (possibly more academic) issue is that calling getComputedStyle() on text rendered with an SVG font will not return the font-family value in your @font-face declaration, even though it renders with that font family. This could prove troublesome if you’re using Javascript to test the success of your font rendering.

So if you need to use @font-face on Mobile Safari today, you should be sure to include an SVG version in your @font-face declaration, and you should patch any text size bugs with a @media query. (If you’re not familiar with @media queries, you should read up on them.)

Incidentally, Opera 10 on the desktop also shows a slight variation in font-size when using SVG fonts as well. However, since it supports TrueType and OpenType formats, this shouldn’t cause any particular issues if you’re using the bulletproof syntax (that’s why it’s bulletproof, yo).

Android 2.0 SDK

Short and not so sweet: There is no support in the Android 2.0 SDK for any webfont format. If you’re targeting Android, use Cufon.

Palm WebOS

Like Android, there is currently no support whatsoever for @font-face in WebOS. Additionally, in my (not at all extensive) tests, Cufon didn’t even appear to work at all (as in no text was rendered).

Summary

In short, if you want your mobile site to join the Nice Web Type bandwagon, you have a little more work to do than for your desktop site. Of all of the modern WebKit-based mobile browsers, only Mobile Safari provides any kind of @font-face support. And even that support is buggy and incomplete. However, if you are aware of these limitations ahead of time (which you ought to be by this point in the post), you have a couple of tricks in your back pocket to keep things running smoothly.

What’s Next?

In the next little while, I’ll extend these tests to cover IE on WinMo and also do a similar write-up for @font-face support in desktop browsers and tabulate all of the results in a little more formal manner.

Update: In case anyone wants to take a look under the hood of these tests without jumping through hoops in Firebug or View Source, the test code is up on Github.

As you might expect, the border-radius property is used a lot like border. That is, you can specify one value for each corner (border-radius: 10px;), one value per corner (border-radius: 1px 2px 3px 4px;), or values for opposite corners (border-radius: 5px 10px). It actually gets more complicated, since in addition to describing corners with one radius (i.e. those with semi-circular curves), you can make elliptically rounded corners by naming two radii. For more detail on this, take a look at the draft spec. Lastly, you can use a property for each corner, border-top-left-radius: 2em;, etc. So, assuming there aren’t any major changes in the spec, expect this to be what gets implemented as part of CSS3, and what you’ll ultimately using in your code.

But what about now? Here? Today? It happens that two of the standards-aware, forward-thinking rendering engines have developed proprietary extensions to CSS that should stand in for border-radius until certain ambiguities in the spec can be resolved, and the property is implented according to the standard. So if you want to use border-radius in your code today, you’ll have to use both the Mozilla– and Webkit-specific CSS properties. Fortunately, both of the proprietary extensions work in the current major releases of their respective browsers.

If you’re making a box with four corners of the same radius, the syntax is the same in Mozilla and Webkit:

-moz-border-radius: 10px; /* 4 corners of radius = 4px*/
-webkit-border-radius: 10px; /* Same as Mozilla */

To specify different radii for each corner, things diverge somewhat.

/* Mozilla: */
-moz-border-radius: 1px 2px 3px 4px;
/* Webkit:
    (The four declarations below amount to the
    same thing as the single rule above) */
-webkit-border-top-left-radius: 1px;
-webkit-border-top-right-radius: 2px;
-webkit-border-bottom-right-radius: 3px;
-webkit-border-bottom-left-radius: 4px;

And that’s the guts of it. So to make a tabbed navigation list, you would use a declaration along the lines of the following (and see the below code in action.):

li {
  border: 1px solid #587402;
  border-bottom: none;
  border-radius: 0 10px 0 10px;
  -moz-border-radius: 10px 10px 0 0;
  -webkit-border-top-left-radius: 10px;
  -webkit-border-top-right-radius: 10px;
  list-style-type: none;
  float: left;
  padding: .5em 1em 0 1em;
}

There you have it. But there are just a couple of other things I want to point out. If the container you’re rounding the corners of has only text content and a background in it, the background will clip to the rounded corners. And indeed, according to the spec, any the contents of a block-level element on which a border-radius is set should clip do the same as long as you set overflow: hidden on those contents. However, the implementations just aren’t there yet. Instead, with anything over and above plain HTML text (for instance, an img or iframe) inside such a container, the square corners will peek outside of the rounded container. (Example)

One solution would be to make the border thick enough that the corners of the inner element can’t poke through the outer border (like so). Though inelegant, this will work just fine if you don’t need everything to round nicely. And this method should suffice for whatever kind of content you’re trying to stuff into your nicely rounded box.

However, if it’s an image you’re putting in the box and you need the inner corners to be rounded as well as the outer corners, then the only answer (for now) is to set the image as a background. Still, if the language of the spec is any indication, it won’t always be this way.

For the poor soul who is trying to squeeze iframe content into a rounded corner box, you’re essentially out of luck at the moment. You can certainly use the thick border method I described above, but short of that, you’ll have to look to the bleeding edge. That is to say, you’ll need something which isn’t yet in any production-quality browser, but that is currently in the Webkit nightlies. I speak of the arcane methods of -webkit-mask-image. This property can take a png or an svg as its url, and pretty much anything you apply it to will play nice and clip to the shape of the image. See for yourself. Still, this last bit is obviously not anything anybody will be using in production code for some time to come.

After reading all of this, if nothing else, I do hope that you’ve come away with a better idea of some of the great things that the CSS working group has in store for you, the developer. But even moreso, hopefully there’s something in all of this mess that you’ll be able to put to use today.