=========================================================================== Today on The World Vol. 4 #151 Wednesday, June 10, 1998 =========================================================================== Continuing the HTML tutorial series... this section discusses general topics regarding making "good" HTML. At this point you know all you need to make Web pages with styled text, pictures, colors, and links. In the future you'll read about "advanced" topics such as tables and frames and stuff, but for now you know the nuts & bolts. So it's time to take a break and talk about tuning up any pages you've started building with what you know. (And if you haven't started on your own Web site yet, go ahead and do so!) --------------------------------------------------------------------------- HTML TUTORIAL -- CHAPTER 6 -- TIPS & TOOLS 6.1 View Source! Most of us learn HTML tricks by finding interesting Web pages and using the "View Source" command in our Web browser (it may be a button or a drop menu item, or you can just save the page's source to disk and view it in your text editor.) But keep in mind that if you copy anyone else's code you're copying their mistakes (and if you don't believe me that other people's Web pages aren't coded as well as they could be, try running their pages through a validator -- see next topic.) 6.2 Validate! A validation program is a tool that checks your HTML for what it thinks are mistakes (common slip-ups, unknown [misspelled] tags, deviations from the W3C standard, etc.) These are very useful tools (I can't stress this enough) for making sure you didn't do something silly like spell or forget a vital . Some of them will even check for dead links (when you set up a page of links you'll discover how rapidly other people's pages appear and disappear.) No one validator checks for every possible mistake, and they often differ in their philosophy (some are overly lax, some are overly strict, at least according to my taste) so I feel it's best to try as many as possible (many are free) before deciding which one or two or three to run on all your new pages. My personal favorite is the one built into BBEdit, a text editor for Mac OS (it costs about $100), and some other professional editors have validators as well. (Even if your program doesn't have one, a good editor with syntax coloring [tags are blue, links are red, or whatever] and automatic indenting can help you a lot.) You can find links to a lot of different validators at http://www.cre.canon.co.uk/~neilb/weblint/validation.html Many of those are free ones which operate over the Web (you fill out a form and it visits your Web site to look at your pages). Others are shareware or commercially-available programs you install on your own computer. One of the free ones is the W3C's own checker: http://validator.w3.org However, the results of this one can be hard to understand, and because it actually follows the W3C spec (which people like Netscape and Microsoft deviate from all over the place by making up their own tags) it may complain about every single thing on your page. One I particularly like is Bobby: http://www.cast.org/bobby/ Bobby was designed to check your Web pages for accessibility for people with special needs, and thus is a good way to ensure that your pages work with exotic browsers (such as ones that read the page aloud for the blind.) It can check for compatibility with particular versions of specific Web browsers, too. (I recommend using the "Advanced Options" to get "Text-Only" output, or else it'll display a copy of your page with cryptic little symbols all over it; the text-only report is very clear.) Remember that validators can't read your mind to figure out what you meant to do when something's wrong. They can only flag the line of HTML where they got confused. For instance, if I said

I Like Potatoes

Potatoes are your friend.

You might get a message like "Line 2:

is not allowed within

" when what is really wrong is on Line 1: your

is missing. So if you see a strange error, chances are the problem is either on that line or else you forgot to turn off something above it. It's very important to validate because some browsers (Netscape's in particular) are lax about enforcing W3C standards. These browsers will do their best to make your code "work" no matter how scrambled it is. That's great for the people using those browsers, but for the people who use browsers which display what you actually wrote, bugs and all, if you only test your code with a lax browser then other people may see a defective page. Which brings us to... 6.3 Test! Check your page with EVERY BROWSER YOU CAN. This means running not just Netscape Navigator and Internet Explorer on your computer, but if you can stand it, run older and newer versions. Make the window wider and narrower. Quit your browser and switch from 256 color mode to millions of colors (or vice versa) and test again. Be sure to try both the Windows and Mac versions of the same browsers (yes, they have different bugs and quirks) if you can (every version of every browser for every operating system is a little different.) If you can, use "minimalist" browsers such as Mosaic 1.0 or older versions of AOL or lynx to see what your pages will look like when viewed in such restricted environments. If your pages have features that will not work in those cases, you'll need to provide alternatives (text links below the image map; alt text for all the images; a "no-frames" version). You cannot just say "You have to buy a Macintosh, install Netscape Navigator 4.04a, enable JavaScript, and upgrade your graphics card 1600x1200 to look at my page." People will simply visit your site, see a broken-looking page in their favorite browser, and go away. Well-designed Web pages should be viewable by people who have arbitrary browsers and setups. (Obviously if you need to use a bleeding-edge technology like a Java applet there's no way a person with, say, a WebTV, will be able to see it, but the goal is to not restrict what kinds of browser can view your site unless you have a good reason. "Plain" pages -- text, pictures, links -- should be viewable under the widest variety of circumstances.) 6.4 Indent! If all else fails and you can't figure out why your page is coming out askew in Browser X but not Browser Y, you probably have some subtle error in your HTML such as improperly nested tags (or are missing something like to turn something off.) Try rearranging your code so that every tag is on a separate line, then indent a few spaces for each nested item:

Hello, World!

...just isn't as clear as:

Hello, World!

...because in the latter example you can read downwards and see that

doesn't line up with

so you know something's mis-matched. Some text editors can automatically format your document this way (as well as doing the reverse -- stripping out all the extra spaces to make the page download faster.) When in doubt, remember: Most HTML tags come in pairs, except for a few (,
,
among them). 6.5 Text blocks! My philosophy regarding text: Paragraphs and other chunks of text should be in some sort of container (

...

,

...

, 
...
, ...
,
    ...
, etc.) No text should be floating around "loose" outside of those, and those text containers are mutually exclusive: Don't put

