I am very much an amateur at CSS. I know the basic rules (I hope), but I'm definitely not a designer or an expert. After running some CSS through the linter, though, and reading the About page, I have a few questions.
First: Why are IDs bad? The About page says:
>> 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 don't quite follow. Isn't the whole point of an ID that it is like a class, but unique? Why exactly would it be better to change all ids to classes with only one member? (I don't even see how that would be different, except for making it less obvious to me that they're unique.) Edit: the context about OOCSS which Jacobr mentions below helps explain this.
Second: Why is it so important that heading styles be declared in exactly one spot. Again, the About page:
>> Heading styles should only be defined once
Heading elements (h1-h6) should have exactly one rule on a site. CSS Lint warns if it finds more than one.
I ran into this because I had one ruleset for h1, h2, h3, etc. to make all the headings use the same font and color, but then I had distinct blocks for settings that I wanted to be different. (Example, I wanted the h1 to be larger and have a different bottom margin from h2 or h3. And so on.) I could easily duplicate things so that each set of rules was in exactly one block, but that would make the stylesheet less DRY.
(Edit - putting my cards on the table, here's the CSS I checked: http://ithaca.arpinum.org/css/screen.css. I definitely don't doubt it could be improved.)
There is nothing wrong with .foo.bar. There are problems with outdated versions of IE, should that stop you?
There is nothing wrong with ID selectors.
There is nothing wrong with having display:inline on the floated element. No harm done, fixes double margin bug in IE6 if you need that.
It is ok to have many rules for heading no matter that CSS Lint says.
It is ok to have width, padding and borders defined. I do that all the time and surprise surprise, result is just as I intended. I am not sure if CSS Lint knows anything about box-sizing rule.
Unit-less zeroes, no empty rules do make sense, but I guess decent CSS compressor would take care of those.
I suspect some of the complaints are valid, but simply saying "broken box model" doesn't explain why.
Overqualified Elements Element (a#galleryLink) is overqualified, just use #galleryLink without element name.
Indeed, I'd argue it ought to say that you EITHER ought to use a.foo or #foo depending on what you're doing in the page.
I'm not an efficiency nut, but it's quite possible #foo runs faster than .foo and this might be important to you, even if giving multiple things the same ID makes you feel dirty.
The argument against IDs is to encourage a mindset for making reusable rules. Obviously, in any project of even basic complexity, you're going to run into elements that only appear once per document. Having a class rule that's used only once is not only acceptable, but probably an inevitability.
The other end of the argument will suggest that it makes for better code readability: an element with an ID guarantees the author intended for this element to appear only once in this document.
There's the whole "IDs are faster than classes" argument; the renderer has to do a substring match instead of a full string match on classes, which you can imagine with today's processors is a relatively tiny hurdle given the scale of an average HTML document.
The whole thing is a trivial matter, but there exists a group of people who focus a good portion of their career on, specifically, CSS, and like any master of the craft, arguments at their end of the knowledge spectrum is going to boil down to things that seem like minor details to laymen. So don't worry about IDs vs. classes too much.
You could for instance define some shared "widget" styles, and then some custom additional styles for a search widget and other additional styles for a filter widget. That way you only have to define the shared styles once, resulting in less CSS (DRY), easier maintenance and more consistency. She helped reduce the CSS of many Facebook pages massively using this technique.
Read more at http://oocss.org
Also, just because you only have an element once at a page right now, you're not necessarily sure it will stay that way. Especially if the HTML code is in some shared template file that you use across your site.
E.g. rules reuse in SCSS can be done with @extend: http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#ex... That way instead of adding classes to your HTML you just group selectors in your CSS appropriately.
Seriously, if you do CSS and did not try SCSS do it now.
But no one would do that. You don't need every possible combination because you want some consistent styles throughout your site. In Nicole's examples, she's getting pretty sophisticated effects, and I don't see her applying more than 3 classes to any element. (http://oocss.org/module.html)
By no means am I a CSS expert, but I'd hesitate to call someone's ideas "bs" if that person has the kind of experience Sullivan has.
I may not like all of Douglas Crockford's suggestions in JSLint, but you know what? He's way more experienced with JS than I am, and doing what JSLint says has saved me pain on more than one occasion.
I've found Nicole's understanding and knowledge of CSS falls short of the standard necessary to advocate CSS best practice with tools such as this. So she's failing at working with the strengths of CSS.
Pick your role models carefully, and please, don't follow blindly.
I'm not going to blindly do whatever she says, but if someone wants to call her ideas "BS" and I don't know who that person is, I'm more likely to discard their opinion than hers. If that person is Eric Meyer, well OK then.
You say her "understanding and knowledge of CSS falls short." Can you point to facts she gets wrong (not just opinions you don't share)?
i'm working on my first large web project in a while. i'm using Compass/SASS (looks like you are too, or at least blueprint) to try to make things easier but i am finding that the HTML/CSS part of this site is such an incredible time sink.
my approach has been coupling the HTML and CSS almost 1:1 except where there are obvious re-use cases (which i'm not yet great at identifying, two pages in). this is probably bad but is there really a better way? i'm finding everything needs its own div in order to be positioned correctly across browsers and so i end up with container divs, then inner divs for padding purposes, then divs for each element, etc. it's a mess.
and don't get me started on the complete impossibility of consistent selector naming scheme...
A lot of the time, it isn't hard and fast what the "best" way to do things is. What's important is that you realise everyone has reasons for doing things how they do, and that they are trying to solve particular problems with their approach. If you don't have the same problems, or solve them in different ways, you may disagree with their approach or even find it nonsensical.
Of course, this shouldn't be used as justification for remaining entrenched, you should always try to understand where people are coming from and see if you could learn something.
The tool flags these issues for the [OO]CSS writer to attend to. If I say "look out walking on that floor it's wet" that doesn't mean you can't choose to walk on the floor nor even that I'm telling you not to.
Why is using floats bad, and what are the abstractions one would use in place of floats? Tables? Or grids?
I've posted a bug report demanding a clarification of the documentation on that point.
Not surprisingly this "system" (this word really makes it sound more than it is) can be found on one of the CSS Lint creator's Github: https://github.com/stubbornella/oocss/blob/master/core/grid/...
While simple, it's definitely way more elegant than some of the grid systems I've seen built, such as the popular 960 fluid grid layout that ultimately generated nearly 800 lines of CSS for 5 columns.
It also goes hand in hand with the core principles of OOCSS, which essentially states to extend classes and use multiple classes per element.
The usage of floats all over the place is no longer justified since all major browsers support now inline-blocks and CSS tables.
Heading (h1) should not be qualified.
this page = 1 errors and 2 warnings
craigslist.css = 4 errors and 340 warnings
facebook's css files' = 0 errors and 140 warnings
google home page: 0 errors and 0 warnings
ebay = 0 errors and 64 warnings
Are these results meaningful? I don't know. Thoughts?
I'm not going to say it's useless, but it certainly isn't as good as a real CSS validator.
Many of the aspects of CSS Nicole is trying to improve with OOCSS/CSSLint simply vanishes when you use SASS (though some still stand). Some of the points as they pertain to CSSLint: https://github.com/stubbornella/csslint
Take for instance the issue of reuseability. Nicole's solution to that is less CSS selector specificity, to not use IDs, and to sprinkle containers with several modular CSS-classes. By using SASS functions, mixins and extends you can achieve that without doing either of those things.
I much prefer using SASS to manage my source code and the related concerns, without resorting to these kinds of sacrifices.
Anecdotally, the designer where I work uses SASS, but in our last iteration of our web app, his compiled stylesheet was something like 10,000 lines.
Your designer colleague probably didn't have a sufficient understanding of the difference between @extend and @include. It's not hard though, a few tests using the different methods and analyzing the results should be enough to understand when to use each.
It is utterly impossible to generate worse CSS with SASS than by just writing CSS directly, as SASS does not deprive you of any CSS feature. SASS provides you with a bigger and more capable toolbox, but won't stop you from using the wrong tool in any given situation.
As well, the functions and built lib are chock-full of comments, which any decent IDE should be able to fold away.
Maybe too much attention put on aesthetics, less on code (nice start though)
Crockford may be an opinionated cantankerous old goat, but at least he gives you options to dial down some of the crazy he's baked into JSLint.
* He's also awesome, but anyone who's worked at Yahoo! or glanced at the JSLint Issues list or Pull Request queue can attest that he has strong opinions.
I need my CSS fast, Ferrari fast.
I don't need toddlers to be able to have a mental model of all my style rules.
• browsers support duplicate IDs already (try `<p id=foo></p><p id=foo></p>` and you'll find that `#foo` styles both)
• both IDs and classes can be preprocessed and looked up using hash tables or similar
https://developer.mozilla.org/en/Writing_Efficient_CSS — suggests that Gecko optimizes class lookup as well
1) "Don't use IDs in selectors"
2) Most "Overqualified Elements"
3) "Broken box model: using height with padding"