
This post will clarify all those matters. They are all matters of which you should be clarified.
But before I explain all those things in the greatest of all detail, I should warn you of a few things:

This post will clarify all those matters. They are all matters of which you should be clarified.
But before I explain all those things in the greatest of all detail, I should warn you of a few things:

These looked like a cool and simple thing to reproduce, so I gave it a shot and came up with something that I think works pretty nicely.
It wasn’t as simple as I thought, and I don’t think my code is the greatest, so I’m open to suggestions. I think this could form the basis for a jQuery plugin but I’ve never created a jQuery plugin so holding I’m off on that for now.

As fallible humans we tend to lean towards making excuses, blaming others, or trying to justify our mistakes or shortcomings. This is why you’ll often read comments from people discussing CSS and web standards, and they’ll say “I don’t use Internet Explorer; I use a standards-compliant browser”. Well, no you don’t. Nobody does.

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.

I’m not going to go through the basics of CSS attribute selectors and their syntax. There are some pretty good resources explaining them, which I’ll link to at the bottom of this post. So if you don’t have at least some grasp of what this CSS feature is all about, please check those out first.
This article will go a little further and focus on some interesting facts and bugs surrounding attribute selectors that you may not have known.

I recognize that not everyone can afford to pay thousands of dollars to hire a designer and/or programmer to create a website for them. Squarespace offers quite a flexible service for website noobs and at a pretty reasonable monthly rate.
But I couldn’t help but laugh when I read the following paragraph on a page describing their services as offering total creative control:

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.

But generally, in the web design/dev blogging niche we tend to fall into the trap of following trends even in our use of words (especially in headlines and book titles). This even occurs on the better sites, not only on the “list-based” ones.
Here are some terms that I think have been overused and that we could probably eventually do without:

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.

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.)