Hi,
From About
Don’t use IDs in selectors
IDs shouldn’t be used in selectors because these rules are too tightly coupled with the HTML and have no possibility of reuse. It’s much preferred to use classes in selectors and then apply a class to an element in the page.
I’m doing it a lot. How do you avoid having too many ids as selectors? Replace them by classes?
Regards,
-jj. 
I don’t really understand that point. There are times when it is best to use a class, and there are times when it is best to use an ID.
Lint is cute for catching things like typo’s – I’d rank it better than the W3C validation service in that regard… but…
A LOT of the stuff it kvetches about as warnings is just plain nonsense… their stance on ID’s in selectors for example is just arbitrary nonsense.
Or even simple messages it gives me – for example:
input {
-webkit-appearance: none;
}
returns:
The property -moz-appearance is compatible with -webkit-appearance and should be included as well.
Uhm, don’t need to, shouldn’t ever need to – mozilla actually lets me style inputs how I want them… kinda. Only webkit is a total nudnik in that department. (I swear, I’m starting to hate webkit more than I do gecko)
But yeah, “don’t use id’s in selectors”?!? That’s 100% unadulterated NONSENSE. Especially if you need to resolve a specificity issue, or SHOCK use the ID to link to, or SHOCK have it on an input for “for” to point at so why WASTE AN EXTRA CLASS on something that has a unique identifier…
100% unadulterated manure, and whoever came up with that as part of LINT should be ashamed.
Another one that’s total nonsense is the “headings should not be qualified” – for example:
.blogSummaries .blogBox h3 {
throws a warning… What, you can’t have Headings in different subsections receiving different style? That’s just… I lack the words in polite company. on just how idiotic that is.
The text for it:
Heading elements (h1-h6) should be defined as top-level styles and not scoped to particular areas of the page. For example, this is an example of an overqualified heading:
.foo h1 {
font-size: 110%;
}
Heading elements should have a consistent appearance across a site.
Makes it sound like they are advocating presentational markup… since if you are choosing your heading tag based on appearance, you aren’t choosing them right. Much less block level prefixes are often used for techniques like image replacement so you don’t have to put a class on the h2, p or anything else inside the parent container – as such they might have the same “appearance” by using different images for the text… So that’s just bull.
Besides, if I have H2 in the main content column and h2 in the sidebar (or for you HTML 5 nutters, “aside”), what’s wrong with making them smaller they aren’t the primary content area and lose the structural order meaning when moved up next to it? STRUCTURALLY they’re H2, that has NOTHING to do with APPEARANCE.
Shame such a useful tool you have to disable about half the checkboxes before using it. Wish to hell it remembered which checkboxes you disable between visits… or even refreshes.
Hello,
CSSLint is nice for many things, but I agree that it is biased by a subjective approach, which, unfortunately, isn’t stated clearly. I would have liked it better to have authors letting us know more clearly that they implementing their own, personal philosophy rather than giving the impression that the warnings their app issue are God’s truth.
Nice app, though.
People using “aside” as a synonym of “sidebar” are badly mistaking. What’s inside <aside> doesn’t even have to stand on the side (left or right) of the content it relates to. <aside> can vertically flow under the content it “comments”. Fine.
The mark-up for a sidebar would be far better achieved using <div role=“complementary”>, which avoids the bloat of a new, confusing tag for beginners (and sometimes gurus).
cssLint is in fact tailored to the “rules” set by OOCSS (Object-oriented CSS)
Well that explains a lot – since that steaming pile basically defeats the entire point of HTML, CSS and separation of presentation from content – as it basically advocates presentational markup.
I find that kind of odd – a lot of LINT’s notions of right and wrong run ENTIRELY contrary to how OOCSS works… though it does seem to be saying “slap extra classes on EVERYTHING” which is definitely up OOCSS’ alley.
I just used CSS Lint for the first time and ran across this as well. It really stumped me, but I experimented with it a bit to see if there was anything to be gained from not using ids in selectors.
What I ran across was being stumped how to name the classes that would replace the ID selectors. Here’s a simple example:
h3 { font-size:20px; margin-bottom:30px; font-family:‘PTSansBold’; color:#2b3690; }
Content h3 { font-family:arial, sans-serif; font-weight:bold; }
So if I were to give the second declaration a class name instead of an ID, what would I name it? The only names that come to mind are horrible old FrontPage ones, like “.arialh3” That just feels wrong.
If I were using the set of styles in the declaration in the same sort of situation throughout the site, like in all contact asides, I could name the class “contact”. But then I would just end up with this:
<aside id="contact class=“contact”>
Well, that’s silly. I’m not converted. I’m still going to use IDs in selectors.
One thing lingers in my mind. Usually I build a site soup to nuts myself, but I worked on one project this year where I did front end only. When the back end dev got my code, he asked me to rewrite the styles not using type or id selectors. His poitn was valid - it would be much simpler for him to see descriptive class names in the code rather than not really even knowing id styles are applied to an element. <h3 class=“boldarial”> is more meaningful to him than just <h3>. Also, if he wanted to apply styles to a new element, he would be able to just see what the class is rather than having to dig through the stylesheet trying to find the relevant declaration.
I got his point, and would have liked to find a better mutual solution, but doing almost all of the styling through classes just went against everything I’ve learned about CSS.
Note to self: ingore CSS Lint.
IDs shouldn’t be used in selectors because these rules are too tightly coupled with the HTML and have no possibility of reuse. It’s much preferred to use classes in selectors and then apply a class to an element in the page.
That would almost, but not really, make sense if you used different CSS for each page in a site but you don’t. If you use a class or selector once per page it has the same effect.
Marked as disregard.
There should be a reason that the heading has those rules applied and it must mean that it identifies a section of the page that is different from others so you would use that to guide your choice of names.
For example if its a main content sub section then simply h3.subcontent would suffice although you could of course tailor it to be more specific (but never presentational). However forsaking ids you still could have styled it via the parents class e.g. .content h3.
The benefit of saying .content h3 rather than Content h3 is that you can over-rule the former with a simple class (h3.newclass) whereas the latter would need to be Content h3.newclass.
I use ids for structural elements of the page (header,footer,main,sidebar,nav etc…) and classes for the minor and re-usable elements. You need to be careful when styling via context using ids as you apply more weight and thus need to apply the same or greater weight to over-rule.
e.g.
Content h3{}
h3.newclass{}
In the above the first rule wins out unless you also qualify the last rule with the id also.
While in the following example the last rule wins out (assuming source order isn’t changed).
.content h3{}
h3.newclass{}
In the end it’s of little consequence if you know what you are doing and to abandon ids altogether is just plain silly.