Dan's Web Tips:

Physical vs. Logical Markup

See also Croatian, French, Marathi, Norwegian, Romanian, Sindhi, Spanish, Ukrainian, and Urdu (via Mobile Mall) translations (done by others in their own sites)

TIP: Know the difference between physical (visual) HTML tags and logical (structural) ones, and when to use one or the other.

There are two basic types of HTML tags. The logical tags represent the structure and meaning of a document, with only suggested renderings for their appearance which may or may not be followed by various browsers under various system configurations. The physical tags represent specific visual effects which are intended to be reproduced in a precise manner, and carry no connotation as to their semantic meaning.

The original implementation of HTML contained almost entirely logical tags, in accordance with the HTML philosophy that it was a structural language rather than a screen-layout description. A few physical tags slipped in even back then (such as <B> for boldfaced text). As HTML was augmented by browser-makers Netscape and Microsoft, a large number of physical tags were added, with very little augmentation of the logical tag set. The HTML 4.0 standard, and now the HTML 5.0 under development, attempts to remedy this balance by introducing some new logical tags and declaring some of the physical tags and attributes as "deprecated" in favor of stylesheets.

HTML style advisors have given varied and conflicting advice about whether to prefer the use of logical or physical tags. Hard-line purists may say to use only logical tags at all times, while some graphical designers advocate using only physical tags (because the logical ones have the tendency, distressing to those of a visual mindset, to be rendered in widely varying ways). I don't follow either rigid standard; rather, I support using whichever tags make sense for the particular application. Nowadays, these sorts of conflicts don't break out nearly as much, since many of the newer generation of developers, whether logically- or graphically-oriented, has learned to use Cascading Stylesheets to keep the HTML clean and simple, and the presentation separated in the stylesheet.

When to Use Logical Markup

Try to use the logical constructs whenever they fit the meaning you're trying to convey. When you want a header at the top of a page, the <H1> tag is a good choice. The alternative of using a physical <FONT SIZE="+3"> tag has the negative effect of not logically connoting a header; any program that attempts to create a structural outline of your document from its headers will be frustrated when you don't mark them as such. A text-mode browser like Lynx, and a reader program for the blind, may have a manner of its own to signal a header to the user, and this will be inoperative on your document when you signal that with a font change that's meaningless on these other devices.

There are a number of logical tags that have specific meanings that may be useful to you. <CITE> is used to surround the title of a work being cited (usually rendered in italics). <EM> designates emphasized text, and <STRONG> designates strong emphasis, usually rendered in italics and bold respectively. The advantage of using the logical rather than the physical tags in these cases is that your meaning is more precisely conveyed. The fact that the mass-market browsers don't actually do anything with these distinctions at the moment is no reason to let them slide; other software can still take advantage of them when indexing or abstracting your documents. Not to mention stylesheets: A site full of hard-coded physical markup will be much harder to convert to stylesheet use than a site with a clean, simple logical structure.

If you get out of the graphical-artist mentality that demands pixel-perfect control of your site's rendering, you'll be able to convey your site's meaning in a sensible, platform-independent way. Try not to defeat the logic of HTML by avoiding the logical tags just because you don't like what some of them look like on some browsers. For instance, some designers don't like how paragraphs are rendered, so they use a line-break followed by an empty graphic to indent the next line. This sort of thing is not generally a good idea, as it's likely to degrade poorly under different environments (e.g., text-only browsing) and obscure the structure of your document for indexing robots. Learn how to use stylesheets, and you can define the look of the logical elements of your pages in a much more flexible way than you ever could with physical markup.

When To Use Physical Markup

When you want to achieve particular visual effects that don't fit into the structural meanings of the various logical tags, then the physical tags are a better way to do it than the abuse of logical tags for meanings not intended. Thus, if you decide to boldface all your body text just because it looks better to you that way, use the <B> tag instead of the <STRONG> tag since "strong emphasis" isn't the semantic connotation here. The appearance in the mass-market browsers will be the same, but perhaps you've saved a blind person using an audio browser from hearing your whole document in a loud tone of voice (an appropriate rendering for strong emphasis, but not an appropriate rendering for the purely visual effect of boldfacing). If you want all your text in a larger font, use <FONT SIZE="+1"> instead of <H4>, since you don't mean to imply that all your text is actually a "header".

TIP: Don't use <UL> to indent a block of text, or other such uses of logical tags in illogical ways.

Don't misuse logical tags. Keep their actual meanings in mind, not just their visual effects on your particular browser (which can vary on other browsers). The meaning of <UL> is not "indent this text"; it means "what follows is an un-numbered list," and the fact that some browsers indent it is incidental. (Early versions of WebTV didn't indent <UL> lists!) By the HTML specs, the only proper content for a <UL> list is <LI> items, so the rendering of lists not following this syntax is undefined; a standards-compliant browser could discard the entire contents of that section of your document. It's poor form to rely on some browsers' behavior that runs against the logical meaning of a tag. You'll just end up confusing any software that actually tries to interpret the meaning of your document instead of just its looks, and you'll have a hard time converting your documents for new innovations like stylesheets.

Unfortunately, those of you who use WYSIWYG editors like DreamWeaver, or let other programs like Microsoft Word or Microsoft Publisher extrude HTML, probably have no idea if these programs are generating physical tags, correctly-used logical tags, or abused logical tags. Most likely the code such an editor generates will not be very good as a logical representation of your content, since it is being generated in accordance with a graphical layout rather than a logical structure. All the more reason to learn HTML syntax and write your pages by hand in an ASCII editor!

Custom Elements

The above article was written originally in the 1990s, with a few piecemeal revisions and updates later. The more modern HTML 5 Web (as of 2015) now affords even more opportunities to use logical identifiers in the Web. Cascading Style Sheets have long let you attach varying styles to logically named things through the use of the "class" and "id" attributes, but now you can even define custom HTML elements of your own, which can get their styling from stylesheets. It's only required that the new elements be named with a hyphen in them so as not to conflict with current and future "standard" HTML tags.

Links

A Detailed Introduction To Custom Elements
David Siegel, the author of Creating Killer Web Sites, understands the distinction between physical and logical tags, but due to his graphical-design-oriented mindset, he advocates using the former where I would support the latter. His was one of the best-presented explanations of the opposing viewpoint from mine, but currently the "KillerSites" site seems to be run by somebody else and no longer has quite the logic-hostile advocacy it once did.

[<== Previous] | [Up] | [Next ==>]