HTML Tag Definitions

 
 

 Introduction 

What is a Tag Editor? A dialog with fields to enter and edit the attributes of a tag. Tag Inspector simply shows the same attributes in a different user interface. With many tag editors, that is indeed all there is to it: list the attributes, write them out as entered. But there can be more to it than that.

Tag editors are driven by a tag definition written in VTML. Theses tag definitions don't just drive Tag Editors, either: they also determine the behavior of Tag Inspector, Tag Insight and Tag Tips. You now find tag definitions for CFML, HTML, HDML, SMIL, and VTML with HomeSite and ColdFusion studio. The tag definitions for HTML and VTML weren't created by Allaire, though: they were first released as freeware on HomeSite Help outside link . They aren't just a listing of attributes to be filled in and written out. These sets have been carefully designed as a whole according to a number of design principles while always keeping general user interface design guidelines into account.

The main principles used in the design of these Tag Definitions are:

How these principles have been applied and how this will make your code editing life easier will be explained in the following sections. Most sections below refer to how these principles have been applied to the user interface and behavior of the the Tag Editors (as defined in the tag definition files). For Tag Inspector and Tag Insight there's a separate section below explaining what they can (and cannot) do. The focus of this document is mainly the how these design principles were applied to the HTML tag definitions, but they apply equally to the tag definitions for VTML, documented separately. This document does not refer to any of the tag definitions (for CFML, HDML and SMIL) written by Allaire.  to menu

 HTML Standards 

HTML 3.2 and HTML 4.0

Forget about HTML 2.0 - it is no longer relevant. But even though HTML 4.0 is the current standard (and has been since December 1997) many browsers currently in use  do not support this. Until these browsers really become rare animals in the wild, HTML 3.2 remains an important standard.

In the Tag Editors defined by these Tag Definitions, HTML 3.2 is therefore the visible starting point: Every tag that exists in HTML 3.2 has a first tab on the dialog for this. If the tag does not take any attributes in HTML 3.2, this is noted on this first tab: attributes added by HTML 4.0 will be found on one or more extra tabs. Tags that are new in HTML 4.0 (even if they were supported by earlier browsers!) are clearly identified (see visibility below).

What you will not find as a Tag Definition are the tags that are considered obsolete in HTML 4.0 (rather than deprecated); if you must use them: the Tag Chooser does have special sections for these.

Browser extensions

But what about all those browser extensions? Don't worry, they are there - also clearly marked. In most cases browser-specific attributes can be found on their own tab pages in the Tag Editors. Most browser-specific tags are also supported and have a clear marker on the dialog to identify them - as well as special sections in the Tag Chooser: Netscape, Internet Explorer, Mosaic and Opera are all covered here.

Finally, some attributes that are now officially part of the HTML 4.0 standard but were supported by earlier browsers are "commented" with browser logos: this also covers Netscape, Internet Explorer, Mosaic and Opera.

Coding standards and UI guidelines

These principles will help you maintain strict coding standards and the way these principles are applied in the dialogs is an application of an important user interface design principle: Recognition is easier than recall. You don't need to memorize what is defined in which standard and what the browser extensions are: these dialogs will simply show you.  to menu

 Visibility 

Grouping

The first visibility principle has been indicated already in the section about HTML standards: attributes are grouped according to the standard they were defined in. But this principle (another important user interface guideline) is taken much further: related attributes are grouped in several levels: on tab pages, in group boxes, and even by proximity. For instance, attributes related to horizontal sizing and positioning are close together - as are the ones for vertical sizing and positioning. Tabbing order in the dialogs also take these relationships into account.

Graphical markers

There are many graphical markers in these Tag Editors as well and their position always makes clear what  they refer to: every marker identifying a group of attributes always occurs to the left of the grouping it is marking. This occurs on several grouping levels as well: you'll find markers for a whole dialog (in the upper left corner of the dialog), for a group of attributes (to the left of a group box enclosing those attributes) or to the left of an entry field (required attributes). There is one exception: graphical markers that serve as a comment rather than identifying a group are found inside the group box (earlier browsers supporting attributes now in HTML 4.0).

Required attributes

