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.

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.

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.

I first thought about personalising my online CV to match these colours (with hair colour at the top, lip colour at the bottom and eye colour for links, etc). But somehow my body colours don’t make good website colours.

Instead I played around with those colours and created a pure HTML and CSS “image” of myself (the core code consists of just five divs). Et voilà, here it is.

You will only see the full beauty of it if you use a modern browser (and can see). It’s funny how IE6 still shows something which is recognisable as a face, but turns it into some kind of a monster:

Beauty is in the eyes of the browser

I’m not a ‘Twitter person’ … I’m more of a ‘Shh person’. I subscribed to this ‘Shh network’, where you write something down, but don’t send it anywhere.

I thought someone might have picked this idea up or had the same idea before, but my short search for such an (obviously hoax) service was unsuccessful. So, I created one myself:

Shh…

Apart from the fun of “cloning” Twitter, writing a better front-end code and having the satisfying feeling of implementing a small project all in one day, I also had the idea of twittering silence on twitter itself. You can follow my as interesting as everybody else’s tweets on:

@_shh

By the way, I needed the underscore because a twitter user called ‘shh’ already existed … as did ‘shhh’ … and ‘shhhh’ … and ‘shhhhh’ … I could have taken ‘shhhhhhhhhhhhhhh’, but maybe that wouldn’t have been such a good idea. Seems a bit desperate, doesn’t it?

These two projects are really a bit unrelated. They serve the purpose of linking to each other. (Yeah, my middle name is “PR”. Or was it “SEO”? Where is your birth certificate when you need it?)
And, of course, they share the same philosophy: “Silent twittering” for fun and more privacy awareness.

What I was looking for:

• usable in a production environment: should work in all major browsers
• should satisfy designers: should make it possible to have fancy borders, gradient backgrounds, drop shadows, etc
• should satisfy coders: usable, accessible, semantic (to a certain extent), no JavaScript, not too many unnecessary extra elements or hacks
• flexible: resizable, shrink-wrappable, same code for big boxes or small link buttons, easy to maintain, easy to adjust
• optional: creating them should not involve too much work

Nearly every technique I used before needed a fixed width or had only two rounded corners or had other drawbacks. I had only found one single technique that fulfilled all my basic needs, but was not very handy to use and had other limitations (such as no way to do a decent hover effect, difficult to maintain and one annoying bug in IE 6).

While I was searching for a new technique I came across one which already came quite close: Creating bulletproof graphic link buttons with CSS

But this technique has a few drawbacks:

• Additional to one big background image with all of the necessary elements in it, it also uses a second one just for the corners.
• It cannot handle fancy backgrounds.
• It doesn’t allow nesting of elements with rounded corners.
• Using the same technique for other elements needs adjusting.
• No fancy hover effects are possible.

So, I fiddled around with it and improved and enhanced it. Here is how:

The original solution

0. The Original

I won’t repeat what Roger Johansson wrote in his original article. I recommend reading it first to understand what I’m talking about.

Step 0: The Original (Demo)

1. One Background Image

The first thing I wanted to get rid of is this strange second background image. Although the corner.gif image contains all of the four corners with a lot of transparent space in between them, the original technique uses it only for the top right and bottom right corner. So, at least 90% of that image is not really needed.

I soon noticed that the bottom right corner does not need to use corner.gif, but can use the normal button.gif just like the rest. So, the only thing to fix was the top right corner.

Every other corner is easy to position because each previous element has a padding exactly where the following element cannot overlap the previous corner. The only tricky bit is the first corner that isn’t “protected” by a previous padding: the top left one. To “protect” the top left corner nonetheless, I just gave the first span a left margin, which I removed again from the second span with a negative margin of the same value. Et voilà, no second image needed.

Step 1: One Background Image (Demo)

2. One Span Less

Then I wondered: Why are there five background image placements and not four? The last innermost span has the background strangely attached to “right center”. And sure enough, I could safely delete the last span and thus could get rid of one unneeded span (13 characters per rounded element after all).
The padding from that deleted span is plainly added to the preceding span.

Step 2: One Span Less (Demo)

3. Fancier Background

Why should it be “tricky to give the button a non-flat background colour”? Mainly because the last, innermost span defines what the major part of the button looks like. Only because the original version chose that to be from the bottom right (and therefore without the 6px on the top and on the left) it is difficult to use an image with a gradient higher than 6px. It could use a much bigger gradient on the bottom without any problems, though.

But as gradients are mostly found at the top, I  simply turned the order around from “top left > top right > bottom left > bottom right” to “bottom left > bottom right > top left > top right”. And now you can have much higher gradients (as high as the container could get minus the 6px at the bottom).

