HTML and Web Design

It occurred to me suddenly that if I wished to convert the unwashed masses [1] to hand-coding, I should attempt an argument of a little more substance than "Yay! HTML is fun!" That shall follow, but first I offer some very informative and perhaps helpful [2] links. Some of these are mostly for my own convenience (portable bookmarks, since I am currently without a personal computer), but you might also find them useful.

Rants

Hand-Coding
Validation
Cascading Style Sheets
JavaScript
Copyright

For Newbies

For Those Already Comfortable with HTML

Other Stuff

Hand-Coding

Personally, I count among the ranks of newbies those whose only contact with HTML has been through the filter of a WYSIWYG (What You See Is What You Get) editor. That means that you see what you're coding on the screen while you edit it. There's nothing really wrong with that type of editor; it's just that you can only have so much control over your code without touching it directly. It's the difference between rolling a ball with a stick and moving it by hand.

Actually that's a very good analogy, because once you put the ball where you want it, it may still roll away on its own. Similarly, the web author never has complete control over how a page is displayed. It depends on the monitor, the browser (even browser versions), the window size, the preferences of the viewer... For example, I can't get my web page (particularly the journal) to display properly in Netscape 4 - why? I don't know. It's not that the page is broken, because it validates, and other browsers (Internet Explorer and Netscape 6 are the only ones I've tried) are fine with it. Leanne occasionally asks me to change something because it displays funny in her browser, but I can't always control that. That's why it's important for web pages to be about content rather than visual effects. As goodpractices.com puts it, "make sure your design features degrade gracefully on multiple browser types." One of my objections to WYSIWYG editors is that when I was using one, I got the impression that I had more control over the appearance of my page than I actually had. There's no point to fiddling with fonts and things more than absolutely necessary, because it's likely that the product on the viewer's screen is going to be different from what you intend, no matter what you do.

A WYSIWYG editor is just a program to do what you can do yourself, more powerfully and with more precision. It basically functions like a word processor for the Web, except that it's completely unnecessary. I started out with a WYSIWYG editor myself, and not even one of the better ones; Netscape Communicator comes with a web editor, Composer, which was all right for the beginning, but I always had trouble trying to make my page look the way I wanted it to. There are other editors, such as PageMill or FrontPage. MHC supports PageMill, and I've had a brief tutorial in that, but I don't really know what it's like. I have had even less experience with M$ FrontPage, but everyone I know says it's an absolute crap program. Oh, and M$ Word thinks it's a web editor, but don't be fooled. It's not, though there is an HTML filter that can be downloaded.

My transition to hand-coding came because I had been hearing people talk about basically what I've been telling you, that you can do a lot more with direct control and knowledge. I just jumped in and cleaned up my Composer-created code, with the help of O'Reilly's HTML 4.0: the Definitive Guide (now a new edition including XHTML). [3] I redid the whole format of my page, from black background to orange; then I experimented with frames and got them working. At some point, just for fun, I tried to open my index page with Composer, and it couldn't handle the frames. It was great to know that I'd surpassed the capability of my WYSIWYG editor - not that that capability was all that great, but still...

Speaking of frames, the general trend in most websites these days is against frames. Some people really don't like frames, but personally I don't think they're that bad. I used them for a while because they fit my layout, and they served their. purpose. A main objection against frames, however, is that some browsers can't handle them; however, these days those are pretty rare, I think. Another is that it's impossible to link to a framed page in any state besides the original. This means that, for example, if I wanted to link from my journal (which was in a different set of frames from the rest of my pages) to any page besides the front index page, I couldn't. I could link to the frames, from which state the viewer could click on another link, but otherwise I'd lose the frames (which some would say is not a bad thing <g>). Then there's the problem of targeting links and opening external links in the whole window ( _top ) rather than the same frame ( _self ). Frames can be more trouble than they're worth, but in some circumstances they can be very useful.

Anyway, back on the topic of HTML editors - there are also editors for hand-coding. In general, Notepad is good enough for me, though it is annoying to have to tell it every time I save a new file that it's not .txt - HTML code is plain ASCII, but the extension makes a difference to how the browser (and server) handle the file. That's only a few mouse and key taps, though, so no big deal. I have, however, been experimenting with a couple of other editors such as Note Tab and HTML-Kit. I've also heard good things about Arachnophilia. I've got less to say about this kind of editor, which is basically a text editor with a few plug-ins and options designed specially for HTML. I don't think you can really go wrong with any of them; it just depends on what fits your style.

Validation

Another issue of web design is that of validation. When I first started creating a personal web page, I didn't worry about it at all; I was just happy if a page of mine vaguely worked. However, during the renovations of February 2001, mostly for fun, I ran my pages through a couple of validators (WDG and W3C) and mostly discovered that the pages mostly didn't validate, but sometimes they did. (A note if you're going to use either of those validators - the WDG's was fine with my pages until I named them .shtml, and then it thought I didn't have a DOCTYPE declaration and went totally haywire. The W3C was better.)

Validation is somewhat like compiling a program; it checks the code for errors such as missing parentheses and misspelled tags. However, like a programming language, the fact that a page is valid HTML doesn't mean that it'll do what you want it to. However, unlike a normal program, unvalidated HTML code can work. For example, my web page worked even though it didn't validate completely; validated code is not necessary. It is, however, nice to have. The WDG elaborates a few reasons to have valid HTML; it boils down to the fact that valid code is less likely to break in horrible ways. Also, it's nice to be able to say that my document validates, so nyer (which is not actually true, but that's another issue). Besides, I like having the buttons at the bottom of my page. <g> (I also have a "Paint Imp Pro" button on my index page, even though I've never used PaintShop in my life. I just think it's cute.)

There are also reasons not to have valid code. Not in general (there's no reason to leave out an end tag, for example), but in specific situations. For example, the first line of code for my guestbook frameset looks like this:

<frameset cols="100,*" border=0 frameborder=0 framespacing=0>

That doesn't validate, because border, frameborder, and framespacing are not attributes of HTML 4.01 Frameset. If you saw my web page earlier in the fall, it had ugly bars between the frames; those attributes get rid of the bars. Unfortunately, since the W3C hasn't defined attributes itself, Netscape and Internet Explorer have invented their own. I can't remember what belongs to whom; I think "border" is Netscape's and the other two are IE's, but don't quote me on that. Luckily, both browsers have the same strategy as me - they ignore whatever they don't understand :-) - so it works. My page didn't validate, but at this point there is no way to do what I want within the W3's definitions, so in this case I made the reasoned choice not to have valid HTML code.

Validating my pages has helped me to learn more about HTML; for example, I didn't know before about block-level and inline elements. I got errors about that on my Emily page because I had <p> tags within <i> tags, and also had tags overlapping - for example, it has to be <tagA><tagB> text</tagB></tagA> and not <tagA><tagB>text </tagA></tagB> I knew about the overlapping before, but I'd forgotten about it. As far as I know, the mistake didn't cause any problems, but it easily could have broken the page.

My pages validate now because I'm not using frames any more. I do have them on my guestbook now, just to make that page fit a little bit better into the rest of my format. It's the only way I can do it. However, everything else validates (unless I've broken anything since I last checked).

Mostly it just gives me a warm tingle of satisfaction to get that "No errors found! Congratulations, this document validates as HTML 4.01 Transitional!" when I check it. Everybody needs a bit of encouragement sometimes. :-)

Cascading Style Sheets

One extremely useful tool is CSS, which stands for cascading style sheets. Style sheets are extremely simple to understand and code but perhaps a bit tricky to implement, at least when they're new. I found them so, at least, so don't be discouraged if the going is rough at first. This page by the Web Design Group gives a good introductory explanation of what style sheets are. Technically (i.e. according to the W3C), style sheets are meant to separate presentation from content. I don't use them that way, however; for me, they are a practical tool which allows me to centralize control of elements which I use in a unified manner throughout my pages. For example, I used to use the following bit of code to govern the color and width of my horizontal separators:

<hr color="#006600" width="100%">

That works fine; however, it requires me either to remember that bit of code every time I want to put in a separator, or to copy and paste it in. With styles I can just use the following bit of code in my external style sheet to define the properties of the <hr> tag:

hr
 { width: 100%;
   color: #006600 }

That means that every time I put <hr> in one of my documents, it will automatically be colored green and span the width of the page. It's much more convenient for typing; it also means that if I ever decide that I want all my separators to be purple rather than green, I only have to change one number in order for the appearance of all my pages to be altered.

Styles can be embedded in the headers of a document or even within a tag; however, I use external style sheets for my pages. This allows me to implement the advantage I explained above, i.e. to have one unified "look" for all my pages. My style sheet is called main.css; take a look at it if you'd like (open it in Notepad). It governs the background color and image of my page, as well as text fonts, colors, sizes, alignments...

There's also a lot more that styles can do; for example, look at Kevin's page about creating buttons with styles (though do note that these look a lot better in more recent browsers). For a little while I had this kind of button for the navigation on my pages; the coolest thing about it was what I could do with it on my Emily page. The code for the button links was in an included file which I used for all of my pages; for Emily, all I did was to put the button definition in that style sheet and change the colors, and presto! Same buttons, different colors! (However, I ended up taking them off because I've done the buttons with gifs now.)

I don't use styles for every tag in my pages, or even every tag with special attributes. It's only tags which I use often enough to make it worthwhile to standardize them. It took me a little while to figure out what I could do with styles, and what was useful to do; some things just aren't worth it. I encourage you to start fiddling around with styles; figure out for yourself how they serve you best.

Btw, for an example of how not to do it, see Microsoft's CSS Gallery. Disable style sheets [4] and witness the horror.

JavaScript

JavaScript is fun. It used to be the favorite rant of OldFarts, but these days its evil has been completely superseded by that of Flash animation. Besides, if even Mike Knell has it on his website, you know it must be okay. (That said, I wouldn't make a website completely dependent upon it, because some older browsers don't handle it well, and some people turn JavaScript off.) I don't really know JavaScript yet, though, so I don't have all that much to say about it; however, I shall attempt to explain in a simple and coherent manner the ways in which I have used JavaScript on my pages. If you'd like to know more about JavaScript, you can go through the same tutorial as I or pick up a book or something.

JavaScript works a lot with things called "event handlers." They basically mean that whenever the user does something (clicks on a button, types something, moves the mouse, etc.), something else happens on the webpage. JavaScript can do a lot of different things, but there are also a lot of things that it can't do. JavaScript is client-side (as opposed to server-side), which means that it can only act on the user's computer and not on the server. Though JavaScript is used a lot with forms, it can't alter files on the server, so it can't be used for a guestbook, for example. For that you need CGI.

The first thing I did [4] with JavaScript was the image rollover for my navigation buttons. I created two sets of buttons, one green and one red, and I wanted them to change from green to red when the mouse pointer was passed over them. Here I'll show you how it's done.

There are two parts to JavaScript: the variable (and function) declarations, which are embedded in the head of the HTML document, and the event handlers and such, which belong in the body. In the head, there's first a <script> tag that encloses the JavaScript code. In addition, the code is commented out (in HTML comments <!-- -->, not JavaScript comments // or /* */ ). I define my variables in this bit; if I had any functions, they'd be here too.

  <script language="JavaScript" type="text/javascript">
<!--
var home = String("nav/home.gif");
var homeA=new Image();
 homeA.src='nav/homea.gif';
//-->
</script>

Basically this defines the variable home as the string of characters which make up the relative URL of the location of the green-colored gif. The other is slightly more complicated; the variable homeA (the "A" stands for "active" as in "active link") is declared with the Image() constructor, and its source (homeA.src) is assigned the location of the red-colored gif. The .src bit is a property of homeA and has to do with JavaScript's organizational hierarchy of elements in a web page, which I'm not going to explain here. Those two lines of code are necessary to preload the images and reduce delay when the image is to be displayed.

Then, in the body of the HTML document, the code for the image itself:

<img src="nav/home.gif" alt="[Home]"
 border=0 height=30 width=95
 onMouseOver="src=homeA.src" onMouseOut="src=home">

The first two lines are completely normal HTML attributes. The third line holds two event handlers, onMouseOver and onMouseOut. When mouse pointer passes over the image, the image source is assigned the value of homeA.src, changing the image from green to a nearly-identical red image. Then when the pointer is removed, the original image reappears.

Another fun trick is to modify the text in the status bar. Usually the status bar displays the URL of a link, but this bit of code can make it say whatever you want it to:

<a href="index.shtml"
 onMouseOver="window.status='Home'; return true;"
 onMouseOut="window.status='';">[...]</a>

Hopefully this is more or less clear; the onMouseOver and onMouseOut bits are about the same as in the previous example. The window.status bits refer to the JavaScript hierarchy; the window is the whole of the active window (including all menus, status bars, etc.), and status is the status bar. Home is the text to be displayed in the status bar. return true; prevents the browser from displaying whatever it usually displays, and the last line restores the display to blank after the mouse is removed.

I have also been blatant and evil and made a page with JavaScript, merely because I knew how to do it and wanted to play with my new toys. Look at my playing around if you'd like.

One further note: Speaking as one who was previously confused about this point, Java (programming language) != JavaScript (scripting language). JavaScript is somewhat similar in syntax, etc. to Java, but they are not the same thing.

Copyright

Copyright is a big issue on the internet. Just the fact that something is there doesn't mean that it's public domain, or that you can take it and use it. That's stealing, pure and simple. Read more about it here:

There are some things you can take. For example, if you like an effect someone else has done on their site, look at the source code and see how they did it. You're free to recreate that effect. Just don't take text, images, etc. (or huge hunks of code). If in doubt, ask permission of the webmaster; most won't refuse. It's just like the rest of the world; photocopying a page out of a book doesn't mean it belongs to you. The Internet is accessible, but right-clicking an image and saving it doesn't make it yours to use.

[1] Thanks Leanne.
[2] The W3C is one of those that's very informative but also very unhelpful if you don't already know approximately what you're doing.
[3] He bought it because he thought he needed to learn HTML. He's not yet done much with it; he has a bit of a web page, but it's nothing more than an index page linked to images for a chemistry course of his.
[4] Netscape: Edit -> Preferences -> Advanced -> Uncheck "Enable style sheets."
Internet Explorer: I don't know. If you do, tell me, because it isn't obvious.
[5] Well, Kevin and I did it. He did a good bit at the beginning, but because I didn't want to have anything on my own website that I didn't understand, and because it didn't quite work at the beginning, I ended up taking over.

This page created and maintained by Laurabelle (send WebMail).
Best viewed with Internet Explorer or Netscape 6.