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
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.
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.
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.
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.
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.
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.
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.
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.
Last time I used Blueprint, it was with SASS & Compass, which lets you mix in the blueprint.css rules in the CSS, keeping the HTML clean and semantic instead of a stupid version of tables with all the "span-4" nonsense.
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.
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.
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.
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.
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)?
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.
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.
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.
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).
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={,}
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.
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.
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).
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