Why is this method of css organization better?

Question

A senior developer at my workstation codes like this:

table {border-collapse: collapse;border-spacing: 0;}
fieldset,img {border: 0;}
address,button,caption,cite,code,dfn,em,input,optgroup,option,select,strong,textarea,th,var {font:inherit;}
del,ins {text-decoration: none;}
li {list-style: none;}
caption,th {text-align: left;}
h1,h2,h3,h4,h5,h6 {font-size: 100%;font-weight: normal;}
q:before,q:after {content: '';}
abbr,acronym {border: 0;font-variant: normal;}
sup{vertical-align: baseline;}
sub{vertical-align: baseline;}
legend {color: #000;}
strong{font-weight:600;}

I coded the same thing like this (different part of same css code that i worked on before the senior developer reviewed/rewrote my code):

html {
    background-color: #7e1d32;
    font: 16px/22px arial, sans-serif;
}
#outer_container {
    min-height: 598px;
    width: 100%;
    background: #D4D4D4 url('../images/top_bg.gif') repeat-x top left;
}
#inner_container {
    min-height: 698px;
    width: 100%;
    background: #D4D4D4 url('../images/top_designed_bg.jpg') repeat-x top center;
}

/* top orange banner */
#top_orange_bar {
    height: 47px;
    width: 100%;
    background: transparent url('../images/top_orange_bg.gif') repeat top left;
}
#top_orange_bar_content {
    width: 1026px;
    margin: 0 auto;
}
#top_orange_bar_content .left {
    float: left;
    width: 730px;
    margin-left: 40px;
}
#top_orange_bar_content .left h4 {
    text-transform: uppercase;
    letter-spacing: 1px;
    font: bold 14px/52px arial, sans-serif;
    color: #7f1e32;
}
#top_orange_bar_content .right {
    float: right;
    width: 160px;
    margin-right: 40px;
    text-align: right;
}
#top_orange_bar_content .right a {
    margin-top: 8px;
}

What are the advantages of writing css code the way the senior developer did?

I would say your code is BETTER than the senior's. Your css only addresses the elements which you really want to alter. The senior's might format elements that are not meant. — gorootde, Jan 17 '12 at 00:04
@alex - true, but don't assume senior is worse in this case since there is no real performance reason to argue for or against the long / short version. Both are valid. Just the short one tends to be annoying to other programmers if they are used to the long form. In the firm I work for, none of us read through css like a book anyhow. It's all done via search so organization is relatively inconsequential. — Kai Qing, Jan 17 '12 at 00:07
@k_wave - you sure he's not just referring to the indenting and line usage? The top one looks like a basic css declaration to follow a reset. Not necessarily his application of the same code. — Kai Qing, Jan 17 '12 at 00:08
@KaiQing If by "annoying" you mean "hard to read and maintain", then yes :) — , Jan 17 '12 at 00:08
@pst - yes, I do mean hard to read and annoying, but not maintain. However, if you program sites all day long forever in an endless and joyless loop you realize how infrequently you need to change most css when you write it out in a realistic way. I have absolutely never had a problem finding and modifying any css regardless of how it is written because any decent text editor has a search tool and all css classes and ID's tend to be within a certain range. It's really not annoying to anyone that knows what they're doing. — Kai Qing, Jan 17 '12 at 00:14

Itay Moav -Malimovka · Accepted Answer · 2012-01-17T00:30:26.350

6

Well, he is not so senior...
He read somewhere that extra characters makes pages load slower, he is right, BUT Code needs to be maintainable and readable.
You should code the way you do, and use a minifier to clean your code of white space character when deploying the file to production. Usually this is a part of the build/release process.
That would be what a senior developer would do.

edited Jan 17 '12 at 00:30

answered Jan 17 '12 at 00:03

Itay Moav -Malimovka

52,579
61
190
278

2

its funny that you misspelled readable. BUT i do agree that he was probably trying to minify the doc. – Kristian Jan 17 '12 at 00:06
1

I don't think he was trying to minify the doc. I think it's just faster to write css inline than to enter, tab or reorder alphabetically for ease of human eyes. – Kai Qing Jan 17 '12 at 00:11

score 3 · Answer 2 · answered Jan 17 '12 at 00:02

3

Very little. You get a short document. It will be a few bytes less when transmitted over the Internet too, but that can be worked around with a CSS preprocessor.

It's pretty much personal taste.

answered Jan 17 '12 at 00:02

SpoonNZ

3,780
1
20
25

And deflate will remove any remaining size differences... – Jan 17 '12 at 00:09

score 1 · Answer 3 · answered Jan 17 '12 at 00:03

Your senior developer's method would result in an absolutely minute difference in bytes for file size. A pointless act if you plan on minimizing before calling on your site.

However, I preferred all on one line css when I had it my way cause I just search when I need to modify.

Readability and organization is the only reason to list it out the long way.

Zoltan Toth · Answer 4 · 2016-11-17T17:45:46.017

No real advantages - just less to scroll and easier to find the rule you need. That makes a difference when you have several thousands lines in your CSS file.

Your way however it's more readable. Just one note - when you do it like this it's a good practice to order them alphabetically even for better readability, like:

#top_orange_bar_content .right {
    float: right;
    margin-right: 40px;
    text-align: right;
    width: 160px;
}

score 1 · Answer 5 · answered Jan 17 '12 at 00:20

Considering that CSS is a language for web design and IMO most of web design is good typography, I think it's important to consider that even when you're writing CSS, typographical rules still apply, and you still have an audience.

At one time or another, assuming a site will be up for 2 or more years, another developer will have to touch code at some point.

So it's alot easier to read anything (book, magazine, blog, CSS code) if it's been written with indentations, spaces, line breaks, and punctuation in a meaningful way.

If I had to work with the first code sample you posted, I would pull my hair out. And I have alot of it.

For declarations with two or less properties, I will use one line. But for everything else, I use the expanded way as in the second code sample... and I leave line breaks after each close bracket. I do this for my own sanity and for the future readability by other developers.

Sections of the CSS file should be separated and commented by the section of the site to which they apply.

And then of course in production you want to use a minifier like the following: http://code.google.com/p/minify/

Why is this method of css organization better?

5 Answers5