Hacker News Reader

Don't pay attention to that tool. Nicole has her own and peculiar view on CSS and many rules in CSS Lint make very little sense.

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.

Etc., etc.

Unit-less zeroes, no empty rules do make sense, but I guess decent CSS compressor would take care of those.

The purpose of these lint tools is to attempt to standardise your opinions as the correct way of doing things. Without a tool that 'checks for correctness' (against someone's opinions), they're perceived as just that: opinions.

It's a very clever way to convince others of your ideas. The same thing has happened with JS Lint. Suddenly many people agree 'this is the correct way to write javascript', you ask them why and they point at the tool as if the correctness is self evident.

Agreed -- almost all its complaints about the first css file I passed it were "don't use id selectors".

I suspect some of the complaints are valid, but simply saying "broken box model" doesn't explain why.

Ditto. Funnily enough you also get some rules that tell you to use id selectors:

    Overqualified Elements	Element (a#galleryLink) is overqualified, just use #galleryLink without element name.
    a#galleryLink {

This was given as a warning, but it's spot on too - https://developer.mozilla.org/en/Writing_Efficient_CSS for example.

I think it's actually saying a#foo is worse than #foo (assuming you're not reusing #foo in which case, conceptually, shouldn't it be a.foo?).

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.

I agree. most of these "rules" are frivolous. simply removing the 3 @import lines in the example file would be a much bigger win than worrying about ids and "overqualified elements"

I'm curious what folks do who follow the no-qualified-headers rule. When they have things that act like headers but which need to be styled differently than the single header style used on the site, do they just use classed P's or DIV's? Confused.

Objection!

>Isn't the whole point of an ID that it is like a class, but unique?

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.

In my projects, I use IDs purely for Javascript identification. I never use IDs to style things because 1) they complicate CSS specificity rules and 2) I get an urge to couple the element with JS, which creates this weird bind between JS and CSS that shouldn't exist.

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.

Speaking of specificity, maybe using !important should also give a warning.

Just submitted this as an issue on GitHub, clearly !important is a bad practice for application-native CSS.

Great points huckfinnaafb thanks for sharing.

Don't worry... CSS Lint is just anal. Your usage of those is fine in my book. I do the same stuff and I've been doing front-end development for something like 7 years now.

Fair enough and thanks for saying so. I suppose I just wondered what (if any) explanation there was for these particular preferences. That is, I understand that a linter (by definition) might be very picky and strict, but usually there's some basis for the rules. In the case of the two rules I asked about, I just don't see the rationale.

Nicole Sullivan, one of the creators of CSS Lint, is a proponent of what she calls Object-oriented CSS. It mean you define "objects" or "modules" that you reuse. The concept is not necessarily new, but she popularized it.

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.

And I recommend SCSS (http://sass-lang.com/ instead. It solves many problems you can come across when dealing with CSS and in much more elegant way.

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.

Yeah, the id thing is just bs. That's the point of id's, to be used for non-repeating tags in the html. While you could try to generalize and find all instances where id's shared similar properties, then extract those and apply them to classes, then add those classes to the elements, that just seems like a ridiculous approach to achieve reusability. In addition, if you move that direction, you start to deal with class bloat, which is no better than just adding inline styles (ie div class="red centered absolute fullwidth", etc)

Except that would be declaring styles, and not content, in the markup which would not be something Nicole Sullivan would approve of. It would rather be div class="post" and class="post featured" or something like that.

In practice you wouldn't actually create just a red class or a centered class... I just meant to demonstrate that as you get more and more granular in the shared attributes of a module you can start getting css bloat... ie: you may have a lot of uses of color:red + position:absolute + top:0, which is then reduced to class = module1, and another set of reused rules reduced to module2, etc... It depends on how complex your css is really, but it's something to consider as you start to apply the rules more and more and make your css completely DRY.

Of course, the absolute extreme of reusable classes would be if each class applied exactly one CSS rule. Then you could mix and match them in any possible way, at the cost of having 18 classes per element.

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)

"the id thing is just bs."

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.

Nicole Sullivan has nowhere near the experience in CSS as Douglas Crockford has with JavaScript. Compare their writings and their talks on their specialist subject matter. Also compare what their peer say about them. For Crockford the negatives are his opinions as to what constitutes good JavaScript, but not against his knowledge and experience.

Peer review is also an essential component. Crockford's contentious points are his opinions as to what constitutes JavaScript best practice, but his underlying knowledge and understanding is rock solid.

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.

Neither Crockford nor Sullivan is a role model for me, and I'm not following blindly. I'm merely observing that Sullivan successfully refactored the CSS on Facebook and got them onto a better development path. That's pretty hard.

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

is there any good way to avoid using IDs as selectors?

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

Regarding your first question: you can perfectly replace every id with a class. Writing object oriented is another thing. Personally I don't. Most CSS is very specifically written. It makes sense for real huge projects though.

There are many different ways to solve problems in CSS, and those problems include things such as how you organise your CSS as well as how you make a two column layout.

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.