1. I had a look at about 100 different CMS at opensourceCMS.com. (Their demo for each CMS listed there is a pretty cool feature that let’s you at least see one of the most important parts of a CMS at once: the admin interface.) Then I did a bit of research, i.e. googling what others use and like and don’t like and tried a few others which were not listed at opensourceCMS.com.
   A few really popular CMS failed already at that stage: Joomla!, TYPO3, CMS Made Simple, XOOPS, e107 and SilverStripe. (I.e. their admin interface failed to convince me, I haven’t had a look beyond that at that point).
2. In the end I ended up with 18 different CMS I installed and tested more thoroughly.
3. I will go into detail about 7 of them below…

But first…

What makes a good CMS?

In my opinion there are 4 points you have to consider:

Usability of the admin interface

Unfortunately that doesn’t seem to be very important to most developers. But I think it’s so important, I wouldn’t recommend using any CMS with an amazing backend, if its admin interface is crap.

Extensibility

It should be easy to create all the plugins and templates you need without hacking the core.

Sustainability

The community should be alive, at least a few contributors to core, plugins and templates existing, the project’s history should be healthy and the code secure.

Performance

It should use resources in a responsible way, scale on large projects and caching is vital.

How much can you trust my verdict on those 4 points? Well, I’m more of a front-end than a back-end developer and I haven’t used any of the listed CMS in real-life projects except one. It might well be that I will change my mind about a few aspects after having properly worked with them. But I have used a fair amount of other CMS and can compare most features.
So, I’d say at this stage I can judge the usability of the admin interface 100%, extensibility 50%, sustainability 50%, performance 0%.

I wouldn’t necessarily consider the quantity of features or extensions as important. As I didn’t have a certain use case in mind, I was looking for CMS in general. Obviously there is no “best” CMS, as each individual choice always depends on so many things you need to consider. But at least it’s easy to make a first rough decision on the category you need: For smaller projects you don’t need a full blown CMS and it’s more harmful to choose e.g. Drupal for a 12-page brochure website. In those cases you just need a lite CMS.

The problem with WYSIWYG editors

One important point in the admin interface is how editors can edit the content. There are two ways it can go wrong:

• don’t provide just a WYSIWYG editor
• don’t provide just an HTML or simple text editor

Unfortunately those two extremes can be found quite a lot in many CMS. The problem is: If you let your editors edit the content with a WYSIWYG editor, it nearly always destroys the integrity, validity and accessibility of the code and the design of the website. On the other hand, just using HTML is obviously no use to non-technical people and just a simple text editor doesn’t leave you with enough power and flexibility over the text.

The middle and in my opinion best way is using a text markup editor for e.g. Textile or Markdown. Although most clients will be reluctant to try it, make them use it for at least a week, and you’ll see that it’s easier for them than you think. If the editor includes a toolbar, the better. In case your clients are really extremely untechnical, a WYSIWYG editor is fine, as long as it excludes harmful markup, i.e. strip down its functionality (like WordPress does) or use a WYSIWYM editor (like WYMeditor).

You have to balance usability with doing the right thing. It’s important that developers understand that usability is vital for clients and clients understand what harm can be done by choosing to use a full-blown WYSIWYG editor.
In my opinion, a rich CMS which doesn’t provide the right tool here (as a plugin if need be), is an unprofessional choice.

The Verdict

The CMS in the lite category which didn’t make it into the final round: pluck, Symphony, WebsiteBaker and WonderCMS. The latter nearly made it, because I think it’s a brilliant idea to write such a simple and small CMS (11 KB download), but it’s not very client-friendly.

The CMS in the rich category which couldn’t make it: Kryn.cms (which has an interesting admin interface: it looks like a desktop with several windows), MODX, Textpattern (I so wanted to love it, but just can’t) and Zikula.

And finally, here are the remaining seven winners:

Category: Lite

GetSimple

It was nearly a draw between Template CMS (which is the simplest and the smallest of these 4), Elefant (which has the most promising back-end and is the only one of these 4 which needs a database), gp|Easy (which has the most functionalities of these 4 and an inline editor) and GetSimple. They are all very similar in functionality, but if I had to decide between them, I would choose GetSimple, mainly for its clean and most intuitive admin interface.

