Here’s the results of how current browsers render the test case, compared to the reference rendering.

Can the browser pick up the style natively?

Can the browser emulate from the regular version?

The most up to date support table, with pretty colours, can always be found on its own page alongside the test case. It also has more notes on ligature and small-caps support.

Why is falling back to regular style so bad?

It makes sentences full of expression look like sentences full of expression. Thus removing part of the typographical elements of a text, whereas @font-face is meant to embellish it typographically.

So what does this mean we should do?

Browser developers:

• Please work on emulating bold, italic, bold-italic, etc. when they’re not present. Browsers do this already when it comes to system-fonts, which means web developers expect this to work. Falling back to the regular style (font-style:normal) is horrible as you lose all styling in a text.
• Also give some thought to picking up “font-variant:small-caps;” in your @font-face code. It’s the only way to ensure proper fall-back. Emulating, like Firefox & Opera do, is a step forward, but it’d be a pity to stop there.
• If HTML 5 has taught us anything, it’s that browsers should be more bulletproof, not web designer’s code. Also: asking web developers to specify as little as possible is a better.

Web designers:

• Using @font-face when you only have the regular version of a font at your disposal is not a good idea. Especially for body text.
• If you use small-caps text, chances are visitors will see the fallback system-font. So make sure you specify a system-font that matches your @font-face font nicely when rendered as small-caps. (The test-case uses an especially jarring one on purpose.)
• Using a (less lazy, less practical) more bulletproof way of specifying your @font-face fonts is recommended (alas) for now.

CSS3 @font-face browser support table originally appeared on Candy by James on 20 February 2010.

[update: to get a bit more background on absolute & relative positioning, and how to center horizontally, read:  On Horizontal CSS Centering using Absolute Positioning or how Relative Positioning can rock your css.]

The regular way of vertically centring in css has been documented by Dušan Janovský back in 2004. It needs an extra div for its IE solution, but it doesn’t require any expressions, only regular (fast!) css. Because a div-tag is semantically empty (like the span-tag), it doesn’t add any wrong semantic meaning (like a table-tag would).

The .area div isn’t stricly necessary, but it was in the original problem posed in the css-tricks.com article. I have however edited out the superfluous background declaration, as it doesn’t have anything to do with positioning.

I’ve updated the example to use conditional comments instead of hacks. The html (in your page) becomes:

<div class="area" id="two">
<div class="bubble">
<div>
<p>Doing this may not be as easy or obvious as we would hope.</p>
</div>
</div>
</div>


The css (in your stylesheet) becomes:

.area {width:300px; height:300px; position:relative; float:left; }
.bubble {position:absolute; left:93px; top:21px; width:135px; height:84px; display:table; }
.bubble div {display:table-cell; vertical-align:middle; text-align:center;}


The IE specific css (in your html-page) becomes:

<!--[if lt IE 8]>
<style>
.bubble div {position:absolute; top:50%;}
.bubble div p {position:relative; top:-50%}
</style>
<![endif]–>

Have a look at the demo to see what you should end up with. Questions welcome!

Vertically centring in css (without hacks and multi-line enabled) originally appeared on Candy by James on 14 July 2009.

update: For an overview of current browser support for CSS3’s @font-face see the browser support tables.

Ideally, designers would specify the font-file they wanted to use for regular text, and then one for each variation they had at their disposal (so, one for Bold, Italic, Bold Italic, Small Caps, Light, Ultra Condensed, etc.) – all using the same font-family name, so that all variations would be picked up automatically for body text, and, if @font-face isn’t supported by the browser,  all text will still display in the proper font-variant.

To do that, your css would look something like this:

/* A font by Jos Buivenga (exljbris) -> www.exljbris.nl */
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_R_45b.otf) format("opentype");
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_B_45b.otf) format("opentype");
font-weight: bold;
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_I_45b.otf) format("opentype");
font-style: italic;
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_BI_45b.otf) format("opentype");
font-style: italic;
font-weight: bold;
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_SC_45b.otf) format("opentype");
font-variant: small-caps;
}

This would ensure proper fall-back in browsers that don’t support @font-face (or only part of it) and compatibility with current stylesheets, making @font-face implementation for designers plug-&-play.

The ideal @font-face rendering (on the left) and fall-back rendering (on the right) would look a little like this (notice the fi-ligature!):

You’ll have guessed by now that browsers haven’t reached this ideal implementation yet. You can find the test-case and CSS3 @font-face browser support tables here.

Information in this series was acquired while working on the design and css for the site of Standards.next and subsequent tests afterwards. The Fontface used in this example is Fontin Sans by Exljbris (Jos Buivenga).

