June 6, 2008
The importance of error-free HTML
Recently I had to work on a couple of stores with seemingly weird problems. In one store, on some pages layout was all over the place, and in the other, nothing showed up on the page except the store header. In both of these cases the culprit turned out to be buggy HTML. Since this wasn't the first time I encountered problems like this, I decided to write these notes so that you can avoid these mistakes.
When I looked at the first problem store, the page looked ok up to the bottom of the caption, but after that the navigation parts and footer were all messed up, misaligned and broken. Since most other pages were Ok, I suspected that the problem was not on the template level, but somewhere in the HTML entered by the store operator. So I edited the page and looked in the "Caption" field. Sure enough, they copied and pasted some table-based HTML layout, which, as it turned out, they created in DreamWeaver. I new something was amiss when I saw that their caption started with <td>. A <td> tag can never appear by itself, without an opening <table> and <tr> tag. Throwing extra or not enough of these tags around will without a doubt break any layout, especially table-based ones. To me the easiest way to fix something like that is to copy that HTML and paste it into Microsoft FrontPage. Now, say what you want, I do like FrontPage for a number of reasons, one of which is that if you paste any HTML into its "HTML View", then switch to "Design View" and then back to "HTML View", FrontPage will not only arrange and indent the HTML so that it's easy to follow, it will also fix up the HTML by adding missing opening or closing tags. While it doesn't always get it 100% right, a piece of HTML fixed up that way is a lot easier to correct than trying to hunt down the errors yourself. By the way, I use FrontPage 2000; newer versions don't seem to have this code-fixing / reformatting "feature", not sure why.
The second store, as I said, showed nothing after the beginning of the left navigation bar, but only in Internet Explorer. It was fine in Firefox. This happens if the code includes a <style>, <script>, or <!– tag without their closing counterparts. While Firefox is smart enough to implicitly close these when it encounters other valid HTML tags, Internet Explorer will simply treat the rest of the page as part of the style, script or comment block, essentially hiding the rest of the page completely. In most cases, I work in Firefox and only switch over to other browsers to test, so I got into the habit of always writing the opening and closing tags of these "problem" tags before I write anything else. For example, if I want to include a <style> block, I always write:
<style>
<!–
//–>
</style>
first, then go back and fill out the inside of that block. That way I won't accidentally forget the closing tag.