GetSimple stores its data in XML files, so doesn’t need a database (which can be important in simple setups). It features a simple, stripped-down WYSIWYG editor. Most things I missed in the core can be extended by plugins (e.g. cache and custom fields) and it seems to be more stable than its contenders.

Stacey

Stacey is different. You might argue it’s not even a CMS, because it hasn’t got an admin interface at all. Instead it uses text files and other assets (images, pdfs, etc) in a certain folder structure to build the website and uses Markdown to parse those text files.
Stacey’s own templating language is very easy and simple, it’s build with nice and clean OOP and a proper cache is already built-in. The main negative points are the missing interface and that you cannot swap themes easily.

But I found a simple solution to the missing interface problem: Combine Stacey with OneFileCMS!
Despite its name, OneFileCMS is not a CMS. It’s an online file manager with a simple text editor, which consists of one single PHP file. Just copy that file into Stacey’s “./content/” folder and rename it to “index.php”. Then you can go to your Stacey-build website’s URL and append “content” (e.g. “example.com/content”) and behold, you can login and edit your Stacey files through a simple interface.
Although this solution makes it much easier, it’s admittedly still not very suitable for non-technical people.

Category: Rich

concrete5

Concrete5 has a really good and most intuitive admin interface. The editing is done nearly inline. (Well, you can see the original page, its areas and some controls while you’re editing it, but the editing itself happens in a modal window.) Its concept of different block types you can add to any area (not just e.g. WYSIWYG content, but also navigations, videos, page lists, etc) makes it very flexible. This block concept is similar to REDAXO’s concept of modules, but in concrete5 it’s done in a much nicer way. But unfortunately all of those fancy editing options come with a price: The essential parts of the admin won’t work without JavaScript.

One thing which some people might consider an issue: Some of concrete5′s add-ons cost money. Personally, I am fine with that. The only issue which could arise from it is that it will be impossible to support unmaintained add-ons.

Its OOP back-end follows MVC principles only half-heartedly, but seems quite powerful. As this CMS is getting more popular every day, it should be on everyone’s “must try out” list.

Drupal

It’s daunting to write anything about Drupal. Because so many people hate it and so many people love it, and my knowledge about it only just scratched its surface.

From trying to find out why so many developers don’t like Drupal, I gathered it’s mainly because it’s so popular and therefore it’s often used in cases where it shouldn’t be used. (The same goes for WordPress, by the way.)

But from what I saw it’s up there among the top of the most popular CMS for a reason. I wouldn’t consider it to be the best out there, there are too many things I don’t like: The way you can switch between editing and viewing a page is against all common usability sense (the tabs involved don’t function as tabs), forms in the admin are confusing (they all look the same, no matter if they are for real content or just for meta content) and the back-end looks “historically grown”. But the concept of the different components working together looks right to me. And whenever I look up how something works, it becomes clearer to me how powerful it really is.

ProcessWire

ProcessWire looks really exciting. The concept is good, the OOP back-end well thought-through and its API takes a refreshingly different approach as it is inspired by jQuery‘s syntax.

Its templating and editing concept is similar to Drupal’s: Templates are populated with the help of fields. And the values of those fields are used in the templates. (It also utilizes a lot of small modules.)
What I don’t like about this is that it means each template is fixed and less flexible (the same goes for Drupal). And unfortunately it hasn’t got any concept of themes yet. (While that is true, I learned that it’s intentional and an important part of its concept not to have themes.)

It’s promising, but it somehow seems to me it’s not quite done yet (e.g. you cannot edit anything without JavaScript) and things might still change. I will definitely keep an eye it.

REDAXO

REDAXO was my favourite CMS for a long time. Its module concept and editing flexibility is something I haven’t come across in any other CMS before. It might sound strange, but there are very few other CMS with which you can freely add any kind of content in any kind of order. But now concrete5 (see above) is a contender for that.

The only reason why I cannot really recommend this CMS is because its documentation (and website and even inline code comments) are mostly in German. This is its biggest flaw and I think the main reason why it’s quite unknown in the CMS world.

