huckfinnaafb

I suspect this means you should be using a grid system, either hand written or borrowed from somewhere that writes grid systems. Constantly using float everywhere is completely unnecessary for larger sites.

>Don’t use IDs in selectors >They are the fastest way a browser can select a given element.

Yes and no. Using an ID to get an element via JS is fast, undeniably so. But the difference in selecting by ID vs. Class in CSS is so minuscule it's hardly worth mentioning. If you're styling an element based on an ID used by JS, congratulations, you've just needlessly coupled JS and CSS.

>Performance at the cost of everything else. Performance as the altar at which all the other benefits of CSS are sacrificed.

Be more dramatic. OOCSS's primary benefit is to minimize maintenance and reduce CSS filesize. File transfer is the second biggest culprit of page load times. I hardly see optimizing CSS as a tertiary goal, and speeding up CSS does not sacrifice other things if done properly.

>Utterly arbitrary. Use as many as you need to get whatever result you’re after. You’re the designer, you know what’s appropriate, and it has little to no impact on performance.

The issue here is that people who use font-size too much are likely simply not appreciating the cascade. That can be said for numerous other properties like float, font-family, padding, and margins.

That all being said, CSS Lint is extraordinarily opinionated. How could it be anything else? If you're looking for a syntax lint, check out W3C's Unicorn. If you're looking to discover a new philosophy for writing reusable, extendable, and optimized CSS, make sure you understand why exactly CSS Lint is throwing you a warning/error and take steps to improve your styles.

So now my argument is probably that of browser compatibility and separation of jobs :)

That said, for anyone wondering why they're not practical...

    Spritesheet image - 9kb [http://imgur.com/Mcr9N](png)
        CSS needed to write the positions - ~1-3kb

    Pure CSS - 60kb

Not really sure why they went with red and not just... black or light blue.

Otherwise, yup... it's a grid. Looks like they're setting the grid elements to display:inline... which seems weird and unnecessary to me? Block elements don't belong inside inline elements.

I hate to keep posting this, but I've been unable to find fault with this grid [https://github.com/stubbornella/oocss/blob/master/core/grid/...] code. .lastUnit spans the pixel gap on the rightmost, nestable, extendable, fluid widths.

The two are mostly the same idea, but I think the OOCSS project implements it better and works with more browsers.

If you're not interested in separating layout markup from content markup, the box-sizing property might be for you.

But I'd certainly avoid using calc()...

"If you have some .class { width:25% } that will make 4 columns grid (25% + 25% +25% + 25%). The problem is that you can't have precision px margins (gutter). So in the past you had nested divs or .something-like-this{width:24%; margin-left:1%}..."

"With calc() that problem is solved now we can have .class{width:calc(25%-10px); margin-left:10px} . And with that we can have the flexibility of the % and the px precision."

This was never a problem if you separated your layout markup from your content markup, like so.

    <div style="float:left;width:50%">
        <div style="margin:12px">Hello, world</div>
    </div>
    <div style="float:left;width:50%">
        <div style="margin:12px">Hello, world</div>
    </div>

I see no reason why anyone would use this over a grid model such as this [https://github.com/stubbornella/oocss/blob/master/core/grid/...].

HTML and CSS are so easy to use that I prototype by actually building it, and then flesh it out as new things need to be introduced or, for example, I don't like the way the navigation works, I rewrite that small part.

I cannot imagine wrangling with Excel for anything other than tabular data.

I suggest Chromium for the paranoid!

I think Chrome and Firefox, together, have really pulled the web out of the dredges and put it on a path of more frequent updates and a more diverse market. Kudos to the Chrome dev team and all the people who contribute to Chromium.

Whitehats are only taking advantage of the unenlightened as much as a mechanic is taking advantage of someone who doesn't know anything about cars - they provide experience and expertise and offer a service for a high price - at least, a higher price than if the client knew how to fix it themselves.

Very useful for people terrible at making their own nice looking gradients.

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