

Show HN: CSS Quality Guide - bevacqua
https://github.com/bevacqua/css

======
udfalkso
Great guide. I'd suggesting adding a bit more about the "why?" if the goal is
compliance. In some cases, there are performance benefits to the stated
approach (like not deeply nesting classes or avoiding tag based selectors) but
some readers may not be aware of this and may assume that it's entirely a
style based preference which is easier to ignore due to personal preference.

------
jjar
Ignore ID's? What? The point of an ID is it is a selector used to identify
only one element on a page - A header or a footer for example. You can't
replace that semantic meaning with classes, if you're only going to be using
the style once on a page then change it to an ID.

Example: <div class="header inset aboutUs"> or <div id="header" class="inset
aboutUs">

The difference is the second option shows at first glance what the element is
supposed to be representing to someone reading your code.

~~~
chrislloyd
This is pretty common advice and not a point of contention for front-end
folks.

> if you're only going to be using the style once on a page

Herein lies the the problem. You now can't use that header anywhere else,
meaning the it's non-composable. You end up writing less, and more
maintainable CSS when you treat components as immutable and composable.

Most people consider the additional readability of separating out the `id` to
be negligible.

~~~
Joe8Bit
It's not composable if you only write raw CSS, they're perfectly composable
via @extend's and @include's, e.g.

    
    
       #login-widget {
          @extends widget();
       }
    

Best of both world's, the semantic meaning of id's with the composability of
classes, plus, the compiler is smart enough to reduce duplicity to it's bare
minimum

~~~
nilliams
But it's still not a good idea to use IDs. Why not:

    
    
       .login-widget {
          @extends widget();
       }
    

The specificity that ids bring alone are good enough reason to avoid them
forever. They're a sledgehammer that can pretty much only be overridden by
`!important`.

If that somehow sits fine with you perhaps consider the rule the rest of the
software world has accepted long ago -- 'this code will be changed'. The fact
you think you will really only have one of these things on a page at once
(hence making it suitable for an ID) ... that WILL change.

There will come a day when you have a login-widget in your sidebar, yet at
some obscene last-minute moment the customer will demand a dedicated login
page too, your developers will want to use your base template (which has your
login widget visible in the sidebar) creating 2 login widgets on-page, cursing
your assumption that you thought you knew better.

Ignoring that, you could forget my example above (I'm sure there's a way you
could dismiss it as contrived) and learn a lesson from the OOP crowd and just
never write singletons [0] ever. It's just a really bad assumption to think
you'll only want one of a thing.