One piece of news which gives some hope: Last year a fork of REDAXO, named Sally, was born and it already looks really promising: It’s cleaner, faster and more open.
But unfortunately the makers of Sally haven’t learned from their sister’s mistake: Everything is still only in German. Apart from that, they made the unprofessional choice to require PHP Short Open Tags. But they are still in pre-alpha stage, so let’s hope and check back in a few months.

Wolf CMS

Wolf CMS is my personal winner. It’s a fork of Frog CMS which again is a PHP port of Radiant CMS (written in Ruby).
Although it’s not as sophisticated as Drupal or concrete5 (and might even be seen as a lite CMS), it seems to be doing everything right. Its OOP MVC back-end is really clean and makes sense. The admin interface is extremely easy to use. Its core editor uses either Textile or Markdown (or PHP/HTML) with an editing toolbar.

Its main strength is simply its simplicity.

In my opinion there are only two things missing to make it perfect: The possibility to enter structured content (which also includes different types of content) and the possibility to store the layouts on the file system (which is also a flaw of REDAXO).
What could also improve: More people should be using it!

Update (30 October 2011): I updated ProcessWire’s info box to show Ohloh widgets like the rest. (As it was not on Ohloh, I just created that project there myself.)

Update (7 December 2011): I corrected some information for ProcessWire.

I recently brought a bag of gummi bears to work. When I arranged a few complete sets of all available flavours by colour as usual (a little OCD, I know ), I asked a colleague who was sitting next to me: “Which is the odd one out?”
I didn’t ask out of interest, because I assumed she would agree with me on the answer to that question anyway. I guess I only wanted to show that beautiful pattern. But the surprising thing was: She didn’t agree with me and picked a completely different colour…

After asking more and more colleagues it got even more surprising: Most people not only picked different colours, but they often had a completely different reason for it!
I thought the answer was obvious but apparently it isn’t…

So, before you read what everyone has replied further below, first look at the following image and think for yourself (and reply in the comments, especially if it’s different):

Which is the odd one out? And why?

Here are the results:

Person	Colour	Reason	Had difficulties deciding
me	green	the pattern follows a gradient from red to white, green doesn’t fit into that gradient	no
MM	dark red or red	there should only be one kind of red	no
EB	dark red or white	it’s either the darkest or the lightest	yes
CL	white	white is not a colour	no
RL	white	white is not in the rainbow	no
RS	green	it doesn’t fit into the gradient	no
CH	white	it’s the only transparent one	yes
RD	white	it’s the only colour not in traffic lights, and it’s not in the prism (as it creates the prism, “it’s the prism bear” )	no
RT	green	it doesn’t fit into the gradient (he also tried to find the odd one out of the fruits those colours represent, but couldn’t find one)	no
IJ	white	(I don’t remember what he said )	yes
ES	dark red	just a feeling, doesn’t know why	no

It’s also important to note that some people didn’t look at the colours at all and tried to find differences in shape or how they were positioned in my hand. Those people were mostly the ones who had trouble deciding on any colour.

So, where does this experiment lead to? What does it say about people? I don’t know!
Some people asked afterwards, what the correct answer was. Obviously, there is none!
Although, I can imagine there are some lessons to learn from this and psychologists or sociologist can deduce something from it!? (If anyone knows more, I’d love to hear about it.)

The only thing I have learned from this so far is: If you think something is obvious, it obviously isn’t!

1. 1
2. 2
3. 4
4. 5
5. 8
6. 16
7. 20

1

Wrong.
I hope, there’s no need to explain further.

2

Wrong.
This answer might be given by beginners who think there’s only a and a:hover.

4

Still wrong.
Although this answer might be given by most developers who think of :link, :visited, :hover, :active.

5

A good answer, but still wrong. (But I wouldn’t fail this one.)
The one missing state from the 4 above is :focus. Professional web developers should always think about :focus for accessibility and usability reasons.

8

