For those unfamiliar with jQuery Masonry, what it, essentially, does is mimic a vertical float, not just the regular horizontal kind. In fact, I used it for the homepage of my blog (where the different posts are displayed).

So, what’s the trouble with CSS? It’s quite simple: there is no CSS model that takes into account vertical alignment. Period. I swear I tried everything. From floats, to positions, displaying inline, run-in, you name it, I tried it. But there was this midget in my head telling me that there must be a solution. And, wouldn’t you know it, BAM, two days ago, while eating an omelet, of all things, it struck me.

The all mighty columns

The solution is so simple that it gave me a brain freeze: CSS columns. Granted, their purpose is to display text in columns like a newspaper, but their display mode is exactly what’s needed to recreate the Masonry effect. But let’s get down to the code. What do you need, you say?

A container and some children

<div>
<a href="#">Whatever stuff you want to put in here. Images, text, movies, what have you. No, really, anything!</a>
...and so on and so forth ad nauseum.
</div>


The CSS magic

div{
-moz-column-count: 3;
-moz-column-gap: 10px;
-webkit-column-count: 3;
-webkit-column-gap: 10px;
column-count: 3;
column-gap: 10px;
width: 480px; }

div a{
display: inline-block; /* Display inline-block, and absolutely NO FLOATS! */
margin-bottom: 20px;
width: 100%; }


An interesting fact: the width of the elements within the columned container is not relative to the width of the parent, but the width of the column. In the case of the example above width: 100% actually translates to 150px, not 480px (the width of the parent).

Fallbacks and browser compatibility

Of course, our friends at Microsoft have taken good care to not provide support for CSS columns. Not even in IE9! In this case, I recommend slapping in David’s awesome plugin like so:

<!--[if lte IE 9]>
<script type="text/javascript" src="js/jquery.masonry.min.js"></script>
<![endif]-->

In Microsoft’s defense, for what it’s worth, this does work (well, even!) in the IE10 Platform Preview. Hopefully they’ll leave support for columns in the final version, which could be released as early as next year.

I’m guessing there’s no point in mentioning that this works (brilliantly) in Gecko and Webkit browsers (Mozilla, Chrome, Safari). Opera does weird things that I don’t quite understand yet, but does an acceptable job of rendering columns (it just has trouble with the gaps and all).

This is usually where you’d find a link to a demo page. This time, however, I direct you to the homepage of this site. Yes, I used it live. I have that much confidence in this. Enjoy, kids!

A bit of an introduction

The W3C specifies that the initial display value of all elements is inline. Some of you may raise a brow in disbelief, and with good reason. What they didn’t specify is that the display property is sensitive to other properties. That is to say that some elements automatically change their default display value according to other properties they might have applied to them.

Practical example: divs and ems. By default, they both act as inline elements. Add width/height or float to them and you start to see a difference. While the ems keep being displayed as inline elements, the divs are rendered as block elements, which is what we’re used to seeing.

Because of this slightly esoteric behavior of the display property, I find it easier to think of divs and forms, etc. as block level elements, while all the rest as inline. Most of the time, the default values are sufficient and adequate but there are times when maintaining semantic code while having a specific element behavior requires a bit of display tinkering.

So, what’s the big deal?

Instead of writing a lengthy and, otherwise, boring post about how this value does this and that value does that, I went a bit further and made a demo page showcasing all the 17 possible display values in a retro kind of Dharma Initiative interface. Yeah, yeah, Lost is over, boo-hoo.

So, clicky on the demo button and have yourself a merry time (best viewed with Firefox 3.6). And don’t forget to get back here and leave a comment!

See the demo

Hopefully, you had a good time playing around with the virtual display keyboard and, who knows, maybe even learned a thing or two about the mother of all structural CSS properties – display.

Web design is growing ever closely to the rank of more traditional, elite professions. Yet, unlike traditional professions, web design is not subject to a standard practice model. We each build websites according to what we think is the best, or sometimes the fastest, approach.

Perhaps you read some books when you started out with web design that explained certain methods of the building process, I know I have. And, perhaps, like me, you too, disappointingly, found that most of these books derive solutions that are either contrived, redundant, illogical or do not withstand the test of time.
In this post, I’ll try to express what I believe to be a healthy candidate for the title of Website Building Standard Method. I call it the Solar Method (of building websites).

