Intermediate HTML-Big Picture

blue fractal Intermediate HTML blue fractal

The Big Picture

line of stars

Go to Writing for all browsers Etiquette and Ethics

Proper HTML

HTML that works may not be "good" HTML. This is true because what works in one browser may not in another, or in another version of the same one. This is a difficult concept to grasp, especially if all you ever see is Explorer. And if you plan only to construct a page or two for limited personal use, it's probably not too important that you try. But if you get into this new kind of publishing in a big way, hoping your pages will become famous throughout Web-land, you should at least be aware of what is and isn't proper.

To have your coding checked out for propriety, you can have your pages validated. Validation generally means checking for compliance with HTML standards. There are several of these validation programs available, and some editors also automatically do some validation. Links to the separate validators abound at the Web Design sites on my personal web page, some of which are included in the General Resources section of the Good and Cited Sites list on the Intermediate HTML main page. Specificially, Alan Richmond has a very good article on validation (with links) in the Web Developer's Virtual Library.

A few general hints might be all you want or need to know on this subject, though. For one thing, try to use tags that convey the meaning of what you are trying to convey, rather that just the appearance. This is where the argument between <em> and <i> (and <strong> and <b>) comes in. The two types of tags are called either logical/structural or physical/presentation. All the web experts I've read on this subject prefer the first kind of tags over the second. <i> and <b>—physical/presentation tags—specify specific fonts, whereas <em> and <strong>—logical/structural—let the browser decide how to display the marked text. If an italic or bold font is not available, it may be programmed to do something else to the text, like change its color. Or if the browser is one that "reads" the content (as in a device for the visually impaired, or for people driving their cars) a description of how the text looks wouldn't be relevant; but the meaning of emphasis can be conveyed by the "voice" of the reader.

That said, however, it seems that simple tags like these display just fine in the major browsers. And if you look at the code for my pages, I have always used <b>, and divide my time about evenly between <em> and <i>.  And the HTML police haven't been kicking in my door. But I feel that I would be remiss on a page such as this if I didn't at least mention this issue. Certainly, when you're typing "raw" HTML, <b> comes out a lot faster than <strong>, and it's perfectly ok to use it. But if your editor puts in the latter, at least now you'll know what it means.

XHMTL, the current standard, requires some other, minor, differences from older HTML standards. The most important are:

line of stars

Writing for all Browsers

It is very important (if you want the largest number of readers to be able to access your pages) that you keep in mind the basic fact of Web authoring—PAGES LOOK DIFFERENT IN DIFFERENT BROWSERS AND ON DIFFERENT MACHINES! Don't become so emotionally attached to your page layout that sight of it in a browser with a default font different than yours (or on a screen smaller than yours) will cause palpitations. It is ok, certainly, to be that attached to your content, but this is a different thing altogether. Working with the Web for any length of time will either teach you this lesson, or you will quit working with the Web.

In addition to keeping this basic idea in mind always, here are some more specific thoughts to ponder:

Some computer users, due to cost and other considerations, use text-only browsers. By definition, they can't see your images, of course. (See the Illustration section of this guide for more detail about helping text readers with your images.) Text browsers may also have trouble with tables, so be careful about using tables for layout. Older versions of some browsers didn't display tables at all. The newer incarnations can display them, but they might not be lined up just right. Frames, understandably, cause text browsers a lot of difficulty as well.

But writing with text-only browsers in mind not only means you are looking out for those unable to afford color monitors. It also means that people who turn off the images in their browsers to speed up page loading will not be able to access your content, either. Not to mention those ahead-of-the-curve types with reader-software installed on their laptop so that they can "listen" to the Web as they drive. People with different kinds of disabilities, too, require special programs (such as text-to-speech) that may work better in a text-only mode. You can find more information on writing for text browsers in this article: Text-friendly authoring topics, by Alan J. Flavell.

Even users with the same version of the same browser may see very different versions of your pages. Some people use laptops with small screens, setting their default fonts small so they don't have to scroll so much. If you specify an even smaller font, your words may very well be illegible to these readers. Conversely, folks with vision problems might very well set their default font rather large—when you make it display even larger, they may be down to a few words per screen. Colors can also cause unexpected problems. Users with color-blindness or perhaps just different color preferences may set their default background color to something you would consider odd. Using different colored fonts on your pages might make text unreadable on some backgrounds.

Don't forget, too, that users can resize their browser windows if they like, scrunching up or spreading out your carefully calibrated design.