Nearly correct.
This might surprise most of you, as nearly all CSS tutorials, books and other resources only talk about the aforementioned 5. The reason why there are more states is not that any is missing from those 5. The problem is that they are two different kinds of states, which are styled differently with link pseudo-classes and dynamic pseudo-classes! A link is either visited or not visited, and, on top of that, a link is reacting to user interactions hover, active and focus. To make the difference clearer, ask yourself: How do you set a style to a visited link that is active?

All the 8 combinations are:

:link,
:link:hover,
:link:focus,
:link:active,
:visited,
:visited:hover,
:visited:focus,
:visited:active

In most cases web developers set link/visited and hover/active/focus to be the same. That makes sense, but from an usability and accessibility point of view, you might want to differentiate. At least you should think about it and, if you choose not to differentiate, you should make it a deliberate decision rather than forget about them.

16

Correct.
I wrote “nearly correct” to this answer of “8″, because you can also combine the dynamic pseudo-classes (link pseudo-classes are mutually exclusive, while dynamic pseudo-classes are not). This gives much more possibilities, i.e.

:link:hover:focus,
:link:hover:active,
:link:focus:active,
:visited:hover:focus,
:visited:hover:active,
:visited:focus:active,
:link:hover:focus:active,
:visited:hover:focus:active

Admittedly, they are a bit ridiculous in most cases (especially the last two).

20

Wrong.
I just put it there to confuse you.

Further information

These articles are very old, but still relevant:

• Notes on suggesting link styles
• A revised method of defining link pseudo-classes

80 variations of "Sh*ved P*ssy" (click image to see all)

Okay, it’s actually not that surprising. But when I posted the picture, I didn’t think that far. However, the funniest thing is this list of 80 search queries I found in my Google Webmaster tools, all more or less synonyms of the term “sh*ved p*ssy”.

(By the way, I’m not using the asterisks because I’m ashamed of writing the actual words. I just like to avoid to invite even more visitors who don’t really want to be here.)

Then I found the answer in a great new service that’s perfect for this kind of thing:
SocialCompare.com

It lets you easily create and edit comparison tables.
You can compare just about anything you can think of. Anyone (well, any registered user) can edit the tables (i.e. items and criteria) or knock something together out of already existing items. It’s more future-proof as it’s easier to update and less error-prone (if the community is there to help to maintain it). It is well thought out: You can re-arrange items and criteria to see more easily what’s important to you.

This takes the wiki concept to the next level.
If you love spreadsheets (like me), you’ll love SocialCompare.

Here is a preview of the Comparison of CSS Playing Cards I created:

Don’t get me wrong, reset styles serve their purpose. They are good for beginners and many intermediates and can save them a lot of trouble. It’s better to use reset styles if you’re not sure why basic styles might be better than not to use any of those two concepts.
Reset and basic styles alike should serve as a reminder to overwrite browser presets.

I don’t see the reason why you might declare, say, the first headline to have no margin (h1 {margin: 0;}), only to redeclare it to have a bottom margin (h1 {margin-bottom: 1em;}) a few lines later.
Basic styles should set all styles instead of resetting them. In order to make reset styles unnecessary, you only need to make sure to style every element and their necessary properties which browser default styles might add. And declare everything else that makes sense in your case.

So, ideally you should set and reset what you need at the same time. That’s what I’m doing with my basic styles.

Most of these styles are quite universal. I tried to keep them as generic as possible (e.g. with many shades of grey). But they are not meant to be taken without adjusting them to each project. You most likely want to change everything I marked with “§font”, “§fsize” and “§colour”.

They are already part of my DokuWiki Starter template and will therefore be part of the new (soon to come) DokuWiki default template. I will provide an always up-to-date version apart from the following current version (2011-05-08):

/**
 * Basic Styles
 *
 * You will most likely want to change the font stacks, font sizes and colours. Search for the following:
 * * §font
 * * §fsize
 * * §colour
 *
 * @version 2011-05-08
 * @link    http://blog.selfthinker.org/2011/05/08/basic-is-the-new-reset/
 * @license CC0 [http://creativecommons.org/publicdomain/zero/1.0/]
 * @author  Anika Henke <anika@selfthinker.org>
 */

