Why it's completely unnecessary to create one-line CSS selectors(blog.nodnod.net)
blog.nodnod.net
Why it's completely unnecessary to create one-line CSS selectors
http://blog.nodnod.net/post/545144090/knowing-your-tools
15 comments
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.
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.
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.
These are good points. Especially, "Typically attribute order is fixed so it becomes natural to know where in a line to look for particular ones."
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.
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.
I strongly prefer this rough ordering when writing css either way:
* 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.
* 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.
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.
Finding isn't the problem. It's understanding the intent and structure of the document by looking at multiple selectors at once.
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)?
Soft wrapping long one-line css selectors completely defeats the purpose of putting it all on one line in the first place.
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.
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.
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.
The sequence of lines has very little bearing on execution
sequence.
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 :-)
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 :-)
Except that you can collapse everything between the braces and get every statement on one line by hitting alt+cmd+0 in textmate.
When your editor can hide the details or navigate directly to the block you are looking for, formatting becomes less important for navigation.
When your editor can hide the details or navigate directly to the block you are looking for, formatting becomes less important for navigation.
But then you can't read the actual CSS properties.
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.
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.
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
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
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.
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.
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.
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.
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.
[deleted]
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={,}What's the incantation for a symbols list in vim?
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....
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....
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.
The search function in VIM is very robust if you know what string to use.
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).
If you drop the colon, you can turn on incremental search.
If you are consistent in ending your tag lines with an opening brace, :g/{$/p will work.
taglist is the most popular vim plugin. It gives a sidebar with your tags (in the ctags sense):
http://www.vim.org/scripts/script.php?script_id=273
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.
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...
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).
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?
CTRL-F works pretty good, too.
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