Mozilla

@font-face Articles

Sort by:

View:

  1. Web Open Font Format for Firefox 3.6

    This article was written by John Daggett. John is a Mozilla contributor and has been working hard with font creators and web developers to improve the state of fonts on the web. This article is a high-level overview of whats different and shows some examples of WOFF in use. A full list of other supporting organizations can be found at the official Mozilla Blog.

    In Firefox 3.5 we included support for linking to TrueType and OpenType fonts. In Firefox 3.6 we’re including support for a new font format – the Web Open Font Format, or WOFF. This format has two main advantages over raw TrueType or OpenType fonts.

    1. It is compressed, which means that you will typically see much smaller download sizes compared with raw TrueType or OpenType fonts.
    2. It contains information that allows you to see where the font came from – without DRM or labeling for a specific domain – which means it has support from a large number of font creators and font foundries.

    The WOFF format originated from a collabaration between the font designers Erik van Blokland and Tal Leming with help from Mozilla’s Jonathan Kew. Each had proposed their own format and WOFF represents a melding of these different proposals. The format itself is intended to be a simple repackaging of OpenType or TrueType font data, it doesn’t introduce any new behavior, alter the @font-face linking mechanism or affect the way fonts are rendered. Many font vendors have expressed support for this new format so the hope is this will open up a wider range of font options for web designers.

    Details on Differences between TrueType, OpenType and WOFF

    First, compression is part of the WOFF format so web authors can optimize the size of fonts used on their pages. The compression format is lossless, the uncompressed font data will match that of the original OpenType or TrueType font, so the way the font renders will be the same as the original. Similar compression can be achieved using general HTTP compression but because compression is part of the WOFF format, it’s simpler for authors to use, especially in situations where access to server configuration is not possible.

    Second, the format includes optional metadata so that a font vendor can tag their fonts with information related to font usage. This metadata doesn’t affect how fonts are loaded but tools can use this information to identify the source of a given font, so that those interested in the design of a given page can track down the fonts used on that page. Fonts in WOFF format are compressed but are not encrypted, the format should not be viewed as a “secure” format by those looking for a mechanism to strictly regulate and control font use.

    Note: until Firefox 3.6 ships, users can test the use of WOFF fonts with Firefox nightly builds.

    Examples

    Below is a simple example that shows how to construct an @font-face rule that links to a WOFF font. To support browsers that only support direct linking to OpenType and TrueType fonts, the ‘src’ descriptor lists the WOFF font first along with a format hint (“woff”), followed by the TrueType version:

    /* Gentium (SIL International) */
     
    @font-face {
      font-family: GentiumTest;
      src: url(fonts/GenR102.woff) format("woff"),
           url(fonts/GenR102.ttf) format("truetype");
    }
     
    body {
      font-family: GentiumTest, Times, Times New Roman, serif;
    }

    Structured this way, browsers that support the WOFF format will download the WOFF file. Other browsers that support @font-face but don’t yet support the WOFF format will use the TrueType version. (Note: IE support is a bit trickier, as discussed below). As WOFF is adopted more widely the need to include links to multiple font formats will diminish.

    Other examples below demostrate the use of WOFF formatted fonts but each example has been constructed so that it will work in any browser that supports @font-face, including Internet Explorer.

    A font family with multiple faces

    Using a Postscript CFF font

    African Language Display

    Below is an example of how downloadable fonts can be used to render languages for which font support is usually lacking. The example shows the UN Declaration of Human Rights, translated into two African languages, and how these render with default browser fonts vs. with a downloadable font suited for rendering these languages.

    Note that in one of these examples that the font size goes from a 3.1MB TTF to a 1MB WOFF font and in the other from a 172KB TTF to an 80KB WOFF file.

    Another Postscript CFF font

    An example in Japanese

    Working With Other Browsers

    Firefox 3.6 will be the first shipping browser to support the WOFF format so it’s important to construct @font-face rules that work with browsers lacking WOFF support. One thing that helps greatly with this is the use of format hints to indicate the format of font data before it’s downloaded; browsers that don’t recognize a given format simply skip data in a format they don’t support.

    Internet Explorer, including IE8, only supports the EOT font format and only implements a subset of the @font-face rule descriptors. This makes creating cross-platform @font-face rules that work with IE especially tricky. One solution is to make different rules for IE:

    @font-face {
      font-family: GentiumTest;
      src: url(fonts/GenR102.eot);  /* for IE */
    }
     
    @font-face {
      font-family: GentiumTest;
      /* Works only in WOFF-enabled browsers */
      src: url(fonts/GenR102.woff) format("woff"); 
    }

    One minor downside of this is that IE doesn’t understand format hints and doesn’t parse @font-face URL’s correctly, it treats format hints as part of the URL, so web authors using the @font-face rules above will see the following in their access logs:

    GET /fonts/GenR102.eot HTTP/1.1" 200 303536
    GET /fonts/GenR102.woff)%20format(%22woff%22) HTTP/1.1" 404 335

    IE successfully pulls down and uses the EOT version of the font but also tries to pull down the WOFF font with the format hint included in the URL. This fails and doesn’t affecting page rendering but it wastes valuable server resources. For more discussion, see Paul Irish’s blog post for one interesting workaround.

    Another problem is that IE currently tries to download all fonts on the page, whether they are used or not. That makes site-wide stylesheets containing all fonts used on site pages difficult, since IE will always try to download all fonts defined in @font-face rules, wasting lots of server bandwidth.

    Further Resources

    Documentation

    Latest draft WOFF specification
    Original blog post on using @font-face
    CSS3 Fonts working draft
    MDC @font-face documentation

    Tools

    Jonathan Kew’s sample encoding/decoding code
    woffTools – tools for examining and validating WOFF files
    FontTools/TTX – Python library and tool for manipulating font data
    Web-based font subsetting tool

    General @font-face Examples

    CSS @ Ten: The Next Big Thing
    Example layout using Graublau Sans
    Examples of Interesting Web Typography
    The Elements of Typographic Style Applied to the Web

    Font Resources

    Font Squirrel
    10 Great Free Fonts for @font-face
    40 Excellent Free Fonts by Smashing Magazine

  2. beautiful fonts with @font-face

    This article is also available in Bulgarian.

    While Firefox 3.0 improved typographic rendering by introducing support for kerning, ligatures, and multiple weights along with support for rendering complex scripts, authors are still limited to using commonly available fonts in their designs. Firefox 3.5 removes this restriction by introducing support for the CSS @font-face rule, a way of linking to TrueType and OpenType fonts just as code and images are linked to today. Safari has supported this type of font linking since version 3.1, and Opera has announced that they plan to support it in Opera 10.

    Using @font-face for font linking is relatively straightforward. Within a stylesheet, each @font-face rule defines a family name to be used, the font resource to be loaded, and the style characteristics of a given face such as whether it’s bold or italic. Firefox 3.5 only downloads the fonts as needed, so a stylesheet can list a whole set of fonts of which only a select few will actually be used.

    /* Graublau Sans Web (www.fonts.info) */
     
    @font-face {
      font-family: Graublau Sans Web;
      src: url(GraublauWeb.otf) format("opentype");
    }
     
    body {
      font-family: Graublau Sans Web, Lucida Grande, sans-serif; 
    }

    Browsers that support @font-face will render text using Graublau Sans Web while older browsers will render text using either Lucida Grande or the default sans-serif face. Example here:



    Digging A Little Deeper

    Most font families today consist of only four faces: regular, bold, italic and bold italic. To define each of these faces the font-weight and font-style descriptors are used. These define the style of the face; there’s no concept of a cascade or inheritance that applies here. Without an explicit definition each of these defaults to a value of ‘normal':

    /* Gentium by SIL International   */
    /* http://scripts.sil.org/gentium */
     
    @font-face {
      font-family: Gentium;
      src: url(Gentium.ttf);
      /* font-weight, font-style ==> default to normal */
    }
     
    @font-face {
      font-family: Gentium;
      src: url(GentiumItalic.ttf);
      font-style: italic;
    }
     
    body { font-family: Gentium, Times New Roman, serif; }

    The sample text below when rendered with this font family:



    A feature that’s easy to overlook is that @font-face allows the creation of families with more than just regular and bold faces — up to nine weights can be defined for a single family. This is true even on Windows, where underlying platform limitations usually restrict font families to just regular and bold weights. Fonts such as those of the Japanese open source M+ Fonts project have as many as seven weights. A selection of these are used in the sample below:



    In some situations, authors may prefer to use fonts available locally and only download fonts when those faces aren’t available. This is possible with the use of local() in the definition of the src descriptor of an @font-face rule. The browser will iterate over the list of fonts in the src descriptor until it successfully loads one.

    /* MgOpen Moderna                      */
    /* http://www.zvr.gr/typo/mgopen/index */
     
    @font-face {
      font-family: MyHelvetica;
      src: local("Helvetica Neue"), 
           local("HelveticaNeue"), 
           url(MgOpenModernaRegular.ttf);
    }
     
    @font-face {
      font-family: MyHelvetica;
      src: local("Helvetica Neue Bold"), 
           local("HelveticaNeue-Bold"), 
           url(MgOpenModernaBold.ttf);
      font-weight: bold;
    }
     
    body { font-family: MyHelvetica, sans-serif; }

    The screenshot below shows from top to bottom the results on Mac OS X, Windows and Linux for a simple testcase that uses the font family defined above:



    The Helvetica Neue font family is available on most Mac OS X systems but generally on neither Windows nor Linux machines. When the example here is rendered on Mac OS X, the local Helvetica Neue faces are used and no font is downloaded. Under Windows and Linux the attempt to load a local font fails and a substitute font — MgOpen Moderna — is downloaded and used instead. MgOpen Moderna is designed to be a substitute for Helvetica, so it renders similarly to Helvetica Neue. This way, an author can guarantee text appearance but avoid a font download when it’s unnecessary.

    The name used to refer to a specific font face is the full name for an individual font. Generally it’s the family name plus the style name (e.g. “Helvetica Bold”). Under Mac OS X, the name is listed in the information panel for a given face. Select a single face and choose ‘Show Font Info’ from the Preview menu in FontBook:

    Similar tools exist under Linux. On Windows, use the font properties extension, a free download from Microsoft to view these names. With the extension installed, the properties panel shows information about an individual font. The full name is referred to as the “Font Name” on the Name tab:

    Safari only supports PostScript name lookup under Mac OS X, so under Mac OS X Postscript names are also supported. For OpenType PS fonts (often labeled with an .otf extension) the full name is the same as the PostScript name under Windows. So for these fonts, authors are advised to include both the full name and the PostScript name for cross-platform interoperability.

    Supporting Many Languages

    Many languages suffer from a lack of commonly available fonts. For minority languages and ancient scripts, the options often dwindle to just a handful. The use of @font-face allows authors using these languages to ameliorate this by including fonts with their pages.

    @font-face {
      font-family: Scheherazade;
      src: url(fonts/ScheherazadeRegAAT.ttf) format("truetype-aat"), 
           url(fonts/ScheherazadeRegOT.ttf) format("opentype");
    }
     
    body { font-family: Scheherazade, serif; }

    Languages such as Arabic require text shaping, where the display of a given character is affected by the characters surrounding it. Different platforms support different rendering technologies to enable text shaping; under Mac OS X, AAT fonts are required while under Windows and Linux OpenType fonts are required. Without a font in a format required for a given platform, text shaping will not be rendered correctly.



    Under Mac OS X, the AAT version of the font is downloaded. On Windows and Linux, where rendering with AAT fonts is not supported, the download of the AAT font is skipped and the OpenType font is used instead. Hence, the text is rendered correctly on all platforms.

    Cross-Site Font Usage

    By default, Firefox 3.5 only allows fonts to be loaded for pages served from the same site. This prevents sites from freely using fonts found on other sites. For sites that explicitly want to allow cross-site font sharing, an online font library for example, Firefox 3.5 supports the use of access control headers to control this behavior. By adding an additional header to the HTTP headers sent with font files, sites can enable cross-site usage.

    # example Apache .htaccess file to add access control header
     
    <FilesMatch "\.(ttf|otf)$">
    <IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
    </IfModule>
    </FilesMatch>

    With this HTTP header enabled, any page can access the fonts on this site, not just pages from the same site.

    Font Licensing Issues

    When using a font for a website, it’s important to always confirm that the font license permits use on a website. If the license agreement is filled with opaque legalese, err on the side of caution and check with the font vendor before using a font on a site. If the license permits its use, it’s a good idea to add a comment near the @font-face rules that points to the license, for future reference.

    “I found a free font, can I use it on my site?”

    Maybe, maybe not. Some free fonts are distributed as teaser products to encourage a purchase and don’t allow for redistribution or posting on a web server. Check the license, even for free fonts.

    “I just want to use [insert favorite font name here] on my site. Is that possible?”

    Right now, probably not. The use of font linking on the web is still in its infancy. Most fonts that ship with proprietary OS’s today have licenses that limit their use to standard desktop applications, so uploading these fonts to a web server is almost certainly not permitted. Piracy has plagued the font industry in the past, so most font vendors are wary of allowing their fonts to be used except in relatively limited contexts. Many font vendors are focused on the needs of publishing and printing industries, and the relative complexity of their license agreements often reflects this. In the future, some font designers may conclude that the sales of fonts as web fonts will outweigh any potential loss in sales due to piracy, others may not. Their license agreements will reflect this choice and should be respected.

    The stock photography market is often described as a $2 billion market but the web font market is still close to a $0 market, it can only go up!

    Font Linking In Internet Explorer

    Font linking has been possible with Internet Explorer but only for linking to fonts in the proprietary EOT font format. The only way to create EOT fonts is to use the Microsoft WEFT tool, available only on Windows. Only TrueType and OpenType TT fonts can be converted to EOT format, OpenType PS (.otf) fonts cannot be used.

    Internet Explorer only recognizes the font-family and src descriptors within @font-face rules, so each family can only contain a single face. It doesn’t understand format() hints and will ignore any @font-face rule containing these hints. This behavior can be used enable font linking cross platform:

    /* Font definition for Internet Explorer */
    /*         (*must* be first)             */
    @font-face {
      font-family: Gentium;
      src: url(Gentium.eot) /* can't use format() */;
    }
     
    /* Font definition for other browsers */
    @font-face {
      font-family: Gentium;
      src: url(Gentium.ttf) format("opentype");
    }

    Future Work

    For Firefox 3.5, the font-stretch and unicode-range descriptors are not supported. Fonts defined in SVG documents are also not supported yet. These are under consideration for inclusion in future releases. As always, patches are welcome!

    Further Resources

    Translations

    Documentation

    Examples

    Font Resources

    Font Politics

  3. after Firefox 3.6 – new font control features for designers

    Note: the discussion below applies to work in progress that might show up in Firefox 3.7. It does not describe features in Firefox 3.6.

    This post is from Jonathan Kew and John Daggett. He’s supplied a 5 minute video that shows some of the features on the fly. If you’re a total font nerd and you enjoy a soothing British accent, you might want to watch it.

    Using @font-face allows web designers a wide palette of font choices and with commercial font vendors supporting the WOFF font format, the set of font choices should improve even more. So the next step is clearly to try and make better use of features available in these fonts.

    For many years, “smart” font formats such as OpenType and AAT have provided font designers ways of including a rich set of variations in their fonts, from ligatures and swashes to small caps and tabular figures. The OpenType specification describes these features, identifying each with a unique feature tag. But these have typically only been available to those using professional publishing applications such as Adobe InDesign. Firefox currently renders using font defaults; it would be much more interesting to provide web authors with a way of controlling these font features via CSS.

    Håkon Wium Lie of Opera, based on discussions with Tal Leming and Adam Twardoch, proposed extending the CSS ‘font-variant’ property to include values for font features. Mozilla is actively working on a new proposal along these lines. This is a fairly big addition to CSS, so it will most likely involve some complex discussions about how best to support these features.

    Experimental Implementation

    As part of this effort, Jonathan Kew has been working on porting a portion of the Pango library for use with handling complex scripts and to enable the use of font features on all supported platforms. He currently has an experimental build that uses a special CSS property to associate a list of OpenType features with specific elements in a page. This is not the proposed format, it simply provides a better way of discussing possible sets of font-variant properties and the OpenType feature settings to which they should map.

    .altstyles {
      /* format: feature-tag=[0,1] with 0 to disable, 1 to enable */
      -moz-font-feature-opentype: "dlig=1,ss01=1";
    }

    The feature setting string above implies rendering with discretionary ligatures (dlig) and the first set of stylistic alternates (ss01). An example using Jack Usine’s MEgalopolis Extra:

    This font makes extensive use of OpenType features; the homepage of the font contains a sample rendering that uses many of these features. Below is a rendering of the same sample written in HTML with OpenType features enabled:

    Tabular Figures for Numerical Alignment

    OpenType features also enable better control over alignment. When numbers are listed in tabular form, proportional forms often result in the misalignment of digits across rows, making the list harder to scan. With tabular alignment enabled, individual digits are rendered using a fixed width so that digits align across rows:

    Automatic Fractions

    Automatic fractions are also possible with OpenType features, note the inline use of fractional forms in the recipe ingredient list below:

    Language Sensitivity

    OpenType also includes support for features on a per-language basis. This is important for rendering text correctly in some languages. For example, Turkish uses both a dotted-i and a dotless-i, so the distinction needs to be preserved when rendering ligatures or small caps. Below is the same text in English and Turkish, with both default and language-sensitive renderings shown for the Turkish text:

    Historical Text

    The way text is rendered constantly evolves; glyphs once in common use often morph into other forms, making the historical forms distinct from their modern forms. Below is the text of an old Massachusetts Bay Colony law, taken from a book in the Daniel R. Coquillette Rare Book Room of the Boston College Law Library.

    Original scanned image:

    Below is the same text rendered in HTML using the Fell Types revival fonts by Igino Marini with OpenType features enabled. Note the ‘ct’ ligature and the contextual form of the ‘s’:

    More resources

    Font feature support in CSS proposal
    OpenType font feature list
    Fell Types revival fonts by Igino Marini

  4. Firefox 4: OpenType font feature support

    When @font-face support was introduced in Firefox 3.5, web authors were suddenly given a way of dramatically enhancing the typography used on their sites.  With all major browsers slated to soon support WOFF fonts offered by many font vendors, the range of fonts available on the web is far wider than it was just two years ago.




    The OpenType format has long provided font designers ways of including a rich set of variations in their fonts, from ligatures and swashes to small caps and tabular figures. The OpenType specification describes these features, identifying each with a unique feature tag but they have typically only been available to those using professional publishing applications such as Adobe InDesign. When glyphs are selected for a particular sequence of characters and positioned for rendering, these features affect both glyph selection and positioning. Firefox currently renders using a font’s default feature settings; it would be much more interesting to provide web authors with a way of controlling these font features via CSS.

    Included among the many new features in Firefox 4 is the next step, support for controlling OpenType font features directly via CSS.  The -moz-font-feature-settings CSS property permits control over kerning, ligatures, alternates, real small caps and stylistic sets to name just a few.

    The CSS3 Fonts specification contains a number of new subproperties of font-variant.  These will eventually provide much better author control over font features but for Firefox 4 only the low-level -moz-font-feature-settings CSS property is supported.  With this authors can enable and disable OpenType font features directly:

    .altstyles {
      /* format: feature-tag=[0,1] with 0 to disable, 1 to enable */
      /* dlig = discretionary ligatures, ss01 = stylistic set 1 */
      -moz-font-feature-settings: "dlig=1,ss01=1";
    }

    For reference, a complete list of registered OpenType features can be found here. The folks at FontFont provide a nice visual guide to OpenType features.

    Ligatures and Contextual Alternates

    Font designers often include simple ligatures and kerning data in their fonts but some go beyond these and spend a lot of time creating special ligatures and contextual alternate glyphs to enhance a given design. The Bello Pro script font from Underware is a brush-like design that includes many special ligatures (click image to view):

    Note the special ligatures for “and” and “by”, the use of all small caps and the use of alternate glyphs to enhance the script connection between the letters in “Smooching”.  Only font styling is used here, all the text can be selected and copied, there are no images used on the example page.

    Number styles

    Using Minion Pro from Adobe, available via Typekit, the example below illustrates the use of tabular, monospaced number forms to display columns of data in a way that’s easy to read and analyze.  When proportional numbers are used, the width of large figures with the same number of digits will vary. Normally this would require using a different, monospaced font.  But with OpenType fonts that provide number formatting features, authors can use a single font without giving up the readibility of large data sets (click image to view):

    Fonts may use either tabular or proportional number forms by default; providing access to these features allows authors to use both proportional figures for inline text and tabular figures for tabular data without the need to switch fonts.

    Automatic fractions

    Recipes for American dishes often use fractional amounts.  These can easily be rendered using the automatic fraction feature in OpenType (click image to view):

    Each of the fractions above is written in simple text form, (e.g. 2 1/2), no special Unicode codepoints are used.  For fonts that support automatic fractions, an OpenType layout engine will automatically generate fractional forms for numbers separated by a slash.  These are typically limited to simple fractions, for more complex math expressions markup languages like MathML should be used instead.

    Language sensitivity

    Many languages often use a common script and over time differences in usage naturally arise.  Serbian, Macedonian and Bulgarian all use the Cyrillic script but with slightly different glyph forms for some common characters.  OpenType fonts support the ability to specify script-specific and language-specific glyph handling so given the correct lang attribute in the markup of a page, Firefox 4 can now render text in a language-specific way (click image to view):

    Arbitrary features

    OpenType defines font feature support using an underlying set of primitives. This allows font designers the ability to create their own features, either for a specialized purpose or as a general feature to be included in a future version of the OpenType specification.  Since the syntax of -moz-font-feature-settings allows for the use of arbitrary feature tags, these can be accessed via CSS.

    In the example below, font designer Erik van Blokland of LettError uses a custom designed set of feature properties to create an interesting animation effect when hovering over text on the page (click image to view):

    HarfBuzz, an OpenType shaping engine

    The process of selecting and positioning glyphs used to display text runs has in the past always been done via platform libraries such as Uniscribe on Windows and CoreText on OSX.  To assure more robust and consistent text rendering across platforms, Firefox 4 will use the open source HarfBuzz OpenType shaping engine on all platforms. In the future this will allow us to integrate support for complex Indic and Southeast Asian scripts that have often been ignored or supported inconsistently in the past.

    A Note About Typekit Use

    All of the Adobe fonts available via the Typekit webfont service provide access to the full range of OpenType features found in the original fonts.  But to access those features you’ll need to explicitly enable “All Characters” under the “Language Support” category in the kit editor dialog before publishing.

    Other examples

    (Updated from a blog post last year):

    Update: the content of the examples is now editable! Edit the text of each example to experiment with the different font features.

  5. the potential of web typography

    This post counts as both a demo and commentary about the changing nature of typography on the web. Ian Lynam and Craig Mod have put together a page that is an excellent example of typography in action, but also offer some suggestions on what the next steps for typography on the web might look like. The page itself takes advantage of a number of typefaces that Craig and Ian got permission to use and uses a pleasing multi-column layout. Please click through to the complete article to get the full effect.

  6. Firefox 4 Demos: Awesome CSS3 Planetarium

    O hai pixel lovers! Check out this gorgeous CSS3 demo: Planetarium, by the LittleWorkshop team (@glecollinet & @whatthefranck).

    planetarium

    Screencast:

    Youtube link.

    Gorgeous Animations

    The principal feature show-cased in this demo is CSS3 Transitions. The animation between the welcome-screen and the planet-screen, and the animation between the different planets are powered by transitions. But there are many little effects in this demo. Take a look at the Twitter button, the ruler, the credit page or the back button. These effects are CSS3 Transitions too.

    Another interesting detail. Next to the planet, you have some different animations. The way the animations is played depends on if you’re coming from the left, the right or from the home screen.

    Try it yourself: Click on the planet Earth, from the home screen. See the text “falling” from the top? Now, go to Mars, and come back to Earth. Now the text is “flying” from the right. Designers will love that :)

    Beautiful fonts

    @font-face allows you to use your own font for creative design. Combined with text-shadow and font-feature-settings, you can accurately forge and style your typographic content.

    Your turn!

    These are features you can use today.
    This demo works perfectly in Firefox 4, Safari and Chrome. Also, Transitions and font-face are easily degradable. Go. Check out the source code, read the documention, and if you’re proud of your code, feel free to submit a demo!

  7. 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
    font_shadow_radius

    Shadows and round corners

    First, we set some style properties on the toolbar:

    -moz-border-radius

    -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

    -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).

  8. font_dragr: a drag and drop preview tool for fonts

    This demo is from our good friend Ryan Seddon who came up with a demo that seems deeply appropriate for this week, given our focus on the future of fonts on the web.

    If you’ve ever been editing a page and wanted to know what a particular font looked like without having to upload files to a web server and update CSS (so tedious, that!) then this demo is for you.

    He’s come up with a demo that shows what’s possible when you’ve got downloadable fonts, drag and drop and editable content. (If you want to know more about drag and drop we suggest you read his excellent overview of using drag and drop to do file uploading.)

    From Ryan’s description:

    Font dragr is an experimental web app that uses HTML5 & CSS3 to create a useful standalone web based application for testing custom fonts, once you visit it for the first time you don’t need to be online to use it after the initial visit. It allows you, in Firefox 3.6+, to drag and drop font files from your file system into the drop area. The browser will then create a data URL encoded copy to use in the page and render the content in the dropped font.

    You can either read the full description, which contains a lot of useful technical information about how the demo works, or you can view the demo below. Either way, it’s nice to see the excellent HTML5 support in Firefox 3.6 coming together with everything else we’ve added to bring a lot of new capabilities to web developers and users.

    Thanks, Ryan!

  9. (r)evolution number 5

    We’ve just launched Firefox 3.5, and we’re incredibly proud. Naturally, we have engaged in plentiful Mozilla advocacy — this site is, amongst other things, a vehicle for showcasing the latest browser’s new capabilities. We like to think about this release as an upgrade for the whole World Wide Web, because of the new developer-facing features that have just been introduced into the web platform. When talking about some of the next generation standards, the appearance of the number “5” is almost uncanny — consider HTML5 and ECMAScript 5 (PDF). The recent (and very welcome) hype around HTML5 in the press is what motivates this article. Let’s take a step back, and consider some of Mozilla’s web advocacy in the context of events leading up to the release of Firefox 3.5.

    Standardization of many of these features often came after much spirited discussion, and we’re pleased to see the prominent placement of HTML5 as a key strategic initiative by major web development companies. Indeed, exciting new web applications hold a great deal of promise, and really showcase what the future of the web platform holds in store for aspiring developers. Many herald the triumphant arrival of the browser as the computer, an old theme that gets bolstered with the arrival of attractive HTML5 platform features that are implemented across Safari, Chrome, Opera, and of course, Firefox (with IE8 getting an honorable mention for having both some HTML5 features and some ECMAScript, 5th Edition features).

    Call it what you will — Web 5.0, Open Web 5th Generation (wince!), or, (R)evolution # 5, the future is now. But lest anyone forget, HTML5 is not a completed standard yet, as the W3C was quick to point out. The editor doesn’t anticipate completion till 2010. The path taken from the start of what is now called HTML5 to the present-day era of (very welcome) hype has been a long one, and Mozilla has been part of the journey from the very beginning.

    For one thing, we were there to point out, in no uncertain terms, that the W3C had perhaps lost its way. Exactly 5 summers ago (again, with that magic number!), it became evident that the W3C was no longer able to serve as sole custodian of the standards governing the open web of browser-based applications, so Mozilla, along with Opera, started the WHATWG. Of course, back then, we didn’t call it HTML5, and while Firefox itself made a splash in 2004, the steps taken towards standardization were definitive but tentative. Soon, other browser vendors joined us, and by the time the reconciliation with W3C occurred two years later, the innovations introduced into the web platform via the movement initiated by Mozilla had gained substantial momentum.

    The net result is a specification that is not yet complete called “HTML5″ which is implemented piecemeal by most modern browsers. The features we choose to implement as an industry are in response to developers, and our modus operandi is (for the most part) in the open. Mozilla funds the HTML5 Validator, producing the first real HTML5 parser, which now drives W3C’s markup validation for HTML5. That parser has made its way back into Firefox. It’s important to note that capabilities that are of greatest interest (many of which are showcased on this blog) are not only developed within the HTML5 specification, but also as part of the W3C Geolocation WG, the Web Apps WG, and the CSS WG.

    The release of Firefox 3.5, along with updates to other modern browsers, seems to declare that HTML5 has arrived. But with the foresight that comes with having been around this for a while, we also know that we have a lot of work ahead of us. For one thing, we’ve got to finish HTML5, or at least publish a subset of it that we all agree is ready for implementation, soon. We’ve also got to ensure that accessibility serves as an important design principle in the emerging web platform, and resolve sticky differences here. Also, an open standard does not an open platform make, as debates about web fonts and audio/video codecs show. We’ve got a lot of work ahead of us, but for now, 5 years after the summer we started the ball rolling, we’re enjoying the hype around (R)evolution Number 5.