inside

...

. Don't put 
 inside 
...
.

A few things DO go outside the text containers:  
 if you want
a gap, 
, 
, etc.  But all the visible text (and
the tags that "style" it, such as , , , etc.) go inside
the text containers.

(We'll cover 
     and 
 in future installments.)



6.6  Too Wide!


How large can you make something and have it fit in someone else's
window?  You don't know.  Their monitor might display 640x480 or
1600x1200, and you have no way to tell from your end, and furthermore,
they can make the window wider or narrower at will.  (Also their
browser will probably need to reserve some space at the edges for
the scroll bars, menus, and icons, making the exact amount of space
available even harder to estimate.)

A good rule of thumb is that you should keep your images (or tables)
under 540 pixels wide if possible.  Why?

1.)  When printing a Web page, and the images are considered 72
     pixels per inch, you only have about 7.5 inches (540 pixels)
     between the margins on U.S. paper.  (It's about 520 pixels
     for the rest of the world, by the way.)

2.)  640x480 is the smallest screen size available on any modern
     computer (old EGA IBM PCs and early nine-inch Macs excepted,
     but we'll ignore those 'cause they're unlikely to be on the
     net these days) and yes, people do choose to use 640x480
     (because they like large print.)  Or some people's computers
     came set for 640x480 and they've never learned how to change it.
     Or they have an old monitor that only does 640x480.  In any
     case, the largest size you can guarantee that any modern
     computer will display is 640 pixels across (minus a bunch for
     the stuff on the sides of the window.)  Note that some versions
     of Netscape Navigator default to 480-pixel-wide windows
     on 640x480 screens.

3.)  WebTVs, which after usually used with TV sets, are limited to
     544 pixels across.  And they cannot scroll horizontally, only
     vertically.

So pick a number (I like 520, myself) based on how many people you
want to be able to see your page.  (My 520 makes my pages go off
the edges of things like 240x320 handheld PDAs, but you gotta draw
the line somewhere.)

If you don't have any gigantic images, and if you don't specify
any width in particular for s (we haven't learned them yet)
your page will look fine in any window width on any screen size.

(If your 
s break between the wrong words at various widths,
the only good solution is to use   [non-breaking space]
between the words you want to stick together.  We'll learn more
about   in a few installments.)


    
The World is my favorite Internet Service.




6.7  House Style!


It helps, early on, to get into certain habits to help you
produce code that easier to work with later (or is better code
to begin with.)  Here are some elements of my "house style",
which you may choose to adopt or ignore as you wish:

a)  All HTML tags are in capitals to make them stand out.

b)  All tag options are in quotes (COLOR="#FFFFFF") because
    once in a blue moon that's required.

c)  All filenames are entirely lowercase and contain no spaces.
    All have a meaningful "file type extension": ".html",
    ".txt", ".gif", ".jpg", etc.

d)  All images have WIDTH and HEIGHT attributes for faster,
    cleaner page loading.

e)  Make notes to yourself with HTML comments in your code!
    



6.8  Don't Do This!


You see this in quite a few HTML files (particularly in Usenet
spam) made by people who have a visual HTML editor (PageMill, etc.)
and don't bother to double-check the HTML that comes out of it:


    


