High-level advice and guidelines for writing sane, manageable, scalable CSS

by jonphillips06 • 12 years ago

30 14 12 years ago

My approach to writing manageable scalable CSS ( I am a programmer) is to never write CSS files on my own. Use a framework like Zurb Foundation etc. and modify the underlying SASS files but never ever write actual CSS files. And scan my HTML for style tags to ensure that I never violate my own rule.

vkjv• 12 years ago

Stopped reading at spaces instead of tabs. It may be a silly argument, but it's one that I'm willing to fight in the streets over. Bring it on.

sbarre• 12 years ago

You are not a good developer, and if this is really your attitude, I would never hire you. Learn to pick your battles better.

zackangelo• 12 years ago

Read down a little further:

But, as with anything, the specifics are somewhat irrelevant—consistency is key.

huuu• 12 years ago

Not using CamelCase makes this CSS very hard to read. For example:

  <div class="box  profile  profile--is-pro-user">

So I don't get the advice of using hyphens only. To me this is more readable:

  <div class="box  profile  profile--isProUser">

Danieru• 12 years ago

Is there a chance you mostly program in languages where camelCase is common? For me as a C programmer / Javascript programmer both are readable.

I think hyphens are useful in css to keep the namespace non-confusable with the javascript.

moron4hire• 12 years ago

That's actually where I mix the two uses. CSS class names, I use hyphens, because what CSS calls a class is not the same thing as what Javascript calls a class. DOM element IDs, I use camel case, because it's likely to also be the variable name I use on the Javascript side to hold the reference to the DOM element.

al2o3cr• 12 years ago

"Nesting in Sass should be avoided"

concurrently with

"By doing this, a developer can see at a glance that .foo__baz {} lives inside .foo__bar {} lives inside .foo {}."

It's like reinventing descendant selectors, but with more typing. In fact, if descendant selectors weren't supported by browsers, this would be the workaround.

And for the punchline, the authors suggest that "descendant" selectors (.foo__bar, etc) in plain CSS files should be indented additional spaces. Y'know, so they like the nesting in Sass that you're not supposed to do. (facepalm)

OOCSS seems to combine all the ridiculous trends in computing into one bundle of sad: OO-fetishization, "don't do that because it takes a microsecond longer sometimes" premature optimization, and "hypothetical reusability trumps actual usability"...

tobr• 12 years ago

I supposed the idea is to limit specificity. It's the same reason you should use class instead of id.

I find the BEM syntax to look horrible though, with the double hyphens and underscores. Why not e.g. capitalize blocks and elements, keep modifiers lower case, and just use single hyphens?

protonfish• 12 years ago

I've seen way worse CSS recommendations, but this still comes across not as a way to write sane, manageable, scalable CSS, but as rules to make working with insane, unmanageable CSS a little easier. Verbose comments and consistent naming and formatting do not address the underlying causes of CSS hell.

The worst CSS practice today that developers insist on shooting themselves in the foot with is the monolithic CSS file. Whether this is one 15,000 line file or 20 smaller ones that are combined at compile time, if you are going to ignore the tools CSS has for limiting the scope of styles and include all styles on all pages you are going to have trouble.

The rules I use that work well to manage style sheets are:

1. A primary style sheet should be included on every page, but it should only contain styles for structural elements (header, navigation, footer) and common default content styles. It should only be changed after extensive deliberation and testing. If you have sections of your site that use a completely different template, they should use a different primary file (main_sales.css or something.)

2. If a section of the site uses the same overall template but needs custom content styles, use a secondary style sheet and only include it on the pages that need it. I know that having more HTTP requests hurts performance but 2 includes is not unreasonable for the benefit of controlling the scope of styles. If content styles in a secondary style sheet appear to be useful for all pages, move them to the global style sheet only after proper consideration.

3. Use embedded style sheets. I know you were told this is "bad" and never do it, but have you ever stopped to question why? Coding CSS directly in the HTML is the correct technique if the styles are meant only for the page they are on. If this is the case, embedding styles improve maintainability (no need to hunt for the external style sheet, it’s right there next to the HTML) and performance (no extra HTTP requests.) If embedded styles are judged to be valuable to other pages, move them to a secondary sheet after proper consideration.

Including all styles on all pages (what I call the "monolithic style sheet") is a maintenance nightmare because no matter how you comment or name selectors, you cannot predict the side effects of even small changes. Because each page’s layout could be affected differently, every single page must be checked by a person who knows what layout was intended. This is a Herculean task that is not inherently caused by the CSS specification, but by poor architectural choices. Please, for your own benefit, start thoughtfully using secondary and embedded style sheets.

edit:

I forgot to mention that monolithic styles sheets also significantly hurt performance due to loading and parsing large amounts of unnecessary code.

eriktrautman2• 12 years ago

"Nesting in Sass should be avoided"

Aren't you missing the best feature of using SASS in the first place? It's a joy to create highly targeted styles with proper SASS nesting... why is it to be avoided?

nroman• 12 years ago

If you do in SASS

  .Foo {
    a {
      /* stuff */
    }
  }

It translates into:

  .Foo a { /* stuff */ }

CSS is evaluated right to left, so this means every time an <a> is encountered in the page it has to at its parent chain to see if any has class Foo. This can cause performance issues especially for really large pages.

That said, for most pages it won't make a noticeable difference so it's kind of up to you to decide if you care.

eriktrautman2• 12 years ago

What's the more performant/"proper" way to narrowly target CSS in that situation? Just tacking classes directly on the links (e.g. `<a href="#" class="foo-link">` starts to get very cluttered very fast if you want the benefits of deeper nesting, targeting and namespacing (e.g. `<a href="#" class="foo-bar-baz-link">`. Is it best to simply try to avoid nesting of styles altogether and keep namespaces as flat as possible?

naturalethic• 12 years ago

Crashes feedly

High-level advice and guidelines for writing sane, manageable, scalable CSS

Related Stories