
High-level advice and guidelines for writing sane, manageable, scalable CSS - jonphillips06
http://cssguidelin.es/
======
al2o3cr
"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
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
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.

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

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

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

~~~
eriktrautman
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
Crashes feedly

------
vkjv
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
You are not a good developer, and if this is really your attitude, I would
never hire you. Learn to pick your battles better.