html {
    overflow-x: auto;
    overflow-y: scroll;
}
html, body {
    background-color: #fff; /* §colour  */
    color: #333; /* §colour */
    margin: 0;
    padding: 0;
    height: 100%;
}
body {
    font: normal 100%/1.4 Frutiger, "Frutiger Linotype", Univers, Calibri, Myriad, "Liberation Sans", Tahoma, Geneva, "Helvetica Neue", Helvetica, Arial, sans-serif; /* §fsize §font */
    /* default font size: 100% => 16px; 93.75% => 15px; 87.5% => 14px; 81.25% => 13px; 75% => 12px */
}

/*____________ headings ____________*/

h1, h2, h3, h4, h5, h6,
caption, legend {
    font-family: Constantia, Utopia, Lucidabright, Lucida, Georgia, serif; /* §font */
    font-weight: bold;
    line-height: 1.2;
    color: #666; /* §colour */
    background-color: inherit;
    padding: 0;
    clear: both;
}

h1 { font-size: 2.25em;  margin: 0 0 0.444em; } /* §fsize */
h2 { font-size: 1.5em;   margin: 0 0 0.666em; } /* §fsize */
h3 { font-size: 1.125em; margin: 0 0 0.888em; } /* §fsize */
h4 { font-size: 1em;     margin: 0 0 1.0em; } /* §fsize */
h5 { font-size: .875em;  margin: 0 0 1.1428em; } /* §fsize */
h6 { font-size: .75em;   margin: 0 0 1.333em; } /* §fsize */
/* bottom margin = 1 / font-size */

/*____________ basic margins and paddings ____________*/

p, ul, ol, dl, pre, table,
hr, blockquote, fieldset, address {
    margin: 0 0 1.4em 0; /* bottom margin = line-height */
    padding: 0;
}

div {
    margin: 0;
    padding: 0;
}

/*____________ lists ____________*/

ul, ol {
    margin-left: 1.5em;
    padding: 0;
}
li, dd {
    margin: 0 0 0 1.5em;
    padding: 0;
}
dt {
    font-weight: bold;
    margin: 0;
    padding: 0;
}

li ul, li ol, li dl,
dl ul, dl ol, dl dl {
    margin: 0;
}
li li {
    font-size: 100%;
}

ul             { list-style: disc outside; }
ol             { list-style: decimal outside; }
ol ol          { list-style-type: lower-alpha; }
ol ol ol       { list-style-type: upper-roman; }
ol ol ol ol    { list-style-type: upper-alpha; }
ol ol ol ol ol { list-style-type: lower-roman; }

/*____________ tables ____________*/

table {
    border-collapse: collapse;
    empty-cells: show;
    border-spacing: 0;
    border: 1px solid #ccc; /* §colour */
}
caption {
    caption-side: top;
    text-align: left;
    margin: 0 0 .3em;
}
th, td {
    padding: .3em .5em;
    margin: 0;
    vertical-align: top;
    text-align: left;
    border: 1px solid #ccc; /* §colour */
}
th {
    font-weight: bold;
    background-color: #eee; /* §colour */
    color: inherit;
}

/*____________ links ____________*/

a {
    background-color: inherit;
}
a:link, a:visited {
    text-decoration: none;
}
a:link {
    color: #00c; /* §colour */
}
a:visited {
    color: #606; /* §colour */
}
a:link:hover, a:visited:hover,
a:link:focus, a:visited:focus,
a:link:active, a:visited:active {
    text-decoration: underline;
}
a:link:focus, a:visited:focus {
    outline: 1px dotted;
}
a:link:active, a:visited:active {
    color: #c00; /* §colour */
}

/*____________ forms ____________*/

form {
    display: inline;
    margin: 0;
    padding: 0;
}
fieldset {
    padding: 1em 1em 0;
    border: 1px solid #999;
}
legend {
    margin: 0;
    padding: 0 .1em;
}
label {
    vertical-align: middle;
    cursor: pointer;
}
input, textarea, button,
select, optgroup, option {
    font: inherit;
    color: inherit;
    /* background-color destroys button look */
    line-height: 1;
    margin: 0;
    vertical-align: middle;
}
input[type=text], input[type=password], input.text, textarea {
    padding: .1em;
}
input[type=radio], input[type=checkbox], input.check {
    padding: 0;
}
input[type=submit], input.button, button {
    cursor: pointer;
}
input[disabled], button[disabled],
input[readonly], button[readonly] {
    cursor: auto;
}
optgroup { font-style: italic; font-weight: bold; }
option   { font-style: normal; font-weight: normal; }

