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.

One of the most useful things on a 404 page is a direct link to the page visitors were trying to get to. Now we can’t read minds, but we do know the URI (explained in the third paragraph of the previous article) and that’s good enough. The following code is adapted from this archGFX article. The method used to transform the URI into a search query is very simple. If you would like a more advanced please refer to “A better 404 — Redux” at Urban Mainframe, where Jonathan Hollin expounds on his (downloadable!) 404 page code.

There are two parts to this “related posts” code. The first part makes it possible to get from “/wrong/link.html” (the URI) to “wrong link” (the search query).

Here it is:

<?php

$search_term = substr($_SERVER[’REQUEST_URI’],1);

$search_term = urldecode(stripslashes($search_term));

$find = array (“’.html’”, “‘[-/_]’”) ;

$replace = ” ” ;

$search_term = trim(preg_replace ( $find , $replace , $search_term ));

$search_term_q = preg_replace(‘/ /’, ‘%20′, $search_term);

?>

That’s all there is to it. If you, however, don’t want to make “/wrong/link.html” into “wrong link”, but rather just “link” (because the first part of the URI is likely to be useless), use the following on the fourth line:

$find = array ("'.html'", "'.+/'", "'[-/_]'") ;

The second part consists of telling WordPress to use the search terms and outputting a list of articles based on the results.

In this case the loop will output a linked title, a line-break and then the date of the article. You can edit out the line-break and the date if you want. Also, you can change OL to UL if you want an unordered list outputted.

<?php

query_posts(‘s=’. $search_term_q );

if ( have_posts() ) :

?>

<h1>Possibly related content</h1>

<ol>

<?php while ( have_posts() ) : the_post(); ?>

<li><a href=”<?php the_permalink() ?>”><?php the_title() ?></a>

<br>

<?php unset($previousday); printf(__(‘%1$s’, ‘sandbox’), the_date(”, ”, ”, false), get_the_time()) ?>

</li>

<?php  endwhile; ?>

</ol>

<?php else : endif; ?>

That’s all there is to it! Once you’ve added this code your 404 error page should look a little something like this.

To conclude, add the following to your 404.php, wherever you think it fits best, to add :

<?php /* Transforming the URI into search terms */

$search_term = substr($_SERVER[’REQUEST_URI’],1);

$search_term = urldecode(stripslashes($search_term));

$find = array (“’.html’”, “‘[-/_]’”) ;

/* If you only want the last term of the URI, use the following instead:

$find = array (“’.html’”, “‘.+/’”, “‘[-/_]’”) ;  */

$replace = ” ” ;

$search_term = trim(preg_replace ( $find , $replace , $search_term ));

$search_term_q = preg_replace(‘/ /’, ‘%20′, $search_term);

?>

<?php /* Use the search terms to run a query */

query_posts(‘s=’. $search_term_q );

/* check to see if there are posts */

if ( have_posts() ) :

?>

<h1>Possibly related content</h1>

<ol>

<?php /* start the loop */  while ( have_posts() ) : the_post(); ?>

<li><a href=”<?php the_permalink() ?>”><?php the_title() ?></a>

<br>

<?php unset($previousday); printf(__(‘%1$s’, ‘sandbox’), the_date(”, ”, ”, false), get_the_time()) ?>

</li>

<?php /* end the loop */  endwhile; ?>

</ol>

<?php else : endif; ?>

If you’ve any questions, don’t hesitate to ask!

Improve your WordPress: related posts for 404’s originally appeared on Candy by James on 8 January 2009.

Four-Oh-Fours are hot again! Just recently came a across the article A Better 404. I remember reading the A List Apart article “A Perfect 404″ ages ago, but had never done anything about it. Time to improve. 

First some quick vocab: the part after your .com (or .co.uk) is called the URI, so if www.google.com/analytics/provision/ is the address,  /analytics/provision/ would be the URI. The URI is the part that’s wrong when someone’s followed a outdated link which means we can use the URI to create a more helpful 404 page. To create a 404 page for your WordPress theme just create a 404.php file in the directory of your theme (/wp-content/themes/default/ is the default).

The default wordpress 404 page code looks something like this:

<?php get_header(); ?>

<h1>Nothing Found (Error 404)</h1>

<?php get_sidebar(); ?>

<?php get_footer(); ?>

Which I suppose is functional enough, but doesn’t actually help the user much, depending on the content of your sidebar. The first thing to do is to tell programmes visiting  (browsers and more importantly search engine spiders!) that the page is a 404 error page.

