Create Well-Formulated HTML and Test - HTML 4

If you start with solid markup and good content and then work through what you’ve wrought to make sure everything works like it’s supposed to (and communicates what it ought to), you’re on your way to a great Web site. But once the construction is over, the testing begins. And only when the testing returns positive results should you open your virtual doors to the public.

Keep track of those tags
Although you’re building documents, it’s easy to forget to use closing tags, even when they’re required (for example, the </a> that closes the opening anchor tag ). When you’re testing Web pages, some browsers can compensate for your errors, leaving you with a false sense of security.

The Web is no place to depend on the kindness of strangers. Scrutinize your tags to head off possible problems from browsers that might not be quite so understanding (or lax, as the case may be).

As for the claims that some vendors of HTML authoring tools make (“You don’t even have to know any HTML!”), all we can say is, “Uh-huh, suuurre.” HTML itself is a big part of what makes Web pages work; if you understand it, you can troubleshoot with minimal fuss. Also, only you can ensure that your pages’ inner workings are correct and complete for your documents, whether you build them yourself or a program builds them for you.

We could go on ad infinitum about this, but we’ll exercise some mercy and confine our remarks to the most pertinent items:

  • Keep track of tags yourself while you write or edit HTML by hand. If you open a tag — be it an anchor, a text area, or whatever — create the closing tag for it right then and there, even if you have content to add. Most HTML editors do this for you.
  • Use a syntax checker to validate your work during the testing process. Syntax checkers are automatic tools that find missing tags or errors —and other ways to drive you crazy! Use these whether you build pages by hand or with software.
  • Obtain and use as many browsers as you can when testing pages. This not only alerts you to missing tags, but it can also reveal potential design flaws or browser dependencies (covered in the “Avoid browser dependencies” section later in this chapter). This exercise also emphasizes the importance of alternate text information. That’s why we also check our pages with Lynx (a character-only browser).
  • Always follow HTML document syntax and layout rules. Just because most browsers don’t require elements such as <html>, <head>, and <body> doesn’t mean you can omit them. It means that browsers don’t give a hoot whether you use them or not. But browsers per se are not your audience. Your users (and future browsers) may indeed care.

Although HTML isn’t exactly a programming language, it still makes sense to treat it like one. Following formats and syntax helps you avoid trouble, and careful testing and rechecking of your work ensures a high degree of quality, compliance with standards, and a relatively trouble-free Web site.

Avoid browser dependencies
When you’re building Web pages, the temptation to view the Web in terms of your favorite browser is hard to avoid. That’s why you should always remember that users view the Web in general (and your pages in particular) from many perspectives — through many different browsers.

During the design and writing phases, you’ll probably hop between HTML and a browser’s-eye view of your work. At this point in the process, you should switch from one browser to another and test your pages among several browsers (including at least one character-mode browser). This helps balance how you visualize your pages and helps keep you focused on content.

You can use public Telnet servers with Lynx (a character-mode browser) installed for free and that don’t require software installation.

During testing and maintenance, you must browse your pages from many different points of view. Work from multiple platforms; try both graphical and character-mode browsers on each page. Testing takes time but repays your investment with pages that are easy for everyone to read and follow. It also helps viewers who come at your materials from platforms other than your own and helps your pages achieve true independence from any single viewpoint. Why limit your options?

If several pages on your site use the same basic HTML, create one template for those pages. Test the template with as many browsers as you can. When you’re sure the template is browser-independent, use it to create other pages. This helps ensure that every page looks good, regardless of which browser a visitor might use, and puts you on your way to real HTML enlightenment.

Navigating your wild and woolly Web
Users who view the splendor of your site don’t want to be told you can’t get there from here. Aids to navigation are vital amenities on a quality Web site. A navigation bar is a consistent graphical place to put buttons that help users get from A to B. By judicious use of links and careful observation of what constitutes a complete screen (or screenful) of text, you can help your users minimize (or even avoid) scrolling. Text anchors make it easy to move to the previous and or next screens, as well as to the top, index, and bottom in any document. Just that easy, just that simple — or so it appears to the user.

We believe in the low scroll rule: Users should have to scroll no more than one screenful in either direction from a point of focus or entry to find a navigation aid that lets them jump (not scroll) to the next point of interest.

We don’t believe that navigation bars are mandatory or that names for controls should always be the same. But we do believe that the more control you give users over their reading, the better they like it. The longer a document gets, the more important such controls become; they work best if they occurabout every 30 lines in longer documents (or in a separate, always-visible frame if you use HTML frames).

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

HTML 4 Topics