Resources for Web Development Students @ Robin’s Blog

So you’re working on your first simple HTML and CSS site. You’ve got a gorgeous layout in your head and hopefully sketched out on paper and you’re ready to fire up the HTML editor. The first HTML page starts to take shape, the doctype is set and divs for the wrapper, header, sidebar, content, and footer are added to the code. The CSS file is created and you add a link to it from the HTML page. CSS declarations are written – floats, margins, padding, fonts, colors, and images are applied. You preview the page in IE 6, 7 and 8, Firefox, Safari, and Opera too and the page is beautiful AND looks EXACTLY the same in all of the browsers!

Well, it would in a perfect browser world

The truth is it probably won’t, especially when you’re first learning to code. Unfortunately, each browser interprets and displays HTML & CSS code differently. Sometimes these differences can be slight, an image may be a few pixels further to the right in Opera or a font may appear slightly smaller in Safari. Sometimes these inconsistencies can be MAJOR, you may find that entire div is positioned in the wrong place or an absolutely positioned image doesn’t even appear in Internet Explorer 6.

In addition to interpretation differences between browsers there are also numerous browser bugs that can be triggered by a simple property/value addition or even a minor change to a pixel value in the CSS. Browser bugs can cause entire layouts to break; floats can drop to the bottom of the page, containing elements with background images and/or colors can collapse around their contents, and elements may just disappear!

The browser bugs and workarounds are well documented; Great CSS Resources and Articles for Students has links to terrific resources around the Web for learning more about these issues and how to fix them. I know that all of the articles may seem overwhelming at first, but taking the time to start to learn about browser issues will save you time and headaches in the future. When you encounter a layout issue remember that Google is your friend. Searching for the browser name and version, display issue, and the word “bug” should give you a lot of resources.

Comments and CSS Code

In a perfect world, we would all have a photographic memory. I know that I don’t – I rely on bookmarks, printed articles, notes, overly highlighted books, and search engines.

When I develop or edit CSS and HTML documents I include notes or comments in my code. I use comments to set reminders or to “talk to myself” as I’m developing or as I’m troubleshooting student code. Developers frequently use comments to explain code snippets to other developers.

Comments begin with a forward slash and an asterisk /* and end with an asterisk and a forward slash */

So here is the format of a typical comment:

/* comment text goes here – comments can be single line or multiple lines */

CSS Design Notes

You may find it helpful to include design notes such as colors and fonts, and frameworks that may have been used at the top of the CSS file within a comment. It’s also helpful to include a table of contents that lists each section of code.

/* Design Notes
Author/Designer: Debb Designer

Table of contents
Wrapper – Container to set width, center page, and define background color
Header – logo and name of site
Sidebar – navigation menu
Content – content area
Footer – contact information and copyright
*/

By putting this information at the top of the CSS file you can quickly see the hex values (colors), fonts, etc. for the site instead of having to scroll through the entire CSS document.

Structural CSS Comments

As you are building the CSS file you should include simple comments about each section of code. This makes for better organization and easier editing.

/*—– Wrapper —–*/

CSS declarations

/*—— Header —– */

CSS declarations

/* —–Sidebar—– */

CSS declarations

/* —–Content—– */

CSS declarations

/* —–Footer—– */

Before you edit!

Before you make major changes to the CSS file be sure to save a backup. You can always revert to this copy if the layout breaks during editing. You can also use this copy to compare to the edited file.

Comment as you edit

Once you have the basic layout done you may need to tweak pixel values. Unfortunately, sometimes an increase of just a few pixels to a margin, padding, or width value can cause a layout to break. As you increase or decrease the original values comment the CSS.

#sidebar {
float: left;
width: 200px; /* increased sidebar width from 175px */
padding: 5px;
}

When you make a value change, preview the code in multiple browsers before you make additional changes. This makes it easy to see if the change caused a problem to the layout. If you make numerous changes to different selectors without previewing and a problem with the layout occurs it will be more difficult to trace the error. This may seem like overkill to experienced developers, but when you’re learning it’s very helpful to see how each change affects the layout of the page. Once the layout is complete you can remove these comments.

Comment instead of delete

If you think you don’t need certain CSS code snippets or you think a piece of code may be causing problems, comment the code out rather than deleting it. Once you’re done developing you can delete these comments and code snippets.

/* this code is no longer needed
.alignright {
float: right;
margin-left: 5px;
border: 1px solid #000;
}
*/

Comment CSS Workarounds

You will probably encounter some browser specific bugs and layout issues, especially in Internet Explorer 6. If a workaround is added for a specific browser issue, add a comment.

For example if you use a layout that has many floats you may encounter a “collapsed” parent element. This is common when you have a wrapper that has a background color and/or image that you want to appear behind all of the nested floats. Instead of the background wrapper expanding to surround all of the floated elements it collapses as demonstrated in the image below.

So you do some searching around the Internet and find some solutions. You decide to apply the overflow fix to #wrapper like this:

#wrapper {
width: 720px;
background-color: #4F81BD;
overflow: auto; /* fixes the collapsed wrapper */
}

Today you may remember why you added overflow: visible to the declaration, but in a few months or even days you may not. It’s a good idea to comment and workaround, fixes, and any other unusual code that may be needed.

What are you waiting for, I’m sure you have a few CSS files that need some comments.