web fonts and css features – a simple demonstration

This post is from Laurent Jouanneau, who was kind enough to build a very simple but elegant demonstration of how to use web fonts and some of the new CSS features in Firefox 3.5.

View the Demo in Firefox 3.5

Shadows and round corners

First, we set some style properties on the toolbar:


-moz-border-radius:10px 0px 10px 0px;

This indicates that top left and bottom right border corner should be round with a radius of 10 pixels.


-moz-box-shadow: #9BD1DE 5px 5px 6px;

This indicates that a shadow should be drawn under the div, with an offset of 5 pixels to the right and the bottom, and with a blur radius of 6 pixels.

Second, the buttons. We still use a border-radius property. But we use also a box-shadow property which changes depending of the state of the button. In the normal state, there is a shadow outside the button. When the mouse hovers over it (the hover state), the shadow is changed to be inside the button using the inset CSS property. We do the same thing when we click on the button (the active state), but we also make the shadow is bigger and darker.

#superbox button {
    -moz-border-radius: 5px;
    -moz-box-shadow: #000 0px 0px 8px;

#superbox button:hover {
    -moz-box-shadow: inset #989896 0 0 3px;
    text-shadow: red 0px 0px 8px;

#superbox button:active {
    -moz-box-shadow: inset #1C1C1C 0 0 5px;

You can also see that we add a red shadow under the text of the button when the mouse hovers over it using the text-shadow property.

Web fonts

Each button is rendered with its own font, declared using @font-face. Example:

@font-face {
    font-family: Brock Script;
    src: url("BrockScript.ttf");
    font-style: normal;
    font-weight: normal;

With the font-family property, we indicate a name for our font. The src indicates the url of the downloadable font.

Once we’ve defined the @font-face property we can use it in the CSS for one of the buttons:

.first {
    font-family: Brock Script;

When you declare the font with @font-face, and then use the font in CSS, the browser will automatically download and render using that font. The browser won’t download fonts you don’t use, so it’s safe to include descriptions of fonts from a common CSS file that might not be used in the page that you’re currently displaying.

In the demonstration there’s also a small amount of script connected to each of the buttons that changes the class of the blue box to use the downloaded font for that button showing that you can update fonts on the fly as well.

With these relatively simple techniques we can have beautiful buttons without having to use a bitmap image.

Note: these fonts can be downloaded from fontsquirrel.com : Brock-Script (created by Dieter Steffmann), Sniglet (created by The League of Moveable Type, under the licence CC-by-sa) and Quick End Jerk (created by Vic Fieger).

About Christopher Blizzard

Making the web better, one release at a time.

More articles by Christopher Blizzard…


  1. dataStorm

    Awesome CSS! Is there a way to scale the size of the text depending on the width of the parent div for example?

    June 13th, 2009 at 21:58

  2. Thor K.H

    Interesting demo, looks good. Would be interesting with a non-JS way (although that’s barely any JS at all).

    June 13th, 2009 at 23:25

  3. AndersH

    It seems to me, that it would be very useful if the browser was able to ask the server for exactly the characters it needed, so only the needed parts of the font could be sent. Otherwise this would probably be a nonstarter for Asian languages where fonts are several megabytes.

    This could be done via a “unicode-range” http request header (not to be confused with the “unicode-range” css property). This would work similar to the “range” header does for byte ranges, i.e. that a server that understood this header would only send the needed characters or fallback to sending the whole file, and if the browser suddenly needs more characters, it would ask the server for another range and combine it with the characters already received (based on bug 465414, that involves the “unicode-range” css property, it seems that combining pieces of a font is already implemented).

    Although the “range” header include a unit (where “bytes”, according to rfc2616 section 3.12, currently is the only defined unit), it should probably not be used for this purpose, because this would perhaps limit backwards compatibility when the browser wants a specific byte range out of a specific Unicode range.

    This might give some problems with ligatures, so the browser might also need to be able to ask for glyphs, so the server could send all the substitution information that involved any of the characters in the requested Unicode range (keep in mind that other Unicode range might already be received by the client) without sending the actual glyph data before being specifically asked for it. But some test with example pages (including Asian pages) and fonts would probably be required, to check what the “expensive” parts (size vice) of necessary parts of the fonts are, to make sure the browser include enough information in its requests.

    June 14th, 2009 at 00:48

  4. macke

    There’s some problem with the demo, instead of characters I only get boxes with [00 46] etc, seems the remote fonts doesn’t work for some reason. Ubuntu 9.04 / Firefox 3.5beta4

    June 14th, 2009 at 00:49

  5. Pete

    why do you call the classes -moz-border-shadow and -webkit-border-shadow instead of simply box-shadow? Why do we need to go through the whole -whatever-opacity drama again?

    June 14th, 2009 at 03:41

  6. soso

    don’t work with Linux and Firefox 3.5b4

    June 14th, 2009 at 06:46

  7. Skeuomorph

    But it *does* work in Safari 4.

    June 14th, 2009 at 08:06

  8. Christopher Blizzard

    @macke + @soso – that’s a known problem with Linux that’s been fixed after Beta 4. It will work in the RC. There’s a reason why we have betas. :)

    June 14th, 2009 at 08:36

  9. Christopher Blizzard

    @Pete – they are called -moz-* or -webkit-* when they are features specific to that browser and haven’t gone all the way through the standards process. This is part of how the standards process works – we try out different things, learn how they interact with other content, figure out what works and what doesn’t and then everyone figures out how to agree on one implementation.

    That’s basically the story with opacity as well. Now that opacity has been standardized and everyone has agreed on how it should be done we’ve deprecated the old -moz-opacity property in 3.5 in favor of the new opacity property. Other browser vendors are doing the same.

    June 14th, 2009 at 08:41

  10. Christopher Blizzard

    @AndersH – That’s a good suggestion and it’s probably possible to do that with the technology that exists today. Not in the same way that you suggest, but servers could serve up fonts with just the characters used in a particular page. That would help quite a bit for languages with thousands of characters like Traditional Chinese. Remember that you can create your own fonts if you want and it’s fine if that font doesn’t contain every single glyph for every character in every language.

    The second thing is that there’s another obvious use case here – caching. It’s an HTTP request so I imagine that the fonts should be cached just like any other resource. If someone hosted a service for fonts they could use pretty aggressive caching and save a lot of bandwidth that way as well – even across sites and services.

    June 14th, 2009 at 08:46

  11. Christopher Blizzard

    @dataStorm I’m pretty sure that you could do that with JS and some simple size-fitting algorithms and there might be a way to do with CSS, but I haven’t thought about it too much.

    June 14th, 2009 at 08:50

  12. nemo

    With regards to serving up characters only for certain ranges.

    Seems to me a website wanting to use various fonts should take the time to edit the OTF/TTF down to the set of glyphs needed for that particular website – this seems no different to me than other basic optimisations like scaling down images.

    Additionally, if the website was serving entirely different glyphs due to i18n based on user settings or Accept-Language/Accept-Charset,
    the website could again serve alternate stylesheets linking to alternate OTF/TTF containing the needed characters.

    Sooo, yeah. A bit of work, but fairly quick in a decent font editor. I suppose a config file for a site that specified the glyph ranges that site was using could also be done, instead of manual labour.

    Heck, for sites doing i18n, a CMS could presumably calculate its own glyph ranges based upon the current content in its database and regenerate the font accordingly :)

    June 14th, 2009 at 13:16

  13. AndersH

    @Christopher Blizzard: I know it is possible to do on the server. But when pages are pieced together on the client (think ajax) from several data sources which are filtered based on user selections and you have user generated content that you want to preview using the correct font, and you want to minimize the size of each font package and do indeed want to enable caching (on the client), it quickly becomes complex and you have to err on the safe side, since it would be quite bad if a single glyph was missing and you don’t know what glyphs the client have already cached (outside your dependency hierarchy of font packages). I did one. So I’m not solely talking out of my ass. One of the Asian languages I referred to was indeed Traditional Chinese.

    It is because of this I say, that it would be tremendously helpful if the client could tell the server what characters it needed. Kind of the way Firefox, as I understand it, currently only load a font if it is used (which could also just be handled on the server, i.e. don’t reference it in the css, if it isn’t used), here you would only load the characters if they was needed.

    With regards to caching, I do not believe this would cause need caching on the server, since the font files are fairly static and already contain lookup tables, so the chopping can be done on the web tier with little overhead (just as a byte-range request is handled by the web tier with little overhead). Where you do want caching is on the client, so parts of the font, that was used on the previous page, isn’t downloaded again when navigating to the next page and you can’t known what path the user will take though your site.

    If you really wanted to create font packages with the most common glyphs and and then fall back to a generated range request, well, that is what unicode-range css property is for. But you could also let the server answer with (a redirect to) a pre-generated font file, if any of the requested characters was in that file (meaning that it had not already been downloaded by that client), the client would then do a new request for the remaining characters when it found out that some where missing and that the server understood the unicode-range http header (because the server answered with a accept-header). The server would when send (a redirect to) another pre-generated font file if one existed or create a new with characters that it really didn’t have mapped to the “.notdef” glyph (index 0). But I don’t think you would win much by pre-generating these font files.

    If you did something like downloading the offset table and table record from the font file and then only the needed parts of the needed tables (e.g. binary search for cmap- and glyf-tables), you would probably get latency problems.

    (sorry for the long rants here, but bugzilla didn’t seem link the right pace either and I was not sure where else to go. Feel free to delete the posts)

    June 14th, 2009 at 13:27

    1. Michel Hubin

      I am the webmaster of a french scientific web site and my problem with Firefox 3 is that it doesnot recognise symbol font. Firefox 2 had not this problem but firefox 3 has it. For scientific sites this is dramatic as symbol font concerns many parameters which are defined by international conventions, and many scientific parameters or mathematical ones are represented by greek characters that is to say by some characters of the symbol fonts. I and many users and specifically students have signaled this bug to bugzilla in april 2008 when Firefox 3 appears on the market but it seams that nobody at Mozilla will understand that this is important. My website is dayly read by more than 2000 students and they are very displeased to be unable to understand the equations because some greek symbols are replaced by latin ones. Mozilla writers should understand that is dramatic and they should also understand that users of Firefox are mostly students and specifically scientific students and I discover that Firefox 2 was used by 28% of the students (from all the world) who read my website and actually only 14% are using Firefox 3. I think this is very significant and that The Mozilla fundation should understand that the only reason for this decrease of Firefox use depends of this bug : Firefox 3 doesnot recognize symbol font and replace greek symbol by latin ones in equations and scientific texts. I hope you help us to obtain the disparition of this stupid bug.

      January 11th, 2010 at 06:20

  14. […] 原文地址:web fonts and css features – a simple demonstration 系列地址:颠覆网络35天 […]

    June 15th, 2009 at 00:13

  15. jmdesp

    > Seems to me a website wanting to use various fonts should take the
    > time to edit the OTF/TTF down to the set of glyphs needed for that
    > particular website

    In fact everytime you create a PDF with embedded fonts, that part is automatically done for you. So it would be nice to find a way so that web authoring tools do the same when you include a downloadable font.

    June 15th, 2009 at 02:47

  16. […] what you have to look forward to in Firefox 3.5? My personal favorite things are being able to embed a font in my website so that I can type in any font I want, the ability to play embedded OGG audio and Theora video […]

    June 21st, 2009 at 22:08

  17. […] Firefox 3.5 has support for web fonts (check out this video of Opera CTO Håkon Wium Lie demonstrating web fonts to Aliza), and you can find a good demonstration of how to use them and some of the new CSS features in the browser here. […]

    June 22nd, 2009 at 13:02

  18. […] Mozilla Hacks site has thrown all these together in a demo (which in itself looks hideous, but does succeed in showing what’s possible), and there are a […]

    July 6th, 2009 at 02:08

  19. […] 原文地址:web fonts and css features – a simple demonstration 系列地址:颠覆网络35天 […]

    July 20th, 2009 at 23:15

  20. Morteza

    thank you for your post. I have a problem using font-face in pages. I use my own language fonts ( Persian ) , but I don’t take a smooth font like what I see in IE. what is the problem? is it something about clearType? how can I fix it?

    July 7th, 2010 at 01:22

  21. vakies

    why PR toolbar not working in Mozila firefox latest version ?

    July 10th, 2012 at 06:29

Comments are closed for this article.