42 ms·

The About[1] page, which explains the linter's rules, should be more prominently linked I think. I am very much an amateur at CSS. I know the basic rules (I ho

The About[1] page, which explains the linter's rules, should be more prominently linked I think. 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 http://ithaca.arpinum.org/css/screen.css. I definitely don't doubt it could be improved.) [1] http://csslint.net/about.html http://csslint.net/about.html

bherms 15y ago
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.
- telemachos 15y ago
  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.
  - bherms 15y ago
    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)
    - jacobr 15y ago
      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.
      - bherms 15y ago
        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.
        billybob 15y ago
        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 http://oocss.org/module.html)
huckfinnaafb 15y ago
>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.
- jacobr 15y ago
  Speaking of specificity, maybe using !important should also give a warning.
  - huckfinnaafb 15y ago
    Just submitted this as an issue on GitHub, clearly !important is a bad practice for application-native CSS.
- Ameero123 15y ago
  Great points huckfinnaafb thanks for sharing.
rimantas 15y ago
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.
- gigamonkey 15y ago
  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.
- redemade 15y ago
  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"
- podperson 15y ago
  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.
  - pbhjpbhj 15y ago
    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 https://developer.mozilla.org/en/Writing_Efficient_CSS for example.
ZoFreX 15y ago
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.
unshift 15y ago
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...
- mindhunter 15y ago
  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.

bherms 15y ago

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.

telemachos 15y ago
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.
- bherms 15y ago
  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)
  - jacobr 15y ago
    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.
    - bherms 15y ago
      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.
      - billybob 15y ago
        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 http://oocss.org/module.html)

huckfinnaafb 15y ago

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

jacobr 15y ago
Speaking of specificity, maybe using !important should also give a warning.
- huckfinnaafb 15y ago
  Just submitted this as an issue on GitHub, clearly !important is a bad practice for application-native CSS.
Ameero123 15y ago
Great points huckfinnaafb thanks for sharing.

rimantas 15y ago

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.

gigamonkey 15y ago
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.
redemade 15y ago
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"
podperson 15y ago
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.
- pbhjpbhj 15y ago
  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 https://developer.mozilla.org/en/Writing_Efficient_CSS for example.

ZoFreX 15y ago

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.

unshift 15y ago

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

mindhunter 15y ago
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.