Most good developers by now accept the fact that pixel-perfect cross-browser CSS is not only unnecessary, but also totally impossible.

Of course, when we speak of the challenge of “cross-browser” CSS, we’re really saying “How can I make this work in Internet Explorer versions 6-8?” — because those are really the most problematic browsers.

Although I’ve written before about cross-browser CSS, and I still stand by just about every word in that article, I thought I’d reiterate my feelings on this subject by providing what I feel is the best workflow for getting your CSS to be as efficient, hack-free, and maintainable as possible while providing as similar an experience in all supported browsers.

You might remember about a year or so ago, there was some discussion about the potential privacy issues caused by the CSS :visited pseudo-class. In a nutshell, it was discovered that this pseudo-class along with some scripting, could be used by websites to “sniff” your web browsing history.

You can read more about the problem and subsequent solution here and here.

It seems now that most of the latest versions of all browsers have taken measures to combat this issue. Fortunately, you can still style text links using the :visited pseudo-class. This is a good thing, and I hope we always have that ability. Visited links are a staple of the web, and they should remain.

The improvements that have been added to HTML5 and how markup is evolving are great for the future of the web.

But I can’t help but feel frustrated that while we’ve come so far in certain areas, that we’re still a long way from being where we really want to be. One of those problematic areas is HTML5 video.

Why it’s taken so long to have a universal way to embed video natively in the browser without the need for a third-party plugin is beyond me. But it’s very difficult to get excited about something that is realistically not very practical or real-world ready.

I’m going to discuss here why I think HTML5 video is a great concept in principle, but a complete disaster in most practical usage.

Thanks to yesterday’s article on Smashing Magazine wherein I covered the use of !important in CSS, my eyes were opened to a small but significant terminology discrepancy.

The article used the phrase “the !important CSS declaration” in reference to the word “important” that appears with a preceding exclamation point at the end of a line of CSS. That’s not the correct terminology, and this was mentioned in the comments by Brad Czerniak.

I subsequently corrected the wording in the article, and even requested that Smashing Magazine change the title to reflect this improved understanding (which they did early this morning shortly before I published this article).

This reminded me that we should be consistent in the use of our terms with regards to CSS. So here’s a quick little list of common CSS terms, and what they represent in CSS code. Much of this is pretty easy stuff for most experienced developers, but some is not used as often colloquially or in writing, so a refresher could help clear up some inconsistencies.

After I created a couple of handy charts that give details on CSS3 property and selector support in the upcoming IE9, I thought to myself: “This is interesting to read, but isn’t very practical.”

I also know that many visits to my site occur via Google searches for stuff like “cross-browser CSS” and similar phrases. So I decided to put together a comprehensive list of CSS properties that are supported in all browsers.

The list is divided into two sections: (1) Properties that are supported by all in-use browsers, with no bugs; and (2) properties that are supported by all in-use browsers, with some bugs in certain browsers.

In a previous article I pointed out an interesting little trick that was made popular by Paul Irish, and has been added as part of his recently-launched HTML5 Boilerplate.

I love that boilerplate, and I wish I could say I understand everything in it. Paul’s a front-end genius and all developers should pay close attention to what he’s been doing lately.

But I have to say that I strongly disagree with Paul’s inclusion of that conditional comments tip in the Boilerplate, because it does not encourage cross-browser, maintainable CSS, but instead encourages CSS developers to consider Internet Explorer development as an afterthought.

Before I explain my specific reasons for wanting that technique removed from the Boilerplate, I’ll first discuss what exactly I’m talking about.

I know this has probably been discussed before, but I’m not sure if it’s been covered in a single post, and I’m curious to hear what people have to say.

What do you think is the best way to group or organize your CSS properities? The way I see it, there are basically three ways to do it, each of which I briefly describe below.

(Be sure to comment if you have a preference for any particular property ordering method, and your reasons for it.)

Last week I posted a couple of charts that demonstrated how well the new IE9 Beta supports HTML5 features. The first chart listed all the new HTML5 semantic elements (<section>, <nav>, <article>, etc.) and I had originally placed a red “X” next to most of those elements.

Thanks to a comment from Richard Kimber, I later changed the red Xs to yellow checkmarks. It was my assumption that since IE9 does not list those elements as strictly “supported” on its “new features in IE9″ pages, then that means we still need to use the HTML5 shiv script. Of course, if I had been paying attention, I would have noticed that the script is included using conditional comments that target every version of IE below IE9.

The reason for this is that while IE9 does not technically include the new semantic elements in its list of supported tags, it does have the ability to allow those elements to be styled.