CSS3 Fonts: The ideal implementation originally appeared on Candy by James on 12 July 2009.

There are three main ways to define your layout in web design: fixed, elastic & liquid. Having written about the differences between them before, I’ll suffice with stating that fixed layouts are defined in “px” (pixels) and liquid ones in “%” (percentages).

Using a fixed layout means your web page is the same width irrespective of the viewers’ screen width, like so:

Using a liquid layout however, means your web page scales along with the viewers’ screen width, like so:

Liquid layouts used to have an edge over pixel layouts in the sense that they increased use of the screen real estate, thus providing more room if the viewer increased their text-size. Line-lengths are hard to control with liquid layouts, because of varying screen-sizes obviously, but also when the viewer increases (just) the text-size. Jason Kottke posted a good warning about line-lengths in liquid layouts a while back:

Attention liquid designers: take a gander at this portion of an ancient Egyptian parchment on papyrus from the Louvre. Even the ancient Egyptians knew not to make columns of text too wide.

Now, however, most browsers have adopted full-page zooming over text-size zooming. Most provide both, but full-page zooming is the new default. Full-page zooming gives users with a wider screen (for example) the chance to increase the size of text and images, while still preserving the ratios of fixed layout pages, like so:

As you can see, full-page zooming means fixed layouts also provide increased use of screen real estate, but only when needed. In addition fixed layouts keep line-lengths relatively stable, and are easy to work with as they are based on pixels, just like images, videos and other objects you may have on your web page.

Bye bye liquid layouts! originally appeared on Candy by James on 8 June 2008.

Also called ‘fixed’, the first and most used method uses pixel measurements to define the width (& height) of elements on a page. The most obvious advantage to this method — and the reason it’s the easiest to get your head around — is that you get pixel perfect results with it. Photos and other fixed elements on your page will always fit, another huge advantage. That’s also its downfall however, as it doesn’t increase in size as text scales, making the defining of a good line-length quite difficult.

Which brings us to the next, most recent, method dubbed ‘elastic’. The crux of this method revolves around using ‘em’ to define (mainly) widths instead of ‘px’. You’ve already guessed of course that ‘px’ stands of pixel — but how is ‘em’ exactly defined? Well, an ‘em’ is the width a normal ‘m’ takes up on the screen. This method has the advantage of scaling along with the text. That means your line-length will always be exactly as you defined it, but, if an included picture were to take up more width than the current line-length, it’d stick out.

Liquid has been going in and out of fashion for a couple of years now. It uses percentages (defined with ‘%’ in one’s code of course) to define the width of elements. I think it was created with the intention of not squandering precious screen real estate, and while it does maximise the use of the screen, it has several flaws. Given that screen sizes can vary a great deal, a designer can never be certain the line-length is anywhere near correct and whether or not photos actually fit (pushing themselves off the screen, or worse, pushing the design off the screen!).

In my next article (not necessarily the next post!) I’ll talk more about handling the downsides of the methods and how a mix of them is often the most effective (and laden with browser flow errors — yikes!).

Elastic, Liquid, Pixel: Explained. originally appeared on Candy by James on 5 March 2006.

Roger Johansson’s article over at 456 Bereastreet on CSS 2.1 Selectors (part 1)

CSS selectors explained properly originally appeared on Candy by James on 29 December 2005.

[update: read how to do it vertically in: vertically centring in css (without hacks and multi-line enabled).]

The method I use is to have a wrapper div with the following css:

.wrapper {
position:relative;
margin:0 auto;
text-align:left;

width:whatever;
}

For good measure, you’ll need to apply the IE fix:
body { text-align:center; }
And yes indeed, the “text-align:left” of the wrapper makes sure the text aligns to the left again.

Now you’re free to absolutely position the content using the wrapper as reference point. This is due to the fact that an element with position:relative applied to it forces every element inside it (the so called child element) to use the parent as reference, not the viewport (the part of the browser in which a web page is displayed). You could say it resets the reference point of it’s children elements.

This means you can still use absolute positioning while centring the whole page, like so:

.content {
position: absolute;
left: whatever;
top: whatever;

width: whatever;
}

In this specific case, he needed a div to be placed over some Flash content. Good news: It works like a charm for positioning something over Flash!

So there you have it, cross browser centring of absolute & relative positioned divs working in modern browsers such as Mozilla Firefox, Opera & Safari as well as the ye olde Internet Explorer. Hope this lil’ article has been useful to you.

On Horizontal CSS Centering using Absolute Positioning or how Relative Positioning can rock your css. originally appeared on Candy by James on 2 October 2005.