HTML Tag Definitions: Documentation

On this page:

Introduction
HTML Standards
Visibility
Consistency
Flexibility
Intelligence
Tag Insight and Tag Inspector
More...

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.

While in HomeSite 3.01 and ColdFusion Studio 3.11 the VTML files defined only Tag Editors, with the appearance of VTML 2 with version 4.0 of these programs they also contain information used by Tag Insight and the new Tag Inspector.

The Tag Definitions that originally came with HomeSite 4.0 and ColdFusion Studio 4.0, and the earlier Tag Editors that came with version 3.x of these programs, simply let you enter values for attributes and then write those into your document - but that's basically all  they did. That way it doesn't make much difference whether you use a Tag Editor or Tag Inspector (version 4.0 and later) to edit a tag.

The Tag Definitions in this package are much more than that. First of all, the set is much more complete: you'll find Tag Definitions for many tags that were missing until now (there are about twice as many here!). But these Tag Definitions are not simply "fixes and additions": this set has been carefully designed as a whole according to a number of principles while always keeping general user interface design guidelines into account.

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

• HTML Standards
• Visibility
• Consistency
• Flexibility
• Intelligence

How these principles have been applied and how this will make your HTML editing life easier will be explained in the following sections. Most sections below refer to how these principles have been applied in the Tag Editors (as defined in the Tag Definitions). For Tag Inspector and Tag Insight there's a separate section below explaining what they can and cannot do.

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.

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 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.

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.

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 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.

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.

The following features are available only with version 4 of HomeSite and ColdFusion Studio.

Tag Insight

In the previous versions of HomeSite (3.01) and ColdFusion Studio (3.11) Tag Insight 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. Now, 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: at least mine do make a point of showing this difference.

While visibility in Tag Insight has suffered with the loss of color coding, its "intelligence" is 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. The only thing these tag Definitions can do for Tag Insight (apart from filling the gaps of the ones missing in Allaire's set) is careful definition of data types and value sets: While there is no way to have different sets for standards and browsers, at least the browser-specific and default values can be marked in their captions, and this is what I have done. The data types do cause some different icons to appear before the different attributes. But that's about it: Intelligence can be in Tag Editors only - and I've used that capability. My Tag Editors give you a lot more "insight" in HTML than Tag Insight can ever do.

Tag Inspector

The case for 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 a font FACE attribute for instance, choosing a value from the fontpicker 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, I have taken a radically different approach to Allaire's with version 4.0:

• The starting point is again standards: you can see Required, Optional, Required HTML 3.2, Required HTML 4.0 and HTML 4.0: this largely corresponds to the distinctions made in the Tag Editors.
• For each browser, starting with version 2 (versions 1 are no longer relevant) all attributes are listed that are supported (including browser-specific ones) starting with that browser version. As with the markers in the Tag editors, this covers Netscape, Internet Explorer, Mosaic and Opera.
• Some additional refinements where applicable (for instance for the complicated INPUT tag)

Why not have the attributes categorized by purpose, as in Allaire's original version of the Tag Definitions? Two reasons:

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 my 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.

There's more

Well, of course there's more. I don't think it's 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 since version 4.0 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 file. For that reason I've included a little toolbar in this package which gives you access to these three Tag Editors; its toolbar buttons are smaller versions of the identifying images used on the Tag Editors themselves.

Fun

Software should not only do the job. I believe 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 I didn't stop at that: 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. One example: 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!