That's a link referring to a file on the "C:" hard drive, and
IT WILL NOT WORK ON ANY CIRCUMSTANCES for anyone but you because
"C:" or "D:" or "Macintosh Hard Drive:" or whatever the name of
your hard drive is cannot be reached over the Internet (at least
with a Web browser under normal circumstances) and if it could
it would have to have a more unique name to "C:".  Links to "C:",
"D:", etc. may preview just fine for you, but I guarantee that
when someone else tries to click on those links they won't have
the necessary file on their "C:".

(That bad example is one of several C: or D: links I saw today.)

If you let a tool such as PageMill "write" your HTML for you,
you should still read through the HTML (as well as testing the
site with various browsers on different computers.)  In general
you should have no need of any "file:" URLs (which refer to
local files);  you should change them to "http:" and put in the
proper URL of your Web page or image.



6.9  Reference materials


General HTML help:


NCSA's Beginner's Guide To URLs:

    http://www.ncsa.uiuc.edu/demoweb/url-primer.html

NCSA's HTML tutorial:

    http://www.ncsa.uiuc.edu/General/Internet/WWW/HTMLPrimer.html

Not the most clearly written (because it's fairly short), but it goes
into more detail about the basic structure of HTML (and less into the
visual stylings) than I do.  I VERY STRONGLY RECOMMENDED READING THIS.
It can be viewed on-line (in HTML form) or downloaded as a single PDF
for printing.

HTML Reference Manual:

    http://www.sandia.gov/sci_compute/html_ref.html

particularly

    http://www.sandia.gov/sci_compute/elements.html

tells you what every tag does and what its options are.  (This document
was last revised in 1995, but it's still very useful.)


Official HTML specification:

    http://www.w3.org/MarkUp/MarkUp.html

The most recent version above (HTML 4.0, December 1997) is 363 pages of
dense reading, but you can't get any more official than W3C's
specifications.  The older HTML 3.2 specification (January 1997)
is more widely implemented by browsers:

    http://www.w3.org/TR/REC-html32

(I like to follow HTML 3.2's specifications;  it covers everything
that the 3.0 or later versions of the Netscape and Microsoft browsers do.)

And the HTML 2.0 specification (November 1995) at 78 pages is the most
basic and compatible of all:

    http://www.w3.org/MarkUp/html-spec/

(If you want to read these, start with the 2.0 version and work your way
up to the newest one.  Not only will the 2.0 version leave out the weird
new stuff, it's so much shorter.)


WebReference:

    http://www.webreference.com

Various materials on building and maintaining sites.


Top Ten Mistakes In Web Design:

    http://www.useit.com/alertbox/9605.html

I agree with nine of these.  (I like blinking GIFs.)


Creating Killer Web Sites

    http://www.killersites.com

The Web site that goes with David Siegel's popular book, which concentrates
mostly on the visual aspects of Web design (you shouldn't worry about that
until you've mastered the fundamentals: do my tutorial and NCSA's first,
then read Creating Killer Web Sites.)  You may know Mr. Siegel best as the
designer of the Tekton typeface.


For picking colors:

ColorCenter:

    http://www.hidaho.com/colorcenter/

(requires JavaScript)


ColorServe:

    http://www-students.biola.edu/~brian/csapplet.html

(requires Java)


WebColor:

    http://hyperarchive.lcs.mit.edu/cgi-bin/NewSearch?key=webcolor

(Macintosh shareware)



For customers of The World:

    http://world.std.com/help/web/index.shtml

That includes a lot of stuff, notably:

    http://world.std.com/help/web/hpa-tutorial.shtml

(Home Page Alone walkthrough)

    http://world.std.com/help/web/icons/index.shtml

(icon library)

    http://world.std.com/help/web/colortable-small.shtml

(color chart)

    http://world.std.com/~wexample

(some tools for advanced users, such as page counters and forms)


Before you ask, ".shtml" in some of those is like ".html" only it lets us
do things such as including the date of last revision on the pages.
These "Server-Side Includes" are not available to HPA customers,
only to Kiosk customers.  You can read more about them at

    http://www.std.com/Newbury/TheWorld/help/ssi_help.html

Server-Side Include help for Kiosk customers.


(kibo)

==========================================================================
[] Send suggestions for tips & URLs to today@world.std.com.
   We're also collecting links for our Web pages at eyeguy@world.std.com.
[] To contact CUSTOMER SUPPORT, send mail to support@world.std.com or
   call 617-739-0202.  
[] To subscribe to the "Today" mailing list, send a note saying 'subscribe
   announcements' to majordomo@world.std.com.
   Subscriptions to this mailing list are open to World customers only.
[] Darn it, I'm gonna buy that digital camera this weekend or explode.
[] Today on The World is (C) Copyright 1998 by Software Tool & Die.
   Its contents may freely be redistributed as long as credit is given.