Step 3: Fancier Background (Demo)

4. Rearrangement

Then I rearranged the code a bit, basically to removed things unrelated to the link nature from .button:link, etc and to move every occurrence of the background image to one single line, so that it’s easier to exchange.

I also fixed a bug in IE 6 introduced with the fancier background changes: IE 6 doesn’t like a bottom padding on the now innermost span.

Step 4: Rearrangement (Demo)

5. Hover

With those changes it is much easier to exchange the background image on hover with just a few more lines of code.

Step 5: Hover (Demo)

6. Hoverissimo

Some time ago my boss wished a link button that exchanges the gradient on hover from top to bottom. With this technique the only problem was the aforementioned problem that you can either have a link button with its main background at the top or at the bottom. To be able to exchange these background gradient positions, I had to turn the order of the background position around again (as in Step 3) as they were before, but this time only for the hover state.

Step 6: Hoverissimo (Demo)

7. Other Button Types

Now adding other different button types is a piece of cake: Simply add another class for each new type and give it a different background image (and change the background and font colour accordingly, if necessary).

Step 7: Other Button Types (Demo)

8.More Universal

Now there are only two problems left: If you plan to use this code not only for link buttons, but also for bigger boxes with block elements, you cannot use the code as it is now. You could just exchange the spans with divs and duplicate each line in the CSS code to accommodate that. But what if you have to use another div in there?

Although I’ve normally long outgrown the ‘classitis’ phase, in this case I think, using classes makes the code much more flexible to use. It reduces the CSS code, but increases the HTML again (by 42 characters per rounded element).
And I normally like to give semantic class names, but here rounded corners itself have no semantic meaning, so I contended myself with giving the classes names that are short and have a functional meaning instead. I also renamed “button” to “rounded”, because as soon as this technique isn’t used on a link button, its name would be erroneous.

Step 8: More Universal (Demo)

The new solution

9. Any Container

Finally, with these former changes it is now possible to use this technique on any container, not only on links or inline elements, but on bigger boxes, too. And these rounded containers can even contain other rounded containers.

Step 9: Any Container (Demo)

Final Code

My final basic code (without the “hoverissimo” code for the sake of brevity):

<a class="rounded <type>" href="#">
  <span class="i1 bg"><span class="i2 bg"><span class="i3 bg">
    Link
  </span></span></span>
</a>

<div class="rounded <type>">
  <div class="i1 bg"><div class="i2 bg"><div class="i3 bg">
    <p>Block level content</p>
  </div></div></div>
</div>

.rounded,
.rounded .bg {
  background-repeat: no-repeat;
  display: block;
}
.rounded {
  float:left;
  background-position:left bottom;
}
.rounded .i1 {
  padding:0 0 9px;
  background-position:right bottom;
  margin-left: 6px;
}
.rounded .i2 {
  padding:0 0 0 6px;
  background-position:left top;
  margin-left: -6px;
}
.rounded .i3 {
  padding:9px 12px 0 6px /* no bottom padding because of IE6 */;
  background-position:right top;
}

/* for each type */
.<type>,
.<type> .bg {
  background-image: url(<type_image>.gif);
  background-color: <type_background_colour>;
  color: <type_font_colour>;
}
/* for hover effect on links */
a.<type>:hover,
a.<type>:hover .bg {
  background-image: url(<type_hover_image>.gif);
}
/* left out :link, :visited, :active and :focus state
   for documenting purposes and readability */

The final result: The same technique for the box and the link button within

I called this technique “Sliding Doors Squared”, because it is basically an enhanced version of the Sliding Doors technique. Although this technique is great and recommended for two rounded corners with a flexible width or four rounded corners with a fixed width, it cannot be used for completely flexible rounded corners. The “Sliding Doors Squared” technique uses the Sliding Doors technique not only horizontally, but also vertically and therefore fills this gap.

Despite all its advantages, there are some disadvantages:

• the background image has to be rather large (the maximum width and height of the container are defined by the width and height of the background image)
• CSS sprites cannot be used for hover effects (at least not before CSS3), so there will be two requests and a flicker at first
• the corners must not be transparent

As yet I have tested this technique in IE 6, IE 7, Firefox 3, Opera 9 and Chrome and it behaves very well so far without any differences or even hacks (no, not even for IE 6!).

For just two rounded corners or simple four rounded corners with a fixed width this might be overkill. But as soon as you need more flexibility or need an easy way to use drop shadows, fancy borders, gradients or link states, this is the ultimate technique to use.

PS: After I finished the code I took a look at the comments for the original article and realised that the first two steps were already solved in there. That could have saved me about 30 minutes, but at least playing with the code got me going further.