5 ms·

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

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.
  - podperson 15y ago
    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.
mindhunter 15y ago
Objection!
ryan-allen 15y ago
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.

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

mindhunter 15y ago

Objection!

ryan-allen 15y ago

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.