As the name implies, my Solar Method is derived from solar systems, more precisely, from the process of forming a solar system. Daunting as it may seem, it’s time for a little bit of cosmology.

The Cosmological Background

For objective reasons I shall use our own solar system as a basis for my theory. This in no way affects the methodology of the proposed theory. Also note that this is a very brief description of the history of our solar system and is meant to provide insight into the background of the proposed method.

Our solar system began its life as a piece of a giant molecular cloud, known as a pre-solar nebula. Upon gravitational collapse, this fragment of the nebula condensed into a proto-star surrounded by debris, known as a solar nebula.
It is from this solar nebula that planets began forming, through the process of accretion. Further down the timeline, through collisions and attractions, the solar system stabilized into the structure we see today.
Snoozing already? Don’t worry, it gets better.

Identifying Parallels

At the center of any website lies the all mighty HTML. It’s the main ingredient we feed browsers and it powers the better part of the web. HTML is the single most essential component of websites. Without it, most other web technologies are useless. In other words HTML is our Sun. And technologies such as CSS, Javascript, PHP, etc. are planets revolving around our HTML Sun.

While there are well founded reasons to claim that technologies such as Java or Flash are equal in importance to HTML, this method is aimed at web designers, not Java or Flash designers, so I’ll refrain from pursuing this line of investigation.

The Solar Method

Terms such as progressive enhancement, a clear focus on accessibility and semantics as well as a clear separation of markup, styling and interaction are driving factors in today’s web environment. These factors are also the driving factors behind this proposed method.

Q: what is the most simple solar system? A: a sun.

Delivering content to the lowest technological denominator is the starting point of this method. We find this lowest denominator by eliminating all non-essential web technologies: a browser that has disabled CSS, Javascript, Flash and Java, reading a website set on a server that does not allow for anything other than simple HTML delivery. It is in this harsh environment that we must first place ourselves.

This method tries to provide the necessary mindset through which we can build websites that manage to overcome the many obstacles of this desert environment and yet achieve our goal of delivering meaningful and complete content.

So let’s look at a very clear way of determining the steps one should undergo in building websites with the Solar Method:

1. HTML
   First, create the HTML content without any images or other media. This is, by far, the most crucial point in developing a website. Clean, semantic & meaningful HTML means your job later on will not only be easier, but also more satisfying.
2. Media & CSS
   Add any necessary media (images, sound, animation etc.) to the HTML code and also CSS styling to match the design.
3. Javascript
   Add Javascript interaction if needed.
4. Programming
   Add any necessary programming (PHP, Ruby, ASP etc.) code.
5. Flash
   Add any necessary Flash code.

At each step remember to make the website functional and meaningful as if no other technology would be added.

At this point you might be saying to yourself: “but this isn’t that complicated!“; and you’re right, it is not. This method is not meant to be complicated, it is meant to guide you in a logical way to building websites. Adding orbiting technologies around the underlying HTML base like planets around the Sun is, or should be, a natural impulse driven by reason and the aforementioned key factors in modern web design: progressive enhancement, accessibility, semantics and separation.

My explanation for the Solar Method may seem overly complicated, considering its easy to follow guidelines. The lengthy preamble was a conscious decision, of course, and it is meant to underline the importance of our work as web designers.

Our craft has grown and so should we, as it’s practitioners, beyond the proverbial “code monkey” and realize that our work is of great importance and we are fortunate to be able to call ourselves the builders of the Internet.

The Starter Pack, as I call it, is a bit different than a template. I built it with one guiding principle: scalability. As a result, you can use this to get started on your portfolio page or the next Facebook.

Of course, the coding part is all HTML5, cross-browser, of course, but I’ve also gone and included a basic Photoshop template to get you started on designing the page. Just to lure you in to it, here’s a list of a few major features of the pack:

• Cross browser (IE6 is supported as well)
• Valid HTML5 (that’s right; valid, baby!)
• Tablet/Netbook ready (via CSS media queries)
• jQuery (from the Google CDN)
• Cufón ready @font-face ready (Lobster & Raleway fonts included from FontSquirel )
• Some structural reusable classes

I’ve set up a separate project page (built with this Starter Pack itself) to showcase some of the features in the pack, so just click the link below (or the screenshot of the project page), read a bit about it and if you like it, I’d really appreciate a comment here.

Download the Starter Pack

UPDATE