Every required attribute is identified with an asterisk Required attribute to the left of its entry field. The normal color is black but attributes required in HTML 3.2 but not in HTML 4.0 have a blue marker while attributes required in HTML 4.0 but not in HTML 3.2 have a red marker. Such distinctions are always commented in text so even totally color blind people will be able to use this information.

Required attributes are always written even if no value has been entered: this will serve as another visual reminder in your code that a value really is needed for the attribute and should trigger an error message when validating the code. So the visual markers serve as an extra warning that you really need to enter a value in the marked fields.

Default values

Many attributes in HTML have defined default values: if the attribute is not present, this is the value that will be used. For every attribute with a list of possible values (usually a dropdown listbox or combobox), this default value is marked in the visible caption. The intelligence aspect of these Tag Editors makes use of this: if you select a default value, it will not be written. You'll know what is happening though since the user interface makes clear what these default values are. If you are not editing an existing tag but inserting a new one, this default value will also be the one initially selected.

One small exception: some tags for use in tables do have a default value for some attributes but this is only in effect if not overruled by a setting on a higher level. In these cases, the initial value in the entry field is blank; the default value is marked but if you select it it will  be written, allowing you to override any setting in a "parent" tag (which the Tag Editor cannot "see").

Tag Chooser

The Tag Chooser has yet another visibility aspect that you won't find in the previous (Allaire's) version: not only are the HTML tags grouped into classes for standard, deprecated, browser-specific and obsolete (with specially designed icons for each), in the listbox on the right you can also see the difference between those tags that are entered directly into your document (those without any attributes) and those that have a Tag Editor associated with them.  to menu

 Consistency 

Learnability

It's quite simple, really. The same things are called the same. And you'll always find them in the same relative places. For instance, the attributes in HTML 4.0 for tying to style information are always on a separate tab; and you'll always find the accessibility attributes on the same tab. The tab always has the same caption. The two groups of attributes (those that are actually defined for a particular tag) each are in their own, labelled, group box. The group boxes are always in the same order. The fields inside the group boxes are always in the same position relative to each other.

Get the idea? Once you've learned where particular attributes are in one dialog, you won't spend much time hunting around for them on another one: you already know where they are. Well, mostly. When a tag has many browser-specific variants, I've sometimes had to distribute then over two tab pages. But still, if there are any browser-specific attributes, you know where to find them. This kind of consistency makes the user interface easy to learn and you'll soon be able to work very fast with it.

Behavior

Another consistency aspect is the behavior of the Tag Editors. For instance: real default values are always indicated; and they are never written. If you make a choice between two sets of values, the Tag Editor makes sure the other, irrelevant, set is not written. You only get what you need, consistently.  to menu

 Flexibility 

To quote or not to quote

Some people like all their attributes quoted. Some like not to have those quoted that really don't need the quotes. All these Tag Editors give you a choice: quote all attributes (set as default) or not. In the latter case, the algorithm is conservative: only real numerical values and strings from a fixed value set where none contain any characters requiring quotes are written without quotes. Mostly this means that pixel values and alignment properties are written without quotes. But all URIs are quoted, even if it's just a file name with a single dot in it.

Some people like their quotes double, some like them single. Another checkbox gives you the choice. Independent from the previous one: only when an attribute is quoted is this choice applied. Even when editing existing attributes like a list of font names that already contains quotes around names with spaces in them!

Optional end tags

Several tags have optional end tags. When inserting such a tag with these Tag Editors, you'll always get the choice whether or not to write the end tag. The default is in all cases to write it: it can help (you, and the browser) when you're using style sheets and will get you used to the next XML-based standard where all containers must have an end tag. If you don't want the end tag anyway, it's just a single mouse click on the first tab.

Browser-specific values

Sometimes attributes themselves are not browser-specific but browsers add possible values to the list defined in the standard. You still get the choice: on the standard tab you'll find the standard list; on the browser-specific tab you'll find the more extensive list.  to menu

 Intelligence 

Not needed, not written