[0]
[https://en.wikipedia.org/wiki/Singleton_pattern](https://en.wikipedia.org/wiki/Singleton_pattern)

------
armandososa
I disagree on what this says about frameworks. I think frameworks are great.
They are specially great when you come to really understand one and how it
works and how it can be customised.

The major problems I've seen with frameworks is that people just use the
default look or try to add customisations on top of the default CSS,
overriding styles. I mean, that is just setting yourself up for a world of
pain.

But most CSS frameworks are really, really flexible in the build stage. You
can tweak a few variables that can dramatically alter the appearance of a
stylesheet and give you an awesome base to build on. Pretty much for free.

If you do all the CSS from scratch you're anyway going to write at the least a
reset, some base typographic styles, responsive stuff, and some kind of grid
system. Why not use something that is widely used, peer-reviewed, and very
customisable?

~~~
donjh
Do you have a particular framework you'd recommend?

~~~
bwy
It must really depend on what you're looking for/doing. My favorite is
[http://getskeleton.com/](http://getskeleton.com/). I'm a noob, but I like
that I can understand and completely customize the 400 lines of code
([https://github.com/dhg/Skeleton/blob/master/css/skeleton.css](https://github.com/dhg/Skeleton/blob/master/css/skeleton.css))
easily.

------
joshribakoff
I like how he explains separating layout from presentation. When writing the
layout code, keep in mind how its coupled to the HTML.

This link mentions how "layout" like z-index is coupled to the structure of
HTML, because nesting elements creates new stacking contexts (Z-index is
hierarchical - an element's z-index only controls it's depth within the
current context, not the overall document).
[http://philipwalton.com/articles/what-no-one-told-you-
about-...](http://philipwalton.com/articles/what-no-one-told-you-about-z-
index/)

This one advises using "js" prefixed classes for JS, so the JS is only coupled
to the HTML & not the CSS: [http://philipwalton.com/articles/decoupling-html-
css-and-jav...](http://philipwalton.com/articles/decoupling-html-css-and-
javascript/)

------
scotchio
" _Frameworks and Vendor Styles: Stay away from frameworks_ "

I disagree - frameworks are awesome.

I guess it's all contingent to the project you're working on though. For small
projects, it speeds things up and stops you from reinventing the CSS wheel.
With large projects, even if you don't use a framework, you [should] end up
making one with a style guide (eg: [http://walmartlabs.github.io/web-style-
guide/](http://walmartlabs.github.io/web-style-guide/)).

Either way, to completely rule them out is not the best advice IMHO. Other
than that, pretty great post/share.

------
handonam
Why not look at BEM?

[https://en.bem.info/](https://en.bem.info/)
[http://csswizardry.com/2013/01/mindbemding-getting-your-
head...](http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-
bem-syntax/)

Harry Roberts really simplifies the idea of it.

------
piker
This was very helpful. One thought on your "Mobile first" media queries
segment. While absolutely correct in principle, those of us who unfortunately
have to support IE8 should make sure to have a default style set at the
"Desktop" level (ie. desktop-first) and have the @media breakpoints kick in at
lower resolutions. Otherwise, they may figure out the hard way (as we did)
that their webpage looks like trash on browsers that don't support media
queries.

~~~
talmand
One philosophy is that if the browser is old enough to not support media
queries then they should deal with the stripped down, mobile-first version of
the site that they get anyway.

At that point, just create a separate IE8 stylesheet loaded with conditional
comments to fix the most annoying issues so that the site is at least
functional for that type of visitor. There's no reason to bloat the main
stylesheet with useless crap for old versions of IE.

------
matthewbauer
Most style guides say to use namespaces for everything. I've never used them.
What do I have to be worried about?

~~~
mikewhy
If you have say a post entry:

    
    
      .post {
        border: 1px solid #000;
      }
    
      .post .title {
        font-weight: bold;
      }
    

And you want to put it into a sidebar

    
    
      .sidebar {
        background-color: #ccc;
      }
    
      .sidebar .title {
        text-decoration: underline;
      }
    

That post's title is now going to be underlined. That's one of the reasons for
namespacing. If the classes were `.post--title` and `.sidebar--title`, this
would be avoided

~~~
austinlyons
Wouldn't you just instead write the CSS as follows?

    
    
      .sidebar.title {
        text-decoration: underline;
      }

~~~
talmand
That likely wouldn't have the intended effect as I find it doubtful that the
element with the sidebar class would also be the title.

------
octocoupler
What is so bad about frameworks? Isn't a simple framework with good standard
classes a good thing?

~~~
ricklancee
The author probaly never worked with a deadline before, where there is no time
to build everything custom.

------
pierotofy
Lots of guidelines, many without an obvious reason.

------
evunveot
I'm surprised how much the personal standards I've built up working solo for
many years align with these.

Regarding "Presentation-Specific vs Layout-Specific Styles," the way I've come
to organize things is roughly "outside-in" i.e.: position, margin, border,
width/height, padding, font/line-height, text styles. I also always put
"display" and "box-sizing" first, if they're present, since they change the
effect of several things that follow.

I disagree with "Prefer nested selectors ... _only if both .foo and .foo .bar
need styling_." I prefer nested selectors always, mostly because it's annoying
to have to go back and nest something later when you realize the container
needs rules, too. Also I sense that there's something beneficial about the
nesting of the (in my case) scss matching the nesting of the HTML, but that
might just be aesthetics.

Also disagree with "Settle for a few (2-3) breakpoints and use those only," at
least for the types of designs I have to work with nowadays. The prevailing
style seems to consist of a series of striking, highly independent sections
with their own internal layout (think the landing page of a typical, new open
source project or startup, with a hero unit or carousel, a list of features in
some number of columns, testimonials in some [other] number of columns, etc.).
If you make each of those sections adhere to the same handful of breakpoints,
either you carefully limit your design or you risk ending up with strange
looking layouts in certain sections at certain "in-between" viewport
dimensions. I tend to treat each such section completely independently and use
as many or as few breakpoints as necessary for that particular internal
layout. Sass definitely helps with this, since nested media queries get
hoisted to the top level automatically, so you can put them in a natural
context.

As for mobile-first, I always work desktop-first. Part of that is that mobile-
first is pretty much impossible when all you're given is a psd with a full
desktop design. But I also find it completely natural to start with the
desktop design, narrow the window until something looks off, throw in a media
query to fix it, and repeat. And as someone else has already said, when you
have to support IE8 to some degree, it's nice to have desktop as the default.

I find most of the claims in the linked article about mobile-first [1] to be
hand-wavy (you don't want to include "large heavy modules by default," or in
other words, you must assume that desktop-first is going to end up slow and
clunky on mobile) or contrived (the actual CSS example, where you can
eliminate a selector because on small devices the element in question happens
to have default styles). In my experience, in fact, things are usually
"heavier" on mobile, specifically because you tend to need a bunch of
javascript to deal with flyout menus and things having to expand and collapse
that can just be there on desktop. In any case: I don't see how the supposed
benefits of mobile-first can't be had desktop-first if you just take a modicum
of care in your work.

[1] [http://bradfrost.com/blog/mobile/the-many-faces-of-mobile-
fi...](http://bradfrost.com/blog/mobile/the-many-faces-of-mobile-first/)

