Clean uncluttered coding.

If there ever was a controversial statement in the front end web development community, that one right there would make it to the top 10 list along with statements like 'Code for IE6' and 'Structure versus Style' and 'Fixed versus Fluid' and 'Hacks versus Workarounds'.

For the most part, I completely agree that coding should be as clean and as uncluttered as possible with the minimal number of nested divs used possible.

Not only does clean and uncluttered coding allow for greater ease of troubleshooting (less code to wade through), but especially in the case of CSS, it also pares down the potentials for cross-code conflicts that tend to pop up because of the cascading nature of CSS.

CSS == Cascading Style Sheets, so no wonder, right?

However, 'clean and uncluttered' is not always possible to do.

Why?

Because how 'clean' and 'uncluttered' one can get depends on a few important factors whose priorities can very well transcend the importance of coding 'clean' and 'uncluttered'.

Here are a few particular factors that come in mind:

- the structure of the site in question
- the layering requirement of various elemental building blocks
- how much formatting/stylization is needed for the content

Let's address the first structural factor by comparing a 2 column site with a 4 column site.

Here's a fact: A site that requires multiple columns with multiple blocks of text per column is simply going to REQUIRE more code to generate.

Yes, one can certainly convert a table into a bunch of divs and maybe pare down the number of code tags needed, but the fact remains that you have a requirement of X number of columns and A number of blocks of content per X number of columns.

Since I think most people can agree with that - that on a general level, structure requirements of a website can and does affect how much coding is necessary, I'll skip on to the second point which is the layering - also called 'nesting' - requirement of various elemental building blocks.

Let's say you have a basic site design that involves a header, a horizontal navigation block, a content block, and a footer block. Let's also say that you want to contain all four of the elements in one larger block so you can center it all and set a fixed width.

Going with this model, I think we can all agree that five containers are required to build this basic structure.

Now that you have these five containers, let's say you want to format the appearance of these containers and format the appearance of the contents of these containers.

Now we're dealing with the third factor - required formatting and stylization of the structure and its content - and this is where things get more complicated and even hairy.

From margins and padding to text alignment and text indentations to blockquotes and dropcaps - the more formatting is required, the more code will be required to perform the formatting.

Exactly HOW much coding is required and how many extra tags will have to be involved, however, depends on what exactly you want to accomplish, how cross-browser friendly you want your site to be, and also... how you do your math.

Yes, that's right.

How much coding you have to do and how many extra divs you're going to need also depends - or can depend, depending on how one looks at the situation - on how you decide to do your math.

Let's go back to that five container example.

Let's say that within the content container you want to display three blocks of content one by one and one after another in a vertical column. You want 20 pixels of vertical spacing between each block and you want the blocks to be indented from the sides of the content container by 10 pixels.

How will you accomplish this?

First things first. Can you accomplish this vertical three-in-a-column content block without turning the three smaller content blocks into their own additional divs/section blocks?

Let's try.

To do the indenting, we can set the padding of the main content block so that there is 10 pixels worth of inner spacing/padding on all sides.

But that just expanded the size of your content block because padding adds to the overall width of your block size according to the standard box model. If the width of your content block can be flexible, this isn't a problem. If you have a set width for your content block, you're going to need to do some math to fix this problem.

To 'fix' this problem, subtract 10 pixels from your main content block width to account for the left padding and subtract another 10 pixels to account for the right padding.

Okay, now you have the indentation problem figured out and you even readjusted the width of your main content block.

Now for that margin.

HOW are you going to specify the margins between each of the smaller content blocks?

If each content block was ONLY made up of a single paragraph or a single image, you could add a little CSS to specify their top or bottom margins.

But what if each small content block was made of up multiple paragraphs or multiple images or a combination of both?

Ahhh ha.

Maybe it's time to block each smaller content block into its own div, hmmm?

So let's do that - let's assign each smaller content block its own div - and in doing so, you can now do some simple math and specify the vertical margin space between each content block without further hassle or brain wrangling.

But did you know? In assigning each content block its own div, you have now opened up each content block to a world of additional CSS stylization possibilities!

You can now change paragraph formatting per content block, image stylizations, font stylizations, and more!

And remember earlier when you fiddled with the padding on the main content block? Remember how you had to remember to subtract the total pixels used in horizontal padding from the main content width to make sure the container stayed the same visual size?

If you use divs for your smaller content blocks, you don't have to bug around with that subtraction business anymore because now you can specify the left and right margins for the smaller content blocks.

For me, I dislike building a layout only to have to account in every single instance how padding affects my specified widths.

----------

Note: I like doing math - in fact, I like it a LOT, don't get me wrong! - but I don't like doing math when bugging around with XHTML and CSS coding and I like even less leaving it up to the browsers to do the math because invariably, different browsers do their math differently, too! ... But that's a post for another time.

----------

In my case, then, because I like to use padding as little as possible, I would definitely block out my content block's content into its own div and stylize it there and use margins instead of padding.

Yes, I would have an extra div. Maybe even two or three, depending on the nature and requirement of each separate content block.

But mathematically speaking, it makes the most sense to me.

When one says one wants a content block 500 pixels wide, one wants the block to be 500 pixels wide. Not 501 pixels. Not 510 pixels. And certainly not 520 pixels.

To preserve the box's dimensions, then, to make the size of the box stay true to the actual width and height specified (if specified) - meaning, 500 pixels is 500 pixels and not 480 pixels plus 20 pixels of padding or 500 pixels plus 20 pixels of padding making the width to be 520 pixels, formatting the content within the block by assigning it its own div is the most logical choice.

And if the contents of the block need additional stylization? The most logical choice now becomes the best choice as one div allows for a whole host of stylization options.

If I had to sum everything up, I would say this:

Sometimes, 'clean and uncluttered' and doesn't do the job.

Sometimes, a few 'extra' divs can give a layout a more solid WYSIWYG structure (less of the surprise! changes in width and height specifications due to padding issues for example, though margins can present their own problems and that's another post in itself).

Sometimes, these same divs make it easier to separate structure from structure and style from style.

And sometimes... 'clean and uncluttered' is not the best option.

Which leads me to my final thought:

The best coding is not coding that is simply just clean and uncluttered; it is coding that serves its purpose in the most efficient, effective, and logical way possible.

In other words:

Yes, CSS got rid of the need for tables which got rid of the need for the tons of tags, but a few extra divs won't hurt anyone, either, so stop being so anal about an extra div, dangit! ;)