You do that by adding the following to the top of your 404.php:

<?php ob_start(); ?>

<?php header(“HTTP/1.1 404 Not Found”); ?>

This “HTTP/1.1 404 Not Found” message tells spiders exactly what they need to know.

Next up, adding useful things for human users! There are three main things you can do to be helpful. Telling the user exactly what’s wrong, giving them a list of related articles and listing your recent articles. Related articles requires some URI magic which I haven’t figured out yet, but Jonathan Hollin has, so stay tuned for an article from him which I’ll link to when the time comes.

Telling the user exactly what’s wrong goes a little something like this:

<blockquote>

<?php // When the visitor is linked through by another site or page

if ($_SERVER[’HTTP_REFERER’]) { ?>

<p>The link at <em><a href=”<?php echo $_SERVER[’HTTP_REFERER’];?>”>

<?php echo chunk_split($_SERVER[’HTTP_REFERER’], 25);?>

</a></em> is incorrect or <em><?php echo $_SERVER[’REQUEST_URI’];?></em> has been moved, renamed or deleted.</p>

<?php } // When the visitor isn’t linked through (most likely a bookmark)

else { 

echo “<p><em>” . $_SERVER[’REQUEST_URI’] . “</em>”;

?>

has been moved, renamed or deleted.</p>

<?php } ?>

</blockquote>

As the comments in the code make clear, there are two situations to tailor for: when people come in from another site and when they don’t. A nice addition is “echo chunk_split($_SERVER[’HTTP_REFERER’], 25)” which echo’s (outputs) the HTTP_REFERER (the site where the user was linked from) in little blocks of 25 characters. This way long URLs still wrap nicely. I chose 25 characters as that’ll put “http://james.gameover.com” all on one line.

That just leaves a list of some recent posts to add:

<h1>Recent Posts</h1>

<ol>

<?php $postslist = get_posts(‘numberposts=6′);

foreach ($postslist as $post) :

setup_postdata($post); ?>

<li><a href=”<?php the_permalink(); ?>”><?php the_title(); ?></a></li>

<?php endforeach; ?>

</ol>

This code simply outputs a linked title of the 6 most recent journal entries in a numbered list. Simple!

So, to recap, you’ll end up with something like this as your final code in the 404.php file:

<?php ob_start(); ?>

<?php header(“HTTP/1.1 404 Not Found”); ?>

<?php get_header(); ?>

 

<h1>Nothing Found (Error 404)</h1>

 

<blockquote>

<? if ($_SERVER[’HTTP_REFERER’]) { ?>

<p>The link at <em><a href=”<?php echo $_SERVER[’HTTP_REFERER’];?>”>

<?php echo chunk_split($_SERVER[’HTTP_REFERER’], 25);?>

</a></em> is incorrect or <em><?php echo $_SERVER[’REQUEST_URI’];?></em> has been moved, renamed or deleted.</p>

<?php } else { 

echo “<p><em>” . $_SERVER[’REQUEST_URI’];

?>

</em> has been moved, renamed or deleted.</p>

<?php } ?>

</blockquote>

 

<p>Don’t worry, just try again!</p>

 

<h1>Recent Posts</h1>

<ol>

<?php $postslist = get_posts(‘numberposts=6′);

foreach ($postslist as $post) :

setup_postdata($post); ?>

<li><a href=”<?php the_permalink(); ?>”><?php the_title(); ?></a></li>

<?php endforeach; ?>

</ol>

<?php get_sidebar(); ?>

<?php get_footer(); ?>

You can visit the final 404 error page here. Many thanks to Jonathan M. Hollin for much of the code and ideas, and to the WordPress Codex and php.net for being such handy recourses.

Update: Added “Possibly related content” to my 404 pages, followup post will come later.

Improve your WordPress: the 404 error page originally appeared on Candy by James on 1 January 2009.

Sites in WordPress (WP) have “posts” which go into categories and “pages”, which are independent. My cunning plan was to name pages exactly the same as the categories I wanted them to describe, and then insert them into the archive page. It has been quite a search to get all the right code, even though the end result looks quite simple!

The first thing you do, is create a category (”One & One”) and create a page (with the title “One & One”). Secondly, you open up your archive.php template file.

You should see something like the following in it:

<?php if (have_posts()) : ?>

And also, further along:

<?php while (have_posts()) : the_post(); ?>

Those two statements start off “The Loop”, which is wordpress lingo for the php-statements which produce the desired output (like posts or lists of them) in a template. We’re going to put our blurb above it. You can also put it under “The Loop” (the “main” loop really) if you so wish — no extra code needed.