These Tag editors make a lot more intelligent choices than just deciding whether a value was entered and only writing the attribute in that case. As already mentioned, they are clever enough not to write any default values either (not without informing you: that's what the visibility is for).

Sometimes tab pages are a mechanism to make choices. For instance, the LI tag can take a number of attributes, but some only apply when it's used inside an ordered list, some only when it's inside an unordered list. You make the choice (the Tag Editor sees only the tag itself) but based on that choice the Tag Editor writes only the relevant attributes (and throws any non-relevant ones away).

Different value sets

What if there are dropdown lists for ALIGN on both the standard tab and the browser-specific tab? The Tag Editor tries to take a sensible decision: If you choose a browser-specific value, it will assume that is really what you wanted - even if you made a different choice on the other tab. In fact, if you make any choice from the browser-specific list, the Tag Editor will assume you have a reason to make you choice there. Knowing this behavior, you can use it: if you want to avoid a value from the browser-specific list: clear the field there and choose one from the list on the standard tab.

Lists in attributes

Several attributes can take more than a single value: they accept lists of possible or applicable values. The rows and columns in framesets are one example: these attributes accept a comma-separated list of values. In such cases you simply type the list in the entry field.

Other lists can consist only of values from a list of predefined ones. A good example is the FACE attribute of the FONT and BASEFONT tags: you can define a list of font names that the browser will traverse to find the first one available on the user's system. For lists these Tag Editors have a special list builder technique: at least three dropdown lists allow you to choose more values at once; the Tag Editor then combines them into a list. When you edit such an attribute, the current list will appear in the first dropdown list which is editable to you can for instance remove a value from the list while adding new ones by choosing values from the other dropdown lists. The current value is shown above as a reminder.

In the case of font faces there's a bit of extra intelligence: when needed, new font names that contain spaces are put in quotes. Your choice for quoting style is taken into account: if necessary already-existing quotes are replaced before adding new ones!

Generators

Some tags are containers for lists of options. The Tag Editors for such tags will optionally generate a list of options with numbers as their initial values. Just fill in the current indent level (tabs) and the number of options to generate and the Tag Editor creates a quick start list for you.  to menu

 Tag Insight and Tag Inspector 

Tag Insight

When Tag Insight first appeared (in HomeSite and ColdFusion Studio 3.0) it was controlled by a separate file. That was both an advantage and a disadvantage: it was easy to add new data for Tag Insight; at the same time it was also very easy to create Tag Insight data that were inconsistent with the Tag Editors. As of version 4.0 of these programs, Tag Insight is controlled from the same Tag Definition as the Tag Editors are; we gain some and lose some: maintaining consistency has become a lot easier. But the user interface Tag Insight can provide cannot be controlled from these Tag Definitions: they only provide the data for it. What we've lost is the color coding that would make the difference between standard and browser-specific attributes visible. If you need this information, your best option is to use the Tag Editors now: these at least do make a point of showing this difference.

While visibility in Tag Insight has suffered with the loss of color coding, its "intelligence" is still absolutely nil. It will happily let you insert attributes that are overruled by others, or insert them twice. It doesn't know anything about defaults or lists. It will generate nothing at all. All it can handle in the user interface is data types (font picker, color picker, lists of possible values, and the rest) but it cannot build value lists. At least the browser-specific and default values can be marked in their captions; but while this helps in Tag Inspector, Tag Insight will show only the values, not the captions, so it won't help you there, sorry. The defined data types do cause some different icons to appear before the different attributes in Tag Insight. But that's about it: "Real" intelligence can be in built into Tag Editors only - and that capability was used in the HTML and VTML tag definitions. By their design, the Tag Editors for HTML and VTML actually give you a lot more "insight" than Tag Insight can ever do.

Tag Inspector

The situation with Tag Inspector is somewhat more subtle. As with Tag Insight, it's an already-defined user interface that a Tag Definition can only provide data for. But while it can do considerably less than a Tag Editor, it can do a lot more than Tag Insight. It does take existing attributes into account and will in principle not let you insert the same attribute twice. Alas, that's about as far as its "intelligence" goes.

The data types have a bit more effect than in Tag Insight: apart from a Color Picker and a Font Picker there's also an interface to the Style Editor (just like in the Tag Editors) which is not present in Tag Insight. But there's still a big drawback here: with Tag Inspector you cannot build value lists; worse: if you use Tag Inspector to edit an existing font FACE attribute for instance, choosing a value from the font picker will destroy any pre-existing list.

In the value sets, those values that have been marked as browser-specific or default are visible, just like in Tag Insight. But a value from a dropdown list is always editable so you can enter whatever you like: unlike in a Tag Editor, where this option can be controlled (editable or not) to prevent illegal values from being entered.

Tag Inspector also does not allow the multiple-level grouping and classification of attributes that is possible in dialog. Attributes can be assigned to different categories, even to more than one, but only one level is available. To make up as much as possible for the level of visibility possible in Tag Editors, the approach to classification taken here is radically different from that found in the tag definitions originally released with HS/CFS 4.0:

There were two reasons to deviate from the original classification by "purpose" as found in HS/CFS 4.0:

  1. Most attribute names are already fairly descriptive.
  2. While there is a "Version" view available in Tag Inspector, instead of from a Tag Definition it draws its information mostly from the configuration file used by the internal validator - which not only contains errors but is also incomplete in that it does not reveal any version information in Tag Inspector for browser-specific tags; it also has no information about Mosaic or Opera.

In many cases this approach results in more categories. But you get information about HTML versions, required and optional attributes, and support from four different browsers, all in a single view. In other words: this categorization makes much more visible.  to menu

 Documentation 

This version of the HTML Tag Definitions has links to corresponding pages from Stephen LeHunte's HTML Reference Library (the special version which is included with HomeSite and ColdFusion Studio); they give you a nice introduction into the language.

Originally Index DOT Html was used as the main reference when creating these HTML Tag Definitions: it is simply a very thorough and complete reference, not just about the use and purpose of the HTML tags and their attributes: It also gives you detailed information about W3C standards and browser support for each tag and each attribute - as well as a lot of useful background information, like a Cascading Style Sheets Guide (not so much a guide as another reference). It's based on extensive research and of course user feedback.

But with all the recent changes in standards, browsers, and their capabilities, it's extremely hard to keep all of this documentation completely up-to-date; relying om this single reference (even if it's the best one available) is no longer an option: references from browser vendors and of course the W3C standards were also used, as well as browser tests.

