Why it's completely unnecessary to create one-line CSS selectors
blog.nodnod.net
blog.nodnod.net
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
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.
I don't have a strong preference for multi-line or single line, but I do insist on keeping all the attributes in alphabetical order.
* Position * Display * Box Model * Text Stuff * Z-Index
This makes it easiest to scan for layout information which is what I usually toughest to figure out.
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.
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.
When your editor can hide the details or navigate directly to the block you are looking for, formatting becomes less important for navigation.
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.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 :-)
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.
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
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.
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.
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.
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={,}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....
The search function in VIM is very robust if you know what string to use.