In most cases, when you place an element on the page in your markup, if you don’t specify any special styles, it will occupy exactly the same space that it appears to occupy visually.

In other words, if you place a box sized at 200px by 200px on your page, anything you place after it in the source order, with no further styles added, will occupy the space below or beside the green box, outside of those set boundaries.

But not everything on an HTML page occupies space that is honored by other elements. I thought it would be interesting to list and describe all the things in CSS that don’t occupy this kind of physical space in an HTML document.

When I look at new modules in the CSS spec, it makes me feel like singing the chorus from a popular Radiohead song from the ’90s: “But I’m a creep. I’m a weirdo. I don’t belong here.”

If web standards could talk, I think a lot of them would be humming that regularly.

In March I wrote about some of my least favourite parts of CSS. Admittedly, that was a pretty negative post, and I’ve even slightly changed my opinion of a few of those things, thanks to the comments.

But I like CSS a lot. So as a follow-up, I thought it would only be fair to list some of the things in CSS that I think work very well and thus are valuable to know and use often.

As many of us have learned, vendor prefixes are a pain in the butt to maintain, and it’s great that CSS preprocessors and client-side scripts are available to help in this regard.

Although I’ve recommended that the standard property be listed after the vendor-specific lines, for “future-proofing” the code, I’m starting to think that might be bad advice in some circumstances.

Now that the numbers for IE6 and IE7 usage are diminishing rapidly, more and more development teams are starting to weed out support for those older browsers.

Most readers will probably have removed IE6 completely from the equation and soon IE7 will follow. Despite IE8 still having the highest share of any single browser version, the demise of IE6/7 now allows us to be more creative with CSS selectors.

This post will provide a comprehensive review of support for CSS3 selectors in the most troublesome browsers (guess which ones?). Each selector links to the appropriate location in the CSS3 spec.

A List Apart’s Issue #344 went live yesterday with a focus on the recent vendor prefix drama. I didn’t get a chance yet to read the entire Meyer/Tantek interview, but I did read Lea Verou’s piece.

First of all, congratulations to Lea for getting published in ALA. She’s certainly one of the most talented web developers I know, and deserves to be featured in such a context. I hope Zeldman and company continue to use new and fresh authors like her.

So what’s the point of my post here? And what’s the deal with the hyperbolic title that resembles Lea’s? Well, in many ways, this post is a response to what Lea wrote in her article. But this is not to say that what I’m going to write necessarily contradicts or opposes what she’s written. For the record, I agree with the spirit and forward-thinking approach in her post.

About a year and a half ago, I wrote about CSS3′s word-wrap property. The angle of the article was the fact that it was a feature that was new in CSS3 that didn’t exist in CSS2.1 and it worked in just about every browser, including old IE.

Well, now that’s all changed, which I discovered while researching additions to my CSS3 Click Chart. The word-wrap property has been removed from the CSS3 spec and other related properties have been added.

Over the past month or so I’ve been slowly working on a redesign and revamp of my CSS3 Click Chart.

A whole slew of things have changed. Here’s a summary.

Currently, there are still a number of CSS3 properties that will not work unless you include all the various vendor prefixes. And that number is growing now that IE10 has added support for a bunch of new properties and features.

Let’s look at a simple example of some CSS3 keyframe animation code that includes other prefixed CSS3 properties, and consider a problem that might arise when trying to future-proof the animation code.

As of this writing, the full code required to cover all current browser support, plus future support for the standard syntax, would look something like this: