Link Details

The problem is, IDs are a less expensive selector in Javascript & CSS because IDs are as specific as you can get. They best suited for side-wide structural elements like content, sidebars & navigation.

What is cheap at the beginning gets really expensive with time. Believe me, their specification is what makes them expensive in the long run.

Obviously this person has never coded or maintained even a moderately sized site. Sorry but just because your website gets 150 hits a month doesn't mean you can speak with authority on Javascript, HTML or CSS.

If you all wish to make your lives harder then I won't stop you. And if the only argument you can throw is a personal insult, then that only describes you. My post is my opinion and I'm going to stick to it. I'm not holding a gun against your head and telling you I know everything and you must do as I say.

I'm just saying flexibility is the crucial element in todays design. And IDs are certainly not a friendly part of it, in the long run. Don't be quick in judgment and short-sighted, please.

I've been saying this for years, as well. Other than referencing the element directly and easily in Javascript, ids should be abandoned for classes.

I only use ids for layout-regions and targets. Just like any other sane person.

I completely agree... I've always stuck to: class = css, id = dom segregation ... though I will deviate from time to time if they would end up sharing the same string, like > but even that's extremely rare for me...

Good to know I'm not the only one with this ideology :-)

Whoops, it stripped the html... let me try another way:
[div id="something1" class="something1"] --> [div id="something1"]

But I only do this when the div it's self will be manipulated via the DOM

Disagree.
Think of #id and .class as of user and group.
One can use #id for identification and .class for grouped parameters.
Anyway, I commented longer on the blog