Markup and Style

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.

Over the years I’ve continued to refine my understanding of front-end development terms, especially CSS terms and definitions.

I’m constantly reminded that as developers we should be consistent in the use of our terms. This post will attempt to list all 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.