

Why it's completely unnecessary to create one-line CSS selectors - thedz
http://blog.nodnod.net/post/545144090/knowing-your-tools

======
JeffJenkins
I'm totally confused. I never even knew that this was an issue, and I agree
with the author that that is a terrible solution. If you really have so much
CSS that you can't easily figure out what selectors you have, you should
probably be breaking it up into multiple files. It's also helpful to use
something like sass for slightly better organized and more concise styling.

I've been guilty of this in the past too, but we really shouldn't be throwing
up the modern conventions of source code organization for CSS

------
JoelSutherland
I know four extremely good CSS developers with at least 500 sites of combined
experience. Two use one-line and two use multi-line.

Both positions are completely reasonable. Not one of the four things either
style is stupid or unnecessary.

To people with a background in programming the benefits of multi-line css are
immediately obvious. Without a strong CSS background it is harder to
appreciate the advantages of one-line selectors. This article misses a number
of them:

1\. It is just as easy to scan attributes that are in one line for someone
that writes a lot of css. Typically attribute order is fixed so it becomes
natural to know where in a line to look for particular ones.

2\. _Finding_ a selector is different than _scanning_ selectors. It much
easier to understand the structure and intent of a CSS file when you can look
at many selectors at once.

3\. Comments are visually more significant when using one-line CSS. CSS for
the header section of a website might run 20 lines using single-line or 100
lines using multi-line. It is much easier to use comments to structure a CSS
document using single-line.

To be clear I am not advocating single-line over multi-line. I am just trying
to give better representation to a method that perfectly reasonable people
use.

~~~
thedz
But again, this comes down to knowing the tools better. I've done probably as
much CSS as the developers you mention, so I'm not completely talking out of
my ass. I just want to make sure that people realize what their editors are
capable of before doing manual workflow optimizations.

1\. With all things equal, I'd say that the developer that is able to scan a
vertically aligned list of attributes can do it fast. Plus, there's no
horizontal scrolling. I'm not saying one-line scanning will be slow, but I'm
arguing that with equal practice, vertical attributes will simply match what
the eye is able to do more naturally.

2\. In Textmate, you can fold all the attributes, and see a essentially a list
of your selectors, with comments.

3\. See #2.

I wonder if the developers you mention ever gave using symbols lists and code
folding a shot before manually adjusting their workflow to mimic those
features.

I really do believe that if they did, they wouldn't be using the one-line
approach.

~~~
JoelSutherland
I'm not arguing for one way or another. I'm saying that reasonable CSS experts
prefer doing it both ways. I can assure you that each one of them has coded
their fair share of sites both ways. In fact they pick up each others CSS and
make changes all the time. They just reasonably have different preferences.

------
antidaily
When you scan, you're looking for the id or class, not its attributes. I'm a
huge fan of one-line and have been doing for 5 years. It's just faster for me.

~~~
blaix
Right. And the whole point of the article is that using any modern editor, you
can easily scan to find an id or class without resorting to one-liners, which
do make the attributes harder to read/write/debug/diff.

~~~
antidaily
The debugging argument is a joke - who doesn't have some sort of soft wrap
option on their editor? what about people who don't write one-line css but tab
nested classes (such as the writer of the article)?

~~~
thedz
Soft wrapping long one-line css selectors completely defeats the purpose of
putting it all on one line in the first place.

~~~
nfnaaron
No, it _helps_ people who like one line. You leave soft wrap off normally, and
you see your lines the way you intend. If a line extends off the end of the
screen, and you don't want to scroll to see the rest, turn on soft wrap to
see, then turn it off again.

------
ra
CSS isn't like most code. The sequence of lines has very little bearing on
execution sequence.

CSS is all about being well organised. If your selectors and attributes are
well organised, then one line CSS absolutely makes sense.

Group selectors by feature and order attributes uniformly. Very easy to read.

Much better to glance at the screen than scroll through a vertical column of
formatting declarations.

~~~
rimantas

      The sequence of lines has very little bearing on execution
      sequence.
    

Maybe I misunderstood what you said, bet sequence is important. When two
separate rules (with the same specificity) match an element, the last one
wins. There is a reason why devs learn LoVe-HAte mnemonics. For those who
don't know it helps to remember the order of CSS rules for links: a:link,
a:visited, a:hover, a:active. A:focus is getting more use recently, so usually
it is stuck betveen V and H.

~~~
ra
You are correct, that's why I said 'very little bearing' rather than 'no
bearing'.

In practice, most of the time specificity is all that matters.

I try to avoid 'last one wins' situations as they often mean you have written
redundant CSS, hence making CSS harder to read :-)