/*____________ misc ____________*/

img {
    border-width: 0;
    vertical-align: middle;
    color: #666; /* §colour */
    background-color: transparent;
    font-style: italic;
}

hr {
    border-style: solid;
    border-width: 1px 0 0;
    text-align: center;
    height: 0;
    width: 100%;
    clear: both;
}

acronym, abbr {
    cursor: help;
    border-bottom: 1px dotted;
    font-style: normal;
}

pre, code, samp, kbd {
    font-family: Consolas, "Andale Mono WT", "Andale Mono", "Bitstream Vera Sans Mono", "Liberation Mono", Monaco, "Courier New", monospace; /* §font */
    font-size: 1em;
    direction: ltr;
    text-align: left;
}
pre {
    overflow: auto;
}

blockquote {
    padding: 0 1.25em;
    border: solid #ccc; /* §colour */
    border-width: 0 0 0 .25em;
}
q:before, q:after {
    content: '';
}

sub, sup {
    font-size: .8em;
    line-height: 1;
}
sub {
    vertical-align: sub;
}
sup {
    vertical-align: super;
}

/*____________ text direction ____________*/

[dir=rtl] caption,
[dir=rtl] th {
    text-align: right;
}
[dir=ltr] caption,
[dir=ltr] th {
    text-align: left;
}

[dir=rtl] ul, [dir=rtl] ol {
    margin-right: 1.5em;
    margin-left: 0;
}
[dir=ltr] ul, [dir=ltr] ol {
    margin-left: 1.5em;
    margin-right: 0;
}
[dir=rtl] li, [dir=rtl] dd {
    margin: 0 1.5em 0 0;
}
[dir=ltr] li, [dir=ltr] dd {
    margin: 0 0 0 1.5em;
}
[dir=rtl] blockquote {
    border-width: 0 .25em 0 0;
}
[dir=ltr] blockquote {
    border-width: 0 0 0 .25em;
}

/*____________ general classes ____________*/

.box {
    margin-bottom: 1.4em;
    padding: 1em 1em .2em;
    background-color: #ddd; /* §colour */
    color: inherit;
}

/* hide something in an accessible way */
.a11y {
    position: absolute;
    left: -99999px;
    top: -99999px;
    width: 0;
    height: 0;
    font-size: 0;
    overflow: hidden;
    display: inline;
}

.clear {
    clear: both;
    height: 0;
    line-height: 0;
    font-size: 1px;
    visibility: hidden;
}

/* one of the many clearfix versions */
.group {
    display: inline-block;
}
.group {
    display: block;
}
.group:before,
.group:after {
    content: "";
    display: table;
}
.group:after {
    clear: both;
}

As I am constantly learning, these styles are subject to change and improve. What will be added at some point: Basic styles for HTML5 and printing.

If there is any interest, I could explain most of my reasons for nearly all of the styles in subsequent posts.

But while researching all the missing bits myself, why not share it and collaborate with others who would help researching? Sounds already like a wiki, eh?
And then I read about and was fascinated by the history of the different editions and translations of the memoirs. The early editions are old enough to be in the Public Domain, so it’s easy to use them in the wiki as a basis for the annotations. So, why not present the most popular editions (French, English, German) side by side?

Well, that’s exactly what I did … I’m proud to present:
Paralis.org – The Annotated Casanova Synopsis Wiki

It’s a long way from being finished, but it’s a good start. Now I only need to keep it alive and search for collaborators.

No, I don't know what happened to that poor cat. I guess it must have had some kind of surgery ...

First, let’s recap what others have done before:

