One thing that’s common in development blog posts and documentation is the use of HTML’s
<code> tags to mark up code snippets inline and in large blocks (the latter of which is usually done along with
One of the problems that occurs with styling of
<code> tags, however, is when they’re used inline inside of links (or
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.
It would seem that with the introduction of HTML5’s semantic elements, styling those new elements should be an easier task. But as I’ve started to use HTML5 more, I’ve realized that it takes quite a bit of forethought to create maintainable CSS that targets the new semantic elements in a future-proof way.
In some cases, it could be fairly straightforward, but in others it’s a little disheartening because targeting the new elements actually creates more verbose markup.
Let’s consider a few examples. If you had a page that used the
<header> element to hold the logo, nav, etc, and the
<footer> element to hold the website’s footer, then your CSS would look something like this:
This article was first published on June 1, 2010 and has been updated to include a few extra features and an improved code base.
I’m a huge baseball fan, so earlier this year, just for a fun side project, I recreated the MLB.com Flash content switcher using jQuery and CSS3.
My goal with this project was to try to recreate the switcher without any extraneous images or other non-essential elements that tend to make stuff less maintainable.
My version uses CSS3’s
border-radius, RGBA colors, opacity, and a small use of a gradient, and still looks acceptable in non-supportive browsers (although the jQuery is not as smooth in IE6 & IE7). Be sure to look at the real version on MLB.com for comparison; there are a few small differences, but mine is basically the same.
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.)