------
akkartik
This seems like a good place to solicit feedback on my css style. ( _Update_ :
css for my current project: <http://readwarp.com/main.css>)

I use one-line CSS selectors.[1] My CSS tends to the minimal because it's not
my differentiator. Especially in the small there's a huge difference between
having two screens of css vs six screens, with little extra complexity.

I rarely have long lines. Mostly because my styles are minimalist, but also
this: selectors occur multiple times in my css. I organize my css into
thematic sections. Layout. Fonts. Colors. Different 'aspects' of the same
selector occur in multiple sections. Is this wrong? I haven't noticed any
browser unable to handle it.

I do indent nested classes - but only in the layout section where the
cascading matters most.

When I do have long lines I hard wrap and indent and use two lines. Still
maximizes screen use, so I don't understand those who say 1% of selectors
being on two lines defeats the purpose of one-line selectors.

Like jules, I don't understand the counter-argument that you can just use
folding. The whole point of one-line mode is that you can see _attributes_.

I use folding to collapse sections of a file. To have to open and close folds
at such a fine granularity strikes me as ridiculous. I would just end up
having the folds always open.

[1] I'm a programmer first, so I guess that runs counter to JoelSutherland's
generalization.

------
weixiyen
One-line css classes is horrible, even if you don't have scanning tools at
your disposal. It makes it harder to work with your CSS and know what is going
on.

I prefer this style, indent the last brace:

<http://stopdesign.com/css/base.css>

With decent commenting and closing bracket indented, CSS is real easy to
browse and understand which section of your page / site you are working on.

The only other option I'd consider is Google's recommendation for defining one
attribute, and piling on a ton of selectors that require that attribute. It's
totally difficult to maintain but at the same time it makes your site load
slightly faster if you have time to spare. Wish there was a program to do
convert CSS coding styles automatically...

Also, blueprint.css style of doing CSS where you append a bunch of classes to
each HTML element makes me want to stab my eye with a pencil.

my 0.02

~~~
retlehs
Use Blueprint as a blueprint. Remove the span-4's and append-1's after you've
created an id or class that does the same thing.

When I use Blueprint I'm able to rapidly create websites (the base typography
is the best part of Blueprint) and then you can just gut it out once a site is
complete.

------
aw3c2
I like one-line CSS. Probably because I am a fan of easy and accessible
webdesign. My biggest CSS file has maybe 80 selectors, about two pages.

It boils down to "do it as you like it". Linked post does some childish
flaming against editors that do not have that kind of "collapsed" view which I
find a far fetched and insulting.

~~~
thedz
A does not follow from B. One-line CSS has absolutely nothing to do with "easy
and accessible web design".

Editors which are not able to collapse code or provide symbol lists via built-
in feature or plugin are editors, but not programming editors. I don't think
you'll find many people who disagree with that.

Now if you choose to use an editor that isn't geared to programmers while
programming, that's your choice.

------
rauljara
Also, in Textmate (and most modern editors) you have access to code folding.
Cmd-opt-0. All of those classes become the equivalent of one liners for
scanning.

------
gcr
For vim:

    
    
      function! CssFoldText()
          let line = getline(v:foldstart)
          let nnum = nextnonblank(v:foldstart + 1)
          while nnum < v:foldend+1
              let line = line . " " . substitute(getline(nnum), "^ *", "", "g")
              let nnum = nnum + 1
          endwhile
          return line
      endfunction
     
      set foldtext=CssFoldText()
      set foldmethod=marker
      set foldmarker={,}

------
10ren
What's the incantation for a _symbols list_ in vim?

~~~
sipior
Typically, you would use something like Exuberant Ctags to generate a taglist
file, which you then tell vim about using "set tags" (this process can, of
course, be automated using an autocmd). Have a look through ":help tags" for
all the amusing ways you can search and jump to tags in vim. Also, consider
installing the taglist plugin for vim, which will get you a nice list of all
the tags in a buffer.

Unfortunately, Exuberant Ctags doesn't grok CSS by default. The necessary
modification is quite simple, and you can find it here:
[http://scie.nti.st/2006/12/22/how-to-add-css-support-to-
ctag...](http://scie.nti.st/2006/12/22/how-to-add-css-support-to-ctags).

~~~
alttab
I generally type colon, slash, and then something like "div.perfmon span.more"
and get to where I want.

The search function in VIM is very robust if you know what string to use.

~~~
sipior
Yep, that's certainly true. One nice thing about tags, though, is that they
can span an entire project (whatever files you specified for inclusion in the
tags file). So you can move the cursor over a function invocation, hit
"ctrl-]", and jump to the definition of that function, in whichever file it
lives. Hit "ctrl-T", and you're back where you started. You can search on tags
directly as well, making it easier to grok large, unfamiliar bits of code (the
taglist plugin really shines here).

------
hieronymusN
As noted in the blog post comments, using a CSS compressor for production will
tighten everything down for deployment and you get to keep a nice, easy to
read file for development by multiple people using different editors in a
manner they choose.

------
decadentcactus
I use both. One line is pretty handy for example with a css sprite I had to
use... 30 lines of identical elements (but different background-position) is
easier on one line each.

~~~
Jach
Sounds like you could use Sass or simply generate all those with a trivial
script. [http://blog.dynamic50.com/index.php/2009/08/cooking-with-
sas...](http://blog.dynamic50.com/index.php/2009/08/cooking-with-sass/)

~~~
decadentcactus
I actually downloaded CleverCSS (similar to Sass) a few days ago and it's been
working great so far. I'll need to figure out loops though. Although it is all
written at the moment so it's no big deal (probably quicker to Ctrl+V 30 times
and go through it, than writing a generator).

------
Dysiode
Why can't we all compromise and make our IDE's fold functionality
collapse/expand one-liners to block format instead of hiding all the
attributes?

------
trafficlight
CTRL-F works pretty good, too.