As some of you have pointed out, I was in error by not pushing for @font-face. Thus, version 2.0 of the pack is up and running. Just click the download link and you’ll be up and running! Thanks everyone for the awesome support and huge help in making this a pretty cool little pack.

If you feel I’ve missed something in this pack, or that, perhaps, some areas can be improved, please, speak your mind in the comments area. I promise I won’t ignore you…much (just kidding!).

Right off the bat, let me say that I do not proclaim (not anymore) that there’s a right way or a wrong way to format your CSS. I’ve come to the (hopefully mature) conclusion that the way one formats styles should be based on the type of project at hand. And this the basis of this post.

Gone are the days of small, static websites that take about a day to code and have less than 500 lines of CSS in them. Nowadays, we find ourselves working with blogs, CMSs, frameworks, web applications, web shops and generally huge friggin projects. The CSS we write today is almost never under 1000 lines and when you’re dealing with that much code, you need to be able to maintain it easily.

Most web designers have their own, preferred, way of writing. And they stick to it no matter what. I used to do that myself. But the more diverse your projects are, the more you’ll start to notice the pitfalls of your preferred technique. And then you might realize that your own, personal, style of writing stylesheets isn’t really that important, when it hinders to the maintainability of the project.

I think it goes without saying that in this post I will completely avoid the possibility of “inline” and “in head” styles. These two options aren’t really an option because they both mean polluting your markup, so I’ll politely tell them to get the fudge out of the equation. If any of you have a problem with that, take it down to the comments section, where complaints are more than welcomed.

I’ve got a system here, so, we’ll start with the big stuff (file management) and end with the really small stuff (the curly bracket – quite poetically).

Single file vs multiple files

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>CSS3 Vignette</title>
<link rel="stylesheet" href="css/style.css" type="text/css" media="screen" />
</head>
<body>
...
</body>
</html>

The single file approach, like the code above, is most suitable for small projects. I’d say somewhere under 1500 lines of CSS is the limit, at least for me. As long as you keep your styles organized, this approach should work out ok.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>CSS3 Vignette</title>
<link rel="stylesheet" href="css/reset.css" type="text/css" media="screen" />
<link rel="stylesheet" href="css/structure.css" type="text/css" media="screen" />
<link rel="stylesheet" href="css/type.css" type="text/css" media="screen" />
<link rel="stylesheet" href="css/colors.css" type="text/css" media="screen" />
</head>
<body>
...
</body>
</html>

The multiple file approach is a good choice when working on larger, more complex projects. It’s also a good idea to use this approach when you have a project that will have a lot of updates. Being organized like this and keeping different sections separate can make your job a lot easier.

@import url('css/reset.css');
@import url('css/structure.css');
@import url('css/colors.css');
@import url('css/typography.css');

The direct approach to multiple stylesheets isn’t the only option. You can use the @import rule to put together your multiple CSS files within a single, main stylesheet.
The downside with using multiple stylesheets is that they add to the number of HTTP requests made for the page, which slows down your page load times a bit. I wouldn’t worry too much about it though. Most of the time you can get away with it and still have good performance on your pages. Compared with database queries, javascript calls or even image load, the downtime caused by large CSS files is, mostly, insignificant.
If you’re totally anal-retentive about page load times, however, you can use a stylesheet minifier to decrease the size of your CSS files. More often than not, you can slim them down to at least 60% of their original size.

To indent or not to indent


p{ font: normal normal 1.2em Arial, Verdana, Tahoma, sans-serif; }
p span{ color: tan; }


Not indenting your CSS selectors at all is usually a bad idea and I really can’t see one upside to it. So don’t be a naughty Nancy and press that Tab key every now and then.

#block{ float: left; margin: 0 20px 0 0; width: 200px; }
p{ font: normal normal 1.2em Arial, Verdana, Tahoma, sans-serif; }
p span{ color: tan; }
p em{ font-variant: small-caps; }

You can indent in chunks. That is to say, sections that are related directly are indented (like the span and em as children of the p tag), but unrelated ones stay unindented (like the block id and p tag). This could work, as you keep your file size small, while still having the legibility and organization specific to the indented style. It’s a sort of hybrid option.

body{ margin:0; padding:0 }
#wrap{ position: relative; margin: 0 auto; width: 900px; }
#left{ float: left; width: 66%; }
#left .inner{ padding: 20px; }

Fully indented text has the best legibility and is, to many people, myself included, the easiest way to maintain your stylesheets. The downside is that styles get big pretty fast so it’s a good idea to combine this style of writing with multiple file stylesheets.