Simply put:

<?php

$getcategory = $wp_query->get_queried_object();

$pagetoget = ‘pagename=’ . $getcategory->category_nicename;

$seperate_query = new WP_Query($pagetoget);

/* Next…we start our own WordPress Loop, based on the seperate query (as seen above). That way we can still use the main query! */?>

<?php while ($seperate_query->have_posts()) : $seperate_query->the_post(); ?>

<div id=“blurb”>

<h3>Standard blurb for: <?php echo single_cat_title(”, false); ?></h3>

<?php the_content() ?>

</div>

<br style=“clear:both;”>

<?php endwhile; ?>

<?php rewind_posts(); /* This “rewinds” the loop, so we can use another loop after it safely.*/ ?>

Infront of the start of the main loop in your archive.php, so above of the following line:

<?php if (have_posts()) : ?>

And that’s all the code that’s needed!

Let me explain what the code actually does. The first two lines — $getcategory = $wp_query->get_queried_object(); $pagetoget = ‘pagename=’ . $getcategory->category_nicename; — ask WP for the “category slug” or the “nicename” of the category. That’s the sanitized version of “One & One” in this case, which is “one-one”.

This “category slug” is handy, because “one-one” will also be the “page slug”, so it’ll match the sanitized name of the page we want to insert into our category archive. We get our page by doing — $seperate_query = new WP_Query($pagetoget); while ($seperate_query->have_posts()) : $seperate_query->the_post(); — that starts a new, completely seperate loop from the main loop that will follow.

Then all that’s left is to insert the page’s content like so — <?php the_content() ?> — and then end and rewind the loop with the following statements — <?php endwhile; ?> <?php rewind_posts(); ?> .

You can see I’ve added a div around the content-insertion and <br style=“clear:both;”> after it. That prepares you for any floating-images that may be part of the inserted page’s content. The <h3>Standard blurb for: <?php echo single_cat_title(”, false); ?></h3> is there mainly to know what I’m doing (when working on it) and to seperate it out from the listing of category content that will follow after the blurb. I’ve left it in the example so you know how to get both the sanitized “category slug” and the regular “category title”, which this produces.

This code works in the standard WordPress 2.6 template based on K2 and should work in pretty much all other templates too. Many thanks to Joen and Google for their help.

Inserting pages into category archives in wordpress originally appeared on Candy by James on 9 August 2008.

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.

Now with full-page zoom being implemented (as default!) in Internet Explorer 7, Firefox 3 and Opera 9*, it’s a different story. Full-page zooming means your easy px-based layout will be fully flexible. Even more flexible than most em-based layouts in fact, as images will scale along too.

So I’m asking myself, why bother with hard-to-keep-from-breaking em-based layouts?

[update] I don’t think liquid layouts are relevant anymore either.

[update 2] * And now Safari too! That’s all of the major browsers.

PS. This still leaves percentage-based layouts of course, but they maximise screen real estate. Which is very different from maximising readability (line-lengths and all that jazz). As far as I can see, %-based layouts are good for some web-apps (like gmail) but aren’t optimal for other uses.

Px vs Em: Is it still relevant? originally appeared on Candy by James on 31 March 2008.

However, aside from a few practical issues, microformats are a fundamentally flawed idea.

Microformats are an attempt at client side innovation. Looking at the history of (x)html, javascript and css (the three main client side technologies), you can see it’s rife with incompatibilities. The standardised versions of said technologies have also had (and continue to have) very long market penetration times (the time it takes for the support of a technology to spread among end users).

The funny thing is that these problems can be mitigated by something very simple; server side innovation! It’d have a couple of huge advantages. First-off, it’d give more control over the user experience. Since microformats don’t define how they should be handled by User Agents (UA’s, like browsers or mail clients), you have no way of knowing how your code will exactly be interpreted by them.

Secondly, it allows you to use more compatible technology on the client side (html, css, vCards, pdf, you name it). This means it would work, right now, for everyone. Also, especially for sites that use a CMS (system to manage a sites’ content), server side solutions are a lot easier to implement.

A few examples of microformats, and an explanation why they don’t provide any (business) benefits:

hCard — Have extra mark-up so you can point to an external site which produces a vCard? Mark-up which might force you to deal with UA’s which may mess up the resulting vCard because they interpret hCards differently? Why not just upload a vCard or have your CMS generate a vCard automatically?

hAtom — Making the page itself it’s own feed? So the full, heavy, page can be pinged by feed readers all the time, using far more bandwidth and messing up stats? Are you kidding me?

