One step back: revisiting html
April, 2000.
By Molly E. Holzschlag. (Link to original article.)
The buzz is extensibility. In client-side markup, this translates to XHTML, the extensible hypertext markup language. But the reality is that most Web developers are still coding in HTML, and probably will be doing so for some time.
Whether because they have no time to study or the difficult learning curves, most developers aren't even coding to the HTML standard, much less ready to use XHTML.
That's a problem if coders want not only to survive, but thrive in the changing world of Web markup. While XHTML inherently cleans up your code, I am convinced that going to XHTML without understanding the current HTML standards puts coders at a distinct disadvantage.
In this first of a series of two articles dedicated to HTML, I'll revisit HTML 4, talk about conventional versus standard code practices, and provide a basic overview of HTML 4's concepts.
Standards vs. conventions
Standards are formal rules that must pass rigorous examination by committee. In the case of HTML and related technologies, that committee is the World Wide Web Consortium (W3C), with which you are probably familiar.
Standards are important as they are the guidelines by which browsers, not to mention HTML authors, determine how they work. However, there is an odd shift occurring with HTML. Where once standards couldn't keep up with code changes, they've now far exceeded them.
This means HTML authors, using HTML for cross-platform, cross-browser design, must work around some of the standard issues and use conventional methods to effectively create their sites. However, just as an artist might choose to break a rule, he or she should know the rule before breaking it!
Conventions, unlike standards, aren't rules. A convention is simply a commonplace way of doing a particular task. Unlike a standard, which formalizes the rules and expected behavior of a community, a convention reflects the real-world practices of that community.
I first learned how to cook from my mother and father. Many of the dishes they prepared were derived from Old World recipes. A standard measuring spoon or cup was never a factor in the process. Instead, it was always a pinch of this, a dab of that, to taste.
When I was in college, I worked in a bakery. Baking, as I quickly learned, is very standardized. Without those standards, cakes will fall, crumble, or be rendered inedible! Measure by measure, standards were applied to baking to ensure consistent taste from cake to cake.
Working as an HTML author requires a sense of compromise. You have to know both the conventional trends as well as the standard process to make effective decisions at every turn. You need to know how to work with a pinch of this but also how to measure it up in the end.
HTML 4 concepts
In order to balance shifting trends in convention, and approach the demand for better standardization across browsers, HTML 4 emerged with some potent rules. The challenge to the developer is that these rules, in their strictest incarnation, don't always work in cross-browser/cross-platform design, and they are often not backward compatible.
To address these issues, HTML 4 has built-in accommodations for them. Interestingly, it is this flexibility within HTML 4 that is the least understood by developers—and yet it's a seminal aspect of the HTML 4 standard.
These accommodations are referred to as "interpretations" of HTML 4, and they fall into one of three types:
- Strict HTML 4.
- This is the most pure of HTML 4 interpretations. Anything deprecated (condemned) or made obsolete in this version of the language is not used, ever. The strict interpretation is also the most optimistic version of HTML 4 because many of its rules are far ahead of the stability user agents, or browsers, offer.
- Transitional, or "loose" HTML 4.
- By combining aspects of the prior version of HTML (HTML 3.2) with elements from the strict HTML 4 standard, a more realistic, useable version of the language emerges. This is where the HTML developer will find the most backward compatibility for most public and contemporary Web site designs.
- Frameset HTML 4.
- This includes all of the information within the transitional version combined with the newly adopted frame-based elements such as FRAME, FRAMESET, NOFRAMES, and IFRAME. The Frameset interpretation exists as an interpretation to confirm the standardization of frames within HTML and offer a regulated method of using them.
The standard expects that you will insert the appropriate document version and type information identifying the standard to which the document conforms. So, if you're creating a strict HTML document, the shell of the document will appear with the document version as shown here:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<title>Strict HTML Sample Shell</title>
</head>
<body>
</body>
</html>
Transitional documents will appear with the document type and structure demonstrated below:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<title>Strict HTML Sample Shell</title>
</head>
<body>
</body>
</html>
Finally, any page you build with frames in HTML 4 should be denoted as being within the Frameset interpretation. Frameset documents will contain the Frameset version information, as follows:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
"http://www.w3.org/TR/REC-html40/frameset.dtd">
Along with these interpretations, there are three primary concepts that HTML 4 encourages authors to adopt. These concepts exist to ameliorate problems and concerns with the language's past (and often current) use:
- Separate document structure from presentation and style. Much of HTML 4 is focused on taking any element from prior language versions used for presentation or style of information and setting it aside. In its favor, style sheets for presentation and design are typically recommended.
- Think carefully about access. Because HTML was originally built for all people to access documents, including those on a variety of platforms, using different user agents, and with a special concern for those having physical impairments, the standard asks that we use forethought when authoring code.
- Make documents load more quickly via careful table design. HTML 4 has several element additions that help tables render incrementally. In fact, HTML 4 highly encourages developers to move away from using tables for an underlying grid system, implementing the use of style sheet positioning in its place. Of course, choosing to use style positioning over table grid systems is very difficult to achieve. Style sheet positioning is highly unstable and unreliable, and there's no backward compatibility built in.
- As you can see, knowing what a standard's goals are enables you to work logically within the standard, but making your own decisions along the way. While you may have to turn away from strict HTML 4, you can code to the transitional standard with a little preparation and foresight
Next time: getting syntactical
Get these fundamental concepts down, and you're well on your way to stabilizing your code practices and preparing for the future as well. Next week, I'll delve into HTML 4's syntax. We'll cover what's new, what's deprecated, and what's been stricken from the HTML record.