Single line vs multiple lines

#left{ float: left; width: 66%; }
#right{ float: right;
width: 33%;
border: 1px solid #333;
background: #cecece;
font: normal normal 1.4em Arial, Verdana, Tahoma, sans-serif; }

I found that many of the programmers I’ve worked with prefer single line CSS. | I found that many fellow web designers prefer the multiple line approach.

Single line CSS attributes are a very concise way of writing your styles, but they have the disadvantage of becoming harder to read as the attributes add up. The id left in the example above is an example of an easy to read and concise set of attributes, whereas the id right, with it’s many attributes is a huge pain to figure out, especially if you’re looking at the code a few months after it was written.
#left{
float: left;
width: 66%; }
#right{
float: right;
width: 33%;
border: 1px solid #333;
background: #cecece;
font: normal normal 1.4em Arial, Verdana, Tahoma, sans-serif; }

The multiple line approach has it’s appeals: it’s easy to read, to edit and, subsequently, easy to maintain. The downside, of course, is the increased length of your stylesheets.

To alphabetize or not to ahlaiebtpze

#right{
background: #cecece; border: 1px solid #333;
float: right;
font: normal normal 1.4em Arial, Verdana, Tahoma, sans-serif;
width: 33%; }

I am a huge supporter of CSS alphabetization, so I may come off a bit subjective here, but I really do think it’s one of the best ways to format your stylesheets, especially when using the single line approach. That way, you can overcome the downside of many attributes becoming hard to read through, like in the example above.

#right{
float: right; background: #cecece; border: 1px solid #333; width: 33%; font: normal normal 1.4em Arial, Verdana, Tahoma, sans-serif; }

Alphabetizing takes time to get used to. It’s not the most intuitive and natural way of writing and it’s main downside is extra time spent on the CSS file. But, if you persist in this practice, you can develop your writing skills to such extent that it becomes natural to alphabetize.

The curliest of brackets

#left{
float: left;
width: 66%; }
#left{
float: left;
width: 66%;
}
#left{
float: left;
width: 66%;
}

Should the closed curly bracket at the end of each selector be next to the last property, or on the next line? And should it be indented or not? Personally, I put the bracket next to the last property, to save some space. But that’s just me, this one’s totally open to discussion.

A few examples


body{margin:0;padding:0}
#wrap{width:900px;position:absolute}
#left{width:66%;float:left}
#right{width:33%; float:right}
.inner{padding:20px}

I like to call this the programmer-friendly approach (though I’m sure this doesn’t apply to all programmers). Single line, chunky indenting, no alphabetization, no extra spaces, curly brackets at the end of the line. And it looks really, really crammed.

body{
margin             : 0;
padding            : 0;
}
#wrap{
position        : absolute;
width           : 900px;
}
#left{
float           : left;
width           : 66%;
}
#right{
float           : right;
width           : 33%;
}
.inner{
padding      : 20px;
}

I call this one the over-achiever approach. Multiple lines, full indenting throughout, alphabetized, curly bracket on a new line and indented and bonus points for super indenting the properties to be one above the other. And it is way to spaced out.

Whichever way you decide to approach your CSS stylesheet “writing skills”, be aware of the pitfalls of each one and settle on a way that fits your project’s needs, not your personal preference.

Of course, there are those of you just looking for the quick fix so, without further ado, here’s the link to the demo page:

DEMO

So, what’s this puppy about?

For those of you who don’t know, a vignette effect is a discoloration on the edges of an image. This effect usually appears in photography and it can be either accidental or intentional. It can also be either light or dark, depending on the situation. Like this:

Good, now that that’s out of the way, let’s continue to the actual tutorial.

We’ll be dividing the vignette into four div elements as shown in the diagram above.

Using absolute positioning we’ll be telling the four divs to sit in their respective corners and using a combination of CSS Gradients and RGBA we’ll fade the discoloration towards the center.

One should be careful not to overdo it with the vignette. A black vignette on a white background will look really cheap, mostly due to universal browser dithering problems, so a subtle approach is key to a successful effect.

We’ll also set the height/width of the divs using percentages. This way we’ll get a proportional vignette according to the user’s screen size. The trick with this technique is using just the right amount of height/width. Too much, and the content will become unselectable on account of the divs having a high z-index value. Too little and the effect is barely noticeable. I did a few experiments and the widest range of usable heights/widths is somewhere around 12%-17%. In this tutorial I used 15% which seems to work fine for resolutions from 1024×768 up to 1920×1080.