All of the foregoing is not to say that you shouldn't design pages that are aesthetically pleasing to you. Have a few pages in your directory that are fun to make and look at, too, as places to try out wild ideas and display weird colors and graphics. But when you're trying to convey information to others, try to keep in mind at least an idea of the variety of circumstances under which your pages might be seen. Try to make sure they're understandable as well as visible in as many different environments as you can.

You can find more information at the AnyBrowser Pages, and some good general points on accessibility are discussed in the Web Design Group's Accessibility. The Center for Applied Special Technology offers Bobby, which will check your pages for their accessibility to people with disabilities.

If this all sounds like being a good Web citizen, well, that's what it is. As well as another segue to my last big picture area, where I'm putting thoughts that didn't seem to fit anywhere else.

line of stars

Etiquette and Ethics

Most of the following is really just basic common sense, but you do have to develop a "big picture" attitude toward the Web to see it that way.

Give credit where credit is due.
"Borrowing" graphics, code, layout ideas from other Web pages is an accepted emergent "tradition" of the medium. But, out of courtesy as well as honesty, and also in the spirit of helping others find "good stuff," credit your borrowings whenever possible.
Make sure your readers know where they are and who you are.
I'm sure you've been to pages on the Web that looked great, but you were reluctant to cite or recommend them because you had no idea who had put them up. Don't let that happen to your readers. If you don't put some kind of identifying footer on each page (you might want to include a copyright notice—use &copy; to make this sign: ©), you should put a link on every page back to some main page from which a reader can tell who you are and where they are. You should also have a way for readers to contact you (maybe a mailto link) somewhere in your pages.
And when you are.
Do all your readers, especially your repeat "customers," a favor and include a "last updated" date on your pages. Many kinds of content, in addition to the obvious like schedules, is time-sensitive to some degree. Web pages should be dated just as books and journal articles are. You might even want to put a pair of dates on each page: a "created" date (so that you get credit for having had the page for such a long time) and an "updated" date. If you have trouble remembering to add dates to pages, like I do, you might want to use this nifty JavaScript. It will automatically change the date when the page is updated.
Make sure your pages can stand on their own, or at least are usable out of context.
You never know how readers are going to come to your pages. They might very well not come through the "front door." The links mentioned above are a good idea. Don't just rely on your readers' "Back" button. If they came to a subsidiary page first, pushing "Back" will never get them to your main page. You might even want to avoid such wording as "on the previous page..." since they may not visit your pages in the order you intended. (An exception to this rule, of course, is if you use HTML to construct visuals for a talk; the value to you of HTML for this purpose, I think, outweighs the few readers who might be confused coming into your "slide show" in the middle.)
Design your pages so that higher-level HTML features degrade gracefully when viewed in older browsers.
This sometimes takes a bit of doing. If you construct an elaborate color scheme based on Cascading Style Sheets for example (curious about CSS? check out the General Resources section of my Good and Cited Sites) be sure that your pages aren't dependent upon this scheme to make your organization understandable. Anyone with Netscape 3 or below won't see the CSS ornamentation. To some extent, this can also be a problem with images and tables (for older non-text browsers). Don't put the only navigation links on your page inside a graphic!
Test your pages on other browsers and other computers.
Better yet, let other people test them on other machines and with other browsers. What seems like crystal clear organization to you might not be so easy to follow for someone not as familiar with your subject. In fact, usability testing should be a major, ongoing part of the maintenance of any web site. There is good information on usability issues at usability.gov.
Does the fact that some users have old computers mean that I can't ever use the coolest new techniques on my pages?
Not necessarily, if the techniques are truly needed to help your pages accomplish their goals, and not just to show off the latest whizz-bang fads. What I hope you will take from this discussion is an awareness of the potential problems associated with some of these features, and a recognition of the importance of communicating with readers using all types of hardware and software. When you are aware of both the problems and the benefits of the techniques, then you can make an informed decision about how and when to use them. You can reasonably assess the tradeoffs you will have to make between accessiblity and nifty stylistic features, when you're familiar with what's at stake for your readers.

BE A GOOD WEB CITIZEN !

line of stars

IMPORTANT NOTE: All of the instructions in this and my other tutorials apply to authoring for the Web at present (mid-2007) and will continue to be useful into the future. But to be sure you are using the latest standards, especially as we get further from 2007, you can always check with the good folks at W3Schools.

line of stars