• Playing Cards with CSS by Mike Hall was quite innovative at the time, but is very old by now (it is from 2001). Too much markup, only half semantic, but scalable and they don’t use any CSS3 goodness (because CSS3 didn’t exist back then).
• XHTML/CSS Playing Cards by Jerry Sievert are half semantic, the amount of markup is okay-ish and they are the most accessible out of these four, but they are not scalable and don’t belong to the beautiful kind.
• Creating playing cards with CSS & HTML by Jamie Taylor are quite beautiful, but are very unsemantic, not scalable and have a tad bit too much markup.
• CSS Playing Cards by Kevin Thompson are my personal favourites out of these four. They are really beautiful, are scalable (although the way they are built doesn’t display too well if the cards are too small) and plays neatly with CSS3. But although the class names are semantic, the markup (which again, is too much) is not semantic at all and completely inaccessible, i.e. it’s empty and contains no information about the cards if you turn CSS off.

Why my CSS Playing Cards are better? Well, they contain less markup, they are much more semantic and accessible (so they even make sense in Lynx), they are perfectly scalable and good looking.
The only negative thing: The CSS only works in modern browsers. (Tested on Win Firefox 3.6.8, Opera 10.61 and Chrome. Internet Explorer 8 cannot deal with many of the CSS3 goodness, but what makes the code unusable in IE8 is the lack of support for the “:nth-child(n)” selector. I implemented a rudimentary fix, though.)

And here’s the proof. This is the basic markup (only two spans in one div):

<div class="card rank-7 spades">
    <span class="rank">7</span>
    <span class="suit">&spades;</span>
</div>

Here is one example of a hand:

• 2♦
• 3♥
• 4♠
• 5♣
• 6♦
• 7♥
• 8♠
• 9♣
• 10♦
• J♥
• Q♠
• K♣
• A♦

And this is how it looks in Opera

Want more? You can see more examples or you can implement them and check out the code on GitHub as I open-sourced it, of course.

Update (2 December 2010):
And I found another version:
CSS Cards by Jeff Yaus are semantic, highly scalable, a bit weird looking, have the least markup of all so far, but are unfortunately not accessible at all.

Last Update (28 May 2011):
And I found another variety… But from now on I won’t update this post anymore, but will update my Comparison of CSS Playing Cards on SocialCompare.com instead.

Really Last Update (12 June 2011):
I just updated my CSS Playing Cards. Get the new version from GitHub.
And additionally I built a beautiful new project page.

Go to the address bar in your favorite browser and type one letter.

As I have three favourite browsers I use on a daily basis, a simple list won’t do. So, here are mine in a table per browser:

	Chrome	Firefox	Opera
A	amazon.co.uk	abcwiki.selfthinker.org	amazon.co.uk
B	bugs.splitbrain.org	bugs.splitbrain.org	blog.selfthinker.org
C	channel4.com	cv.selfthinker.org	cv.selfthinker.org
D	dict.leo.org	dokuwiki.org	dokuwiki.org
E	en.wikipedia.org	en.wikipedia.org	easyjet.com
F	forum.dokuwiki.org	friendfeed.com	firezza.co.uk
G	google.co.uk	google.de	google.de
H	heise.de	https://banking.postbank.de	http://wiki/ (my local development wiki)
I	imdb.com	bbc.co.uk/iplayer	irclog.dokuwiki.org
J	journeyplanner.tfl.gov.uk	journeyplanner.tfl.gov.uk	-
K	-	tvguide.co.uk	-
L	lebara-mobile.co.uk	localhost	-
M	my3.three.co.uk	maps.google.co.uk	maps.google.co.uk
N	natwest.com	natwest.com	nationalrail.co.uk
O	ofdb.de	ofdb.de	opera.com
P	php.net	https://banking.postbank.de	php.net
Q	-	-	-
R	redaxo.de	reed.co.uk	-
S	splitbrain.org	splitbrain.org	slideme.org
T	three.co.uk	twitter.com	textpad.com
U	uk.androlib.com	update.dokuwiki.org	-
V	votematch.org.uk	config.variomedia.de	-
W	www.dokuwiki.org	www.dokuwiki.org	http://wiki/
X	-	xing.com	-
Y	youtube.com	youtube.com	-
Z	zumodrive.com	twitter.com/zombooloo (account deleted)	-