The Lemures Files
  Guest Article: February, 1st 1999

Good Form

By: Ben Goodger

WI made a post recently to the SMZ Forum (whose posters represent a fair cross section of design competence) about degrading HTML standards, understanding, and a senatorial class of SM pages that do nothing to encourage innovation in design. The response that I got back was largely to the tune of

  • We don't take our design as seriously as you
  • People shouldn't have to understand a concept to use it.
This is complete and utter bullshit. I've noticed many SM webmasters who take their design very seriously, performing update cycles that make the frequency of updates used by this site look positively wooden. After viewing some source, and thinking it over, I've discovered that many people have lost interest in actual HTML coding.

The second point is even more repugnant. To use a good analogy from the programming world (see appendix for explanation). Imagine a small software company like Opera Software decided that since it wasn't a big fish like Netscape or Microsoft, it shouldn't take programming so seriously. Say, for instance, they decided to flout the convention of deleting memory allocated for a program once created. Their software would start sucking on your computer's memory, and it wouldn't stop, not until you shut the program off (Windows 95), or, worse still, rebooted the computer (Windows 3.1). Well hell, why should they bother going to all that trouble, they don't take their programming so seriously!

Sure, misuse of HTML and misuse of a "serious" programming language are separated but the principle remains the same. The folks at W3C (The World Wide Web Consortium http://www.w3c.org/) go to a lot of trouble to set us these nice standards that, in a perfect world, Microsoft, Netscape and all the other startups would follow to the letter. Its bad enough that Microsoft and Netscape "massage" the standard as they do why ruin it further by creating your own implementation? While I'm not against the two major browsers adding non-standard tags (many of these have been incorporated into the standard as time went on this is the way the language develops), what I'm against is the browsers' tolerance of misuse of elements.

Internet Explorer, it seems, is largely indifferent about closing certain table tags, displaying the page anyway. Netscape, boldly, does not display the table at all a commendable move. By having the page not display a badly written document, Netscape forces the page creator to fix the problem, which involves several key steps finding the bug on the page, thinking about why the problem is occurring, and thinking about how to fix it. This promotes the creation of better HTML documents. Both browsers prevent bad HTML coding to some extent forget to close a B tag and you'll end up with a page of text that's bold when it shouldn't. Fixing this is obvious for the webmaster if he or she tests their page before uploading it.

Standards of HTML writing exist for a reason, even if some browsers allow you to fudge it a bit before spitting the dummy. Both Netscape and IE will let you omit the and tags, for instance, without complaint. If you design webpages, whether you are a beginner or an advanced person, it is your responsibility to treat the language conventions with respect when creating pages. This is a skill best learned when still new to the language, as old habits are hard to break.

On the "we don't take our design as seriously as you do" argument I'll accept that for a basic page made by a beginner, or someone wanting to convey their message, complete understanding of everything on your page is not essential. I don't know everything about HTML, JavaScript or CSS, and yet I preach about it. A lot of people are the same. However (and this is the warning) you should know when you're out beyond your depth. Modifying the previous analogy (sorry Opera ^_^) we could imagine them not even knowing that not cleaning allocated memory is a sin, because they never saw fit to understand that concept. They're not as big as Netscape, why should they take the time to understand the hard parts?

Now, for the second part. If you at all consider yourself an HTML coder worth your salt, you should be taking steps to understand new technologies like CSS it will save you time, you know. I'm not saying you have to know everything I don't know everything, and yet its possible for me to create pages with a fairly high-level structure. If you are serious about your design, you'll be taking the time and initiative to learn for yourself. Most of you will have taught yourself HTML, that required initiative surely. If you are really so serious about this (not all of you are some simply want to create a place for their stories, photos etc), then you should be taking steps to further your knowledge. Don't rely on others to bring the new technologies to you on a gilded platter.

I was told today that it was not possible for everyone to get access to knowledge which is also bullshit. Almost everything I know comes from reading web-documentation online, and I've not paid a cent for it. Its free, its there, and its often only a few clicks away from sites like Alta Vista and Yahoo. People who claim its too hard to get knowledge like this are being lazy, and are therefore not as serious as they might appear to be.

Finally, a section on optional good HTML practise. Avoid these tips at your peril!

So many people have trouble with their tabled designs, attempting styles that are far too complicated for them for the purpose of looking cool. Often they'll come up with cock-eyed solutions for problems that could be easily solved with a proper understanding of HTML, and a better idea of the way that one should design a complicated document. If you're not an advanced HTML designer - that is, if you can't produce reasonably complicated table designs in your head - you need a piece of paper.

Before trying to make your table up of sliced images, 4.0-only background images and other stop-gap nonsense, try considering what the effect would be if you used an advanced table to lay out your design. Draw it on paper. When I say this, don't just draw the design of your page with its images, draw the lines where you think the table cell boundaries will go. Think about how you're going to slice the images, don't just sit there with some smartass tool like Fireworks and spray slices all over the show. Slice them so you can optimise colour (i.e.each slice contains a smaller number of colours if they are suitable for GIFing), slice them so you can optimise display speed (So that the important parts of the image load if the server connection drops the ball) *

Once you've drawn your design, look at it. You should have a number of rows and a number of cells. Some of your cells may span columns of cells, some of your cells may span rows of cells. Load your HTML editor, and start from the top down. Write the opening table tag, and begin with the first row. Remember that row-spanning cells are incorporated in the first row that they span, have no involvement in the following row code, and that the span includes the row that they begin in.

Work your way down through the table, completing rows and cells as dictated by your design. You may find using cellspans where possible is easier than rowspans. At the bottom, close your table tag, and preview it.

If it doesn't work, set BORDER=1 and look at how your cells are being distributed. Is there a "blank" cell (one that does not have any content area, e.g. the bottom cell in the following example) that indicates a missing cell, or incorrect spanning?

<TABLE>
<TR>
<TD> </TD>
<TD> </TD>
<TD ROWSPAN=2>
</TR>
<TR>
<TD> </TD>
</TR>
</TABLE>

Go back through your code and find the problem. If your code is too hard for you to understand, you've got a problem. If your code was generated by Netscape Composer, you're up shit creek without a paddle (^_^) I suggest indenting your code if you have problems following it, especially through complicated elements like tables. Indent every "contained" element (i.e. the contents of any tag) by either a space or a tab (depending on how deep you want the indentation to be smart editors like Allaire HomeSite let you specify the width of a tab).

I'll wrap this up sharply. If you get nothing out of this article but these following points, I'll be happy:

  • wizards, macros, wysiwyg editors, code-regurgintating etc are not a substitute for understanding a concept.
  • Fling around HTML recklessly at your peril you never know what a danger you might be posing. Sure HTML blunders are less lethal than those you can make with programming, but its still possible to crash people's browsers with botched HTML.
  • If you consider yourself to be a serious webdesigner, take some steps to understand what you create! It'll ultimately enable you to create better pages more quickly and easily. Trust me, I speak from experience.
* it never ceases to amaze me how many people will rush into a new trend without understanding WHY its done. I'm sure there are designers out there slicing away merrily, thinking their pages are going to be the shit because they display chunk by chunk in a gaudy little jigsaw.

Appendix: Here is a brief explanation to the background of the analogy I use in this example. I apologise if I screw this up, but as it is, its a fairly good analogy:

When programming computer applications, it is commonplace to allocate memory for use in the program using pointers to spaces on what is known as the "free store" or the "heap" This is a large block of un-allocated computer memory that programs can use if they needed it. Basically, the programs you have running (e.g. your web-browser, internet connection etc) use this when needed. If your browser needs memory to load a large image for display on the screen, or your graphics editor to perform some sort of complex operation it'll grab a chunk of this memory, and use it. After it is used, it is good programming practise to "free" this memory up again by releasing it back to the heap for use by other programs. If programmers didn't release this memory after they'd used it, there'd be a chunk of memory that would become perpetually unusable until the program was shut down (in Windows 95) or, more drastically, the computer rebooted (as necessitated by Windows 3.1). If a program chomped through a meg of your RAM like that, and didn't give it back, you'd be without that meg of RAM, and you'd be able to do less with your computer until you did one of the above.


Comments on this article can be sent to: Ben Goodger.


Comments made on this page are opinions of the author. They are not necessarily shared by Tripod and the Amazoness Quartet.


More
[top]
  Current Lemures Top || Main || Email   
© 2002 AQ