If you prefer, you can use Index DOT Html as a reference together with these HTML Tag Definitions rather than the HTML Reference Library: From HomeSite Help outside link you can download detailed instructions outside link for downloading and installation of Index DOT Html in a form that makes it easier to integrate with HomeSite and ColdFusion Studio and my HTML Tag Definitions.  to menu

 More... 

There's more

Well, of course there's more. It's hardly necessary to document 88 tag editors individually: most use the principles outlined above. What you read there are examples. You get the general idea: so experiment. Try the (write-only!) "mailto" Tag Editor, for instance. Of course an email address is required; the rest is optional - see what you get with different fields entered or not.

Built-in editors

For three tags HomeSite and ColdFusion Studio have built-in Tag Editors: A, BODY and IMG. If you edit a tag or choose the corresponding button from the QuickTab, these are the editors you'll see. There is a good reason for having built-in editors: all these three do things Tag Editors written in VTML cannot do. The Anchor editor allows you to choose from your bookmarks or favorites; the Body editor will show you a preview of the effect of background and text colors; the Image editor shows a preview of the image and allows recalculation of HEIGHT and WIDTH attributes. But sometimes, these features are not the ones you need but you do need the ones defined in the VTML version.

Currently, the only way to use the VTML-based Tag Editors for these tags is when inserting a new tag: and you can no longer select it from the Tag Chooser: only a toolbar button will give access to the Tag Editor as defined in the Tag Definition. HomeSite and ColdFusion Studio make it easy to create a toolbar button for a Tag Editor though. Make one for A, BODY and IMG and you'll have all the power of these tag editors available when inserting these tags - as well as the built-in ones.

Fun

Software should not only do the job. Software should also be a pleasure to use - and Tag Editors are software, of course. The careful application of interface design guidelines should help. But that isn't necessarily all: quite a few Tag Editors in this package have "identifying" images that are not strictly necessary to discern between HTML standards or browser versions. Sometimes they still help: for instance, all table-related tags have images that identify what part of a table they refer to. But some are purely for fun: poke around and you'll find them.  Made in the Netherlands One example: the (VTML version of the) IMG Tag Editor is identified by an "image" image. Something that reminds of a Mondrian painting; it doesn't just look nice: this image will also serve as a gentle reminder that these Tag Editors don't come from the USA but from the Netherlands ;-) Enjoy!  to menu

 Acknowledgements 

 to menu