So yes, I do think that microformats are not worth implementing yourself.

No business benefits for microformats originally appeared on Candy by James on 9 May 2007.

While the other people who were questioned managed to keep it nice and concise, I managed to write up a whole bucket load of words about it. As others asked me why I made sure Bite Size Standards is HTML 4, I’ve decided to post my answer here too.

As published on Elementary Group Standards:

“I’ve used xHTML for 5 years, from 2001 til 2006. My original reason for using it was that it is supposed to be the future. It would have benefits like in-line SVG and MathML. It was presented as TheThingToUse™ with CSS.

There are two things about xHTML which make it a poor choice for (public) sites. Both of them have to do with xHTML’s mime-types. In short, xHTML can be sent with text/html or application/xhtml+xml as the mime-type. On the web xHTML is usually sent as text/html, as Internet Explorer (which has 83+% market share) doesn’t support the other mime-type. Both mime-types are valid for xHTML 1.0, but (supporting) browsers do handle them differently.

It’s the handling of the same code differently where xHTML’s problem lies. When xHTML 1.0 is sent as text/html, it is handled as HTML. This means that it has zero user benefits over HTML 4.01.

When sent as application/xhtml+xml, you could use MathML — but — the browsers will also apply draconian error handling. This way users visiting the site will be punished (by not being able to see the site) for mistakes by the creator (which could be the developer, the CMS, the person updating the text or indeed the user her/himself just writing something). Simple things like a misplaced “&” on a page (instead of “&”) will completely shut off a page from its users.

So not only are there no benefits over HTML 4.01 because you have to send Internet Explorer text/html — you do get user-punishing error handling from other browsers if you decide to send to them the application/xhtml+xml mimetype.

No benefits but increased headaches? Mwa, count me out.

Some people might say ‘but xHTML is the future!’ This may well be, but is of little consequence. The future versions of xHTML (1.1 and 2.0) are not backwards compatible with xHTML 1.0, so writing xHTML now gains you little in the future. Furthermore HTML 5 is coming. Who says that can’t be the future?

My recommendations for writing HTML? Use the doctype ‘HTML 4.01 Strict’ and write your code as xHTML compatible as possible. This means self-closing tags in the body, but not in the head.*

*Little known fact: It’s actually in the spec that you’re not allowed to self-close the meta or link tags. Quite silly in practical terms, and I would suggest to the HTML 5 people that they change that¹.

I hope this answers all the questions people have, but if you have any more (or dare to question my arguments!) don’t hesitate to use the comment form accompanying this journal entry.

Why I use HTML (instead of xHTML) originally appeared on Candy by James on 11 September 2006.

It’s worth noting this doesn’t happen to everyone — just to people who have index.php in front of their permalinks. The fix for this problem is included in 2.0.2, but it’s a bit silly to have to wait until it comes out. Luckily there’s an easy two-step solution to the problem:

1) As per the instructions at Trac Bug Ticket 2379 :

Open the file ‘classes.php’ in your wp-includes/ folder. Find line number 1321; it should look like this:

// Root
(blah blah)

// Comments
$comments_rewrite = $this->generate_rewrite_rules($this->root . $this->comments_base, true, true, true);
$comments_rewrite = apply_filters(‘comments_rewrite_rules’, $comments_rewrite);

That first line in the comments section (in bold) needs another ‘, false’ behind it. That means it should end up like so:

// Comments
$comments_rewrite = $this->generate_rewrite_rules($this->root . $this->comments_base, true, true, true, false);

2) Now go to your ‘Options’ panel in your WordPress admin centre. Click on the ‘permalinks’ tab. If you’ve chosen the 4th option, copy your custom structure to clipboard (ctrl+c). Select the 1st option. Click ‘update permalink structure’. Now select your original option again. If it the 4th, put your custom structure back in again. Click ‘update permalink structure’ again. Or, because an image speaks a thousand words:

That’s all there is to it!

Update: WP 2.0.2 is out, and the fix is indeed included. Remember to use the special upgrade procedure — it’s a quick delete/move & upload this time!

How to fix your WordPress 2.0.1 feeds originally appeared on Candy by James on 10 March 2006.

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.

Now increase text size. (use ctrl + plus or ctrl + scroll wheel up) Ignoring the fact that most of the text remains at exactly the same size, look what it’s done to the model!

So beware: using tables may cause bodily harm.

Using tables may cause bodily harm originally appeared on Candy by James on 31 January 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.