Page 1 of 3 This article is meant for the coder who is becoming comfortable with tableless design, but must deal with other members of a site design team, or a client, who doesn't grasp CSS as well as you do. Suddenly your well-working CSS layouts are getting folded, spindled, and yes, even mutilated! The horror! If you are unprepared, a long slow train of "difficulties" may await you. We've been there, done that, and we are going to tell you all the little things that we learned the hard way.
No deep specifics will be discussed; this series is an overview of the issues, along with tips and methods based on our personal experiences in this area. Remember that what follows is just opinion, not hard and fast laws that must be followed, or even agreed with. We offer such advice in the hope that others may possibly benefit from it, and detour around some of the nastier things that might happen.
We begin with issues involving source code, including tag problems, code formatting, and more.
We know, you have heard this before, but it bears repeating. It is amazing how often a simple visit to the HTML and CSS validators can find code typos that might easily waste lots of time and money. Sure, validation won't catch everything by a long shot, but it's quick and free, and can mean the difference between being a hero and a goat. Just do it, early and often.
One of the big problems inherent in CSS layouts involves the presence of many "structural" DIVs, used to contain and visually arrange groups of content. The DIVs themselves are not the problem, but their closing or "end" tags definitely can be.
The fact is, all DIV end tags look exactly alike. The DIV start tags will usually have class and/or ID attributes that identify them individually, but those pesky end tags tend to blend together, especially if you've nested them a few times. It is all too easy for you or your client to lose or add DIV end tags accidentally while directly editing the code or preparing dynamic templates. Unfortunately, each DIV end tag is critical to most layouts, so much so that the addition, subtraction, or misplacement of a single DIV end tag will often totally destroy a CSS layout.
Usually the visual result is so bizarre that an inexperienced CSSer won't have a clue what's wrong, and might flail around amongst the CSS rules in a futile search for the cause of the problem, never even thinking of checking the source. This is particularly true of clients who take a working CSS layout and try to break it up into includes for dynamic serving. The DIV end tags sometimes come in groups, and if their number is somehow changed, that incorrect end tag count may be less than obvious to the casual code reading eye.
There are two ways to try avoiding the problem: labeling and indenting.
Labeling consists of adding an HTML comment before or after an end tag, and using the comment to explain what element is being ended. See below for a typical example of a structural DIV. (The label is highlighted.)
<div class="wrapper">
(content in the wrapper...)
</div><!-- end .wrapper -->
Code Block 1
This method definitely identifies an end tag with its matching start tag (assuming you don't forget to add the labeling comment), and mistakes involving end tags are far less likely when such labels are used. However, labels do clutter the source a bit, so some coders dislike the labeling method. In addition, source comments may, under certain semi-rare conditions, cause a bug in IE6 that is quite difficult to defeat or even to understand. You can learn about this Duplicate Character bug in Common Coding Problems - Part Four.
On the other hand, indenting blocks of code inward from the left margin is a time tested method of visually delineating various elements and code groups, and it's no wonder. Indenting is very obvious to the eye, much more so than labeling.
Indenting does have its own drawbacks though. One drawback is that multiple indenting may sometimes become confusing, and the confusion greatly increases if the indent formatting is not rigidly maintained. When more than one coder is dealing with the source, or if a dynamic template is employed, indenting can be quickly lost or even become badly scrambled. Such confusion obviously defeats the purpose of indenting in the first place.
Another indenting problem is that excessively nested indenting can extend some of the code a long way to the right, making visual code scanning more difficult for everyone. In some cases, all that is necessary to overcome this problem is to shorten the length of the lines so they stay in view. Unfortunately it may not always be possible (or desirable) to shorten code lines. This issue leads directly to the next tip.
A major headache of coders everywhere is code that must be horizontally scrolled to be read. Clients are particularly sensitive to this, not having had a lot of experience in side-scroll reading. Scripts sometimes require long unbroken code lines to work properly, but HTML and CSS can almost always be made less wide than a typical code-reading window.
One possible exception is when you must keep code all on one line in order to eliminate display irregularities, typically in IE/Win browsers. Another is when PRE formatting is used, and the content in the PRE styled element needs to be very wide for some reason.
A good length to aim for is about 80 to 100 characters per line, but that's only a suggestion. Each coder will have a favorite line length, so experiment with lengths until you find out what you like.
Dreamweaver will automatically limit most lines to a pre-selected character count, but when coding in a simple text editor such as Notepad, code lines tend to become longer and longer. It may not be easy to maintain proper line lengths when deep into a code project, but it's certainly something you can learn to do without too much trouble.
Some text editors, such as HTML-kit and Notepad2, have an optional vertical line or background color change that you can set, visually cueing you when to start a new line, which is a great help. If you do not maximize a text editor's display size, and instead set it's width to just about the line length you want, it's also pretty easy to get used to manually wrapping lines when they get near the edge of the editor's visual display.
Enforcing a maximum code line length not only keeps clients happy, but also lets you deal with your code more easily, since nothing is hidden off to the side except possibly as described above.
Keywords
CSS, HTML, tableless design, clients, co-workers, layouts, missing tags, label source code, end tags, indenting code, side-scrolling code, source code line length, style sheet organization, inline, embedded, remote, external, formatting rule sets, missing semicolon, missing bracket, extra bracket