The HTML

The HTML part is really, really straight forward – just four empty divs, in no particular order:

<div id="top"></div>
<div id="right"></div>
<div id="bottom"></div>
<div id="left"></div>

The CSS

Here where the magic really happens:

/* First we set the four elements of our vignette
to be on top no matter what and set their initial
width and height which we'll overwrite in the next declarations.
*/
#top, #bottom, #left, #right{
height: 100%;
position: absolute;
z-index: 999;
width: 100%; }


/* Overwriting the default 100% */
#top, #bottom{
height: 15%; }


#left, #right{
width: 15%; }


/* We set the gradient with CSS3 from a solid gray to
a 100% transparent color which should be the same as
the body background color, to have a nice, clean falloff.
And we're also setting the position of the vignette elements.
*/
#top{
background-image: -moz-linear-gradient(100% 100% 90deg, rgba(255, 255, 255, 0), #e1e1e1 );
background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#e1e1e1), to(rgba(255, 255, 255, 0)));
top: 0; }


#bottom{
background-image: -moz-linear-gradient(100% 100% 90deg, #e1e1e1, rgba(255, 255, 255, 0) );
background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from(rgba(255, 255, 255, 0)), to(#e1e1e1));
bottom: 0; }


#left{
background-image: -moz-linear-gradient(100% 100% 180deg, rgba(255, 255, 255, 0), #e1e1e1 );
background-image: -webkit-gradient(linear, left center, right center, from(#e1e1e1), to(rgba(255, 255, 255, 0)));
left: 0; }


#right{
background-image: -moz-linear-gradient(100% 100% 180deg, #e1e1e1, rgba(255, 255, 255, 0) );
background-image: -webkit-gradient(linear, right center, left center, from(#e1e1e1), to(rgba(255, 255, 255, 0)));
right: 0; }

The code may look a bit stuffy at first but it’s quite easy to maintain as only the hex values of the gradient and perhaps the height/width values need adjustment.

Browser compatibility

All in all I’d say it’s a pretty useful and usable technique, but if you must extend it’s compatibility to Opera and IE7 and above you could use fixed heights/widths and a repeating transparent PNG image. A lot less cool, but you get the point.

I hope you enjoyed this little technique and if you ever get the chance to use it somewhere, I’d appreciate dropping a line and showing off.

I’m not trying to point fingers here, but one must admit that while there is a growing interest and awareness of HTML5 and CSS3, most agencies and freelancers are just as discrete about them as before.

On the other hand, agencies and freelancers haven’t really been pioneers for obvious reasons: they work for clients. And clients don’t care about the latest and greatest, they care about revenue and WYSIWYG (most have never heard of graceful degradation/progressive enhancement). It’s all about the Benjamins, baby!

Enter the wonderful world of personal pages. I’m referring to design blogs and designer portfolios mostly. These places have, for some very long time now, been a sandbox for testing, learning and experimenting with technology that’s considered “avantgarde”. Though, one must point out the existence of the HTML5 Gallery Showcase, a place to check out plenty of websites using HTML5.

So, in our sickness, we thought: lLet’s do the redesign for Sickdesigner using HTML5 and CSS3. We did, and so much more.

It was a stroke of luck that around that time we came across a mind-blowing post by the one and only John Resig, creator of jQuery. In case you haven’t come across the article or just didn’t click the link back there, it’s all about a nifty little piece of Javascript goodness called document.createElement which John used to portray how one could create and use the new tags in HTML5.

This tiny piece of code made all the difference in our minds, when realizing the potential and usefulness of document.createElement. Here’s a bit of code from this very website:
<container>
   <header>
      <h1>
         <a class="tooltip" id="logo" href="http://sickdesigner.com/" title="The main ward">
            Sickdesigner - The sickness is spreading
         </a>
      </h1>
   </header>
</container>

At this point you’re probably scratching your head a bit. It’s okay, it’s normal. Most of you will recognize the h1 and a tags. Some of you, more familiar with HTML5, will recognize the header tag. But then, right at the very start we have  a tag called container, which doesn’t really belong anywhere.  That’s because it’s generated with document.createElement.

Well, there’s a very good explanation for this: Semantic tags. We’ve all heard of them and, unless you have tables for layouts, you’re using them.

Semantic tags = “use the right tag for the right place”. If you’ve got a paragraph, use a p tag, if you’ve got a line break, use an hr tag. This also extends to classes and ids: if you’ve got a header div, slap on an id of “header”.

We work in an environment which really thrives on progress. And in such an environment it is the opinion of this sick designer that one must always strive to challenge old paradigms. We challenge the term Semantic tag. We want it to actually mean a semantic tag, a tag that means something, that expresses it’s use.

Still not on our side? Check this out:

<container></container>
<div id="container"></div>

Isn’t the first way of writing the container cleaner, more efficient, more meaningful and easier to maintain?

So what other tags did we decide to include? Let’s see now: wrap, container, header, sidebar, twitter, rss, homepage, posts, article, category, tags, footer, single, comments, author.

HTML is a great language which does employ semantic tags in the sense described above, such as p, em, strong etc. But you’ll notice that they are all tags that relate strictly to content, not structure. For that we’re bestowed upon with divs. Ugly, ugly divs, which mean nothing but “a divider”. Sure, the W3C is trying their best to come up with semantic structural tags in HTML5, like header and nav and footer, and that’s peachy fine. But what they don’t understand is that not all websites are built the same. Not all websites have just these elements.

Pop quiz, kids:

Most blogs display their categories. What’s the appropriate tag for a category? And I mean truly appropriate, not a span. Why not have a category tag?

We’ve only used the newly created tags for structural purposes. It’s not an exercise in “look ma, see what I did?”, but an attempt to bring sense and direction to a part of HTML that lacks proper meaning.

The how to part

Now, enough chatting about this stuff. Let’s say you want to implement this kind of weirdness in your next project. How do you go about it?

First, take a piece of paper and write down all of the tags you’re going to create. This is not rocket surgery(!), but planning ahead is essential.

The Javascript

// Create elements
document.createElement("wrap");
document.createElement("container");
document.createElement("header");
document.createElement("sidebar");
document.createElement("footer");

Quite. Save that with a filename of, say, create-elements.js. Let’s include that in our HTML page.

The HTML

<!DOCTYPE html>
<html>
   <head>
      <title>Truly Semantic Tags</title>
      <link rel="stylesheet" href="style.css" type="text/css" media="screen" />
      <script type="text/javascript" src="create-elements.js"></script>
</head>

I’ve also added the HTML5 Doctype declaration and a stylesheet to the equation. Now, let’s move on to the CSS part of the deal.

And the CSS

wrap, container, header, sidebar, footer{
   display: block; }
By default, these elements have no properties and since their use is structural, a display: block is needed for proper rendering.

And there you have it. Now you’re ready to style away at these newly created elements, without added classes/ids and with meaningful names.

But, alas

Of course, we can’t forget about that wretched “old friend” of ours, Internet Explorer.

If you’re thinking about whether this stuff works on IE6…forget about it. It just withers into a corner and starts crying at the very site of the new tags. And it should. I don’t hear any cries of grief over the inability of Firefox 1.5 to render border-radius, so there will be no tears shed for this relic.

IE7 and 8, however, do seem to comply. There are restrictions, though. It seems that IE likes to create self closing tags, instead of normal ones. But there is hope, yet.

You can use Remy Sharp’s HTML5 shiv. It’s a nice little piece of Javascript, which essentially does exactly what we just did, but using the .replace method and some nice regular expressions. Just download and add your own  elements to the list. Like so:

// For discussion and comments, see: http://remysharp.com/2009/01/07/html5-enabling-script/ (credit to @jdalton for minif)
/*@cc_on'abbr article aside audio canvas container details figcaption figure footer header hgroup mark menu meter nav output progress section sidebar summary time video wrap'.replace(/\w+/g,function(n){document.createElement(n)})@*/

This way you can include IE7 and 8 into your supported browsers list.

So, can you use this in a client’s project? Perhaps. We think it’s feasible enough, although it does take some (little) time getting used to it. And if your next project doesn’t imply supporting IE (one can only dream, right?), then this is definitely something you should try.

This whole idea may seem a bit nutty and perhaps it is. But I like to look at us web folk like doctors. We work in an ever changing, nerve wracking medium and all our professional lives we strive to learn newer, better ways of doing what we do, no matter how ludicrous and unreasonable they may seem ar first glance.