HTML TADS is based on the HTML 3.2 reference specification, which is a W3C (World Wide Web Consortium) recommendation document that can be found at http://www.w3.org/pub/WWW/TR/. HTML 3.2 is a widely deployed "markup" language; it's supported by most of the popular web browsers currently available.
The primary reason that HTML TADS is based on HTML 3.2 is that HTML 3.2 is widely known and is reasonably powerful. Since copious documentation on HTML is available, game designers should have no problem learning how to use HTML TADS. While I've tried to follow the HTML 3.2 standard as closely as possible, so that game designers can readily apply their HTML knowledge to writing games, there are probably many existing web pages that won't work properly with HTML TADS. HTML is a quirky and somewhat nebulously-defined language, and the behavior varies substantially from one browser to another, all of which makes it difficult to implement a browser that will handle every web page. Fortunately, HTML TADS is not a general-purpose web browser, so it shouldn't ever see most of these problematic pages.
In addition to HTML 3.2, there is also a proposal for a version called HTML 3.0. Surprisingly, while HTML 3.2 is a more recent version of the language, it's not a superset of HTML 3.0; in fact, HTML 3.0 is considerably more powerful than 3.2. This is somewhat confusing, because a higher version number on a standard usually implies some degree of backward compatibility with the older versions. What happened in this case is that HTML 3.0 never became a "standard," and was never widely adopted; while work on the proposal for HTML 3.0 was underway, the HTML 3.2 specification was developed based on the older 2.0 standard.
In the meantime, because HTML 3.0 has some very nice and useful features, I've incorporated a few of its features into HTML TADS. These additions don't interfere with normal HTML 3.2 behavior, so a game designer familiar with HTML 3.2 should be able to use HTML TADS without having to learn about HTML 3.0. See the section on HTML 3.0 additions for details.
In addition, HTML TADS has a few extra features that are specific to the TADS implementation. These features don't have any equivalent in normal HTML, so I've added extensions to the language to accomodate. See the section on TADS additions for details.
HTML TADS does not incorporate the extended features of HTML 4.0 or any of the variants of DHTML.
I have tried not to deviate from HTML standards capriciously or needlessly,
which is why most of the extensions that I've chosen to implement are
based on HTML 3.0 rather than being entirely unique to HTML TADS.
I've tried to keep HTML TADS compatible with the HTML standards as
much as practical to reduce the amount you need to learn beyond
standard HTML to use HTML TADS.
An extension to the <IMG> tag provides a way of implementing simple roll-over images. A roll-over image is a hyperlinked image that has up to three different appearances: a normal appearance, a second appearance when the mouse is hovering over the hyperlink, and a third appearance when the mouse button is being held down with the mouse over the hyperlink. Using roll-overs can give a user interface a more lively feel, since the active elements respond visually as the mouse approaches them.
In HTML designed for viewing in Web browsers, site designers can use Javascript to implement roll-over buttons. HTML TADS does not include Javascript support, so it has to provide its own non-standard mechanism for roll-overs.
Important: The roll-over extensions work only with hyperlinked images (i.e., images nested within <A HREF> tags). You cannot create a roll-over image that is not hyperlinked.
The HTML TADS roll-over extensions consist of a pair of new attributes of the <IMG> tag: HSRC and ASRC. Both of these attributes are optional, and each takes a URL to an image resource, just like a standard SRC attribute does. The HSRC attribute, if present, specifies the image resource to use for the "hovering" appearance of the image: this is displayed when the mouse is over the hyperlink, but the button isn't being pressed. The ASRC attribute specifies the image to use for the "active" appearance: this is displayed when the mouse button is being held down over the hyperlink. You can use any supported image file format (including MNG animated images) for the HSRC and ASRC images.
You can specify one or both of ASRC and HSRC. If you specify only HSRC, the same image is used for both the "hovering" and "active" appearances. If you specify only ASRC, the image will use its regular SRC image for the "hovering" appearance.
Here's an example of an IMG tag that specifies separate images for all three appearances:
<A HREF='test'><IMG SRC='button_normal.png' ASRC='button_active.png' HSRC='button_hover.png'></A>
For proper display, you must ensure that all of the images for the different appearances used in a single <IMG> tag are the same size.
BANNER is a tag from HTML 3.0 that allows a document to create a non-scrolling area on the screen, and display arbitrary HTML markups within this area. HTML TADS uses BANNER, with a few extensions, to implement the "status line" that traditional text adventure games display across the top of the screen to show, for example, the current location and score.
Refer the to full description of the BANNER tag
for details on how to use this feature.
As described in the <A> section on
HTML 3.2 tag behavior deviations, <A
HREF> allows you to set up a "hypertext link" of sorts. Instead of
specifying a link to a web page with a URL, HTML TADS interprets the
HREF as a command. When the player clicks on a link, HTML TADS
enters the text in the HREF attribute as a command (replacing any
text that was on the command line already, and immediately entering
the command without waiting for the return key).
In addition, the PLAIN attribute (which takes no value) specifies
that the link is to be rendered as though it were normal text. The
text will still act like a link, so any other (system-dependent)
visual cues that the text is a link will still be in effect; for example,
the mouse cursor will still change to the link shape when the mouse is
moved over the linked text. This attribute is not meant to be used to
hide important links from the user, and should be used carefully to
avoid obscuring information; the purpose of this attribute is to allow
specific links that are provided for convenience, but which are
otherwise not critical, to be rendered in an unobtrusive fashion.
Two additional attributes, unique to HTML TADS, let you control how
the command text in the HREF is handled. Normally, when the player
clicks on a link, TADS deletes any existing text on the current
command line, puts the HREF text into the command buffer, and then
immediately ends the command as though the player had pressed the
Enter key. You can change this default behavior in two ways.
First, if the <A> tag
specifies the APPEND attribute (which takes no value), the system does
not clear the existing command text, but simply adds the HREF
text to the end of the current command text. Second, if the tag
specifies the NOENTER attribute (which also takes no value),
TADS does not enter the command, but simply puts the HREF text into
the command buffer, and lets the player continue editing the command.
Note that APPEND and NOENTER can be used the same way
with <AREA> tags, which specify links in image maps.
<A HREF>
<TAB MULTIPLE>
As described in the TAB section on
HTML 3.0 Additions, HTML TADS
supports the <TAB>
feature of HTML 3.0. Note, though, that the <TAB MULTIPLE>
feature is a TADS-specific extension of the HTML 3.0 extension.
Note that a percentage value of HEIGHT in an embedded TABLE tag (a table embedded within another table) still bases the table's height on the window's height, not on the enclosing table row's height. This is different than WIDTH with a percentage value, which bases an embedded table's width on the width of the column containing it.
The CAPTION tag takes both ALIGN and VALIGN attributes. If ALIGN is set to TOP or BOTTOM, CAPTION behaves as it does in HTML 3.2. However, ALIGN can also be set to LEFT, CENTER, or RIGHT. If you want to control both horizontal and vertical alignment explicitly, use ALIGN for horizontal alignment, and use VALIGN for vertical alignment. The defaults are ALIGN=CENTER and VALIGN=TOP. If ALIGN is specified as TOP or BOTTOM, this is equivalent to setting VALIGN to the same value and using ALIGN=CENTER.
The BGCOLOR attribute can be used to specify the background color of an entire table (TABLE tag), all of the cells in a row (TR tag), or of an individual cell (TD or TH tags). The cell BGCOLOR setting overrides any setting inherited from the row, which in turn overrides the setting inherited from the table.
If a table has an ALIGN attribute value of LEFT or RIGHT, the renderer shows the adjoining text flowing around the table - that is, a table with ALIGN=LEFT is placed in the left margin, with the adjoining text filling the area to the table's right, and an ALIGN=RIGHT table is placed in the right margin with text filling the area to its left. This is standard, although optional, behavior. However, HTML TADS deviates from the standard by treating a table with ALIGN=LEFT or ALIGN=RIGHT as an "in-line" item rather than a "block" item, which means that such a table does not cause a paragraph break in the visual display. Instead, a table with ALIGN=LEFT or ALIGN=RIGHT is treated visually exactly as though it were an <IMG> tag with the same alignment. This behavior, while non-standard, is actually consistent with the most popular web browsers, and allows greater flexibility for special text layout effects. If a paragraph break is desired, the author can simply insert a <P> tag explicitly before and/or after the table. If no flow-around is desired at all, a <BR CLEAR=ALL> tag can be used immediately after the table's closing </TABLE> tag.
HTML TADS lets you define an about box for your game using this new tag. To define an about box, display the <ABOUTBOX> tag to start the information you want to include in the dialog, then display any HTML text, then display the </ABOUTBOX> closing tag. You will probably want to put this display in your init function, since you'll only need to display it once, at the beginning of the game.
Here's an example of using the tag. Note that we put the about box code in the commonInit function, because we want to make sure that this text is displayed whenever the game is loaded, regardless of whether it's loaded with a saved game or not. We assume in this example that your init and initRestore functions (one of which the system automatically calls at startup, depending on whether the player starts your game from the beginning or with a saved game) each call your commonInit function (which the system does not automatically call, but is merely a convention used in std.t).
commonInit: function { /* run this game in HTML mode */ "\H+"; /* set up the about box for the game */ "<AboutBox> <body bgcolor=silver> <H3 align=center>A Sample Game</H3> <center> This is a sample game that demonstrates some exciting new HTML TADS features. </center> </AboutBox>"; }The information within the ABOUTBOX tag doesn't show up in the normal text window. Instead, TADS captures the information and stores it away, so that it can be displayed when the user brings up the "About this game" dialog. (The "About this game" command is on the "Help" menu in the Windows version of HTML TADS. If the game never defines an about box, the menu item is disabled.) When the user displays the game's about box, HTML TADS opens a dialog box showing the ABOUTBOX information.
In addition to the entities listed above, HTML TADS supports all of the named entities in HTML 4 in the section "symbols, mathematical symbols, and Greek letters." In fact, HTML TADS supports nearly all of the HTML 4 named entities; the only entities not currently supported are the spacers and joiners (ensp, emsp, thinsp, zwnj, zwj) and the bidirectional markers (lrm, rlm).
Because the list of HTML 4 named entities is lengthy, it's not included here; refer to the HTML 4.0 specification for the full list.
HTML TADS also supports the ISO Latin-2 named entities. ISO Latin-2 is
a character set designed for Eastern and Central European languages.
The Latin-2 named entities are not part of the standard HTML specification,
but some provide this set of entities as an extension. Refer to the
HTML TADS Latin-2 table for the complete list.
When you use a parameterized font, instead of naming a system font
explicitly, you name a special pseudo-font. HTML TADS maps this name
to an actual font at run-time according to the fonts available on the
system. Because the mapping is done at run-time, the parameterized
fonts are portable -- the HTML TADS interpreter chooses an appropriate
mapping for the current system when the game is played. In addition,
on some systems, HTML TADS allows the player to choose the
mapping through a preferences mechanism, so parameterized fonts give
both the game author and the player control over the presentation:
the game author specifies the abstract style desired, and the player
chooses the final display appearance.
Here are the available parameterized font names:
You should consider using parameterized fonts whenever possible rather
than explicit system font names. Using explicit system font names
creates portability problems not only to different types of computers,
but even to the same type of computer, because you can't always be
sure of which fonts a player will have installed. Parameterized fonts
provide much better portability, because HTML TADS will determine which
actual system font to use at run-time.
Note that you can also use parameterized font names as a fallback
for an explicit system font for when the font is not installed. A
common strategy that web page designers employ when specifying fonts is
to specify a series of fonts that are common on various platforms as
substitutes for a particular system font; for example, Arial on Windows
is similar to Geneva on Macintosh, so Geneva is often used as a fallback
for Arial. You can take this one step further using a parameterized
font. Since the parameterized font lets you specify the style of
font you want, you can use it to provide a good substitute when
the font you really want isn't present. For example, since Arial is
a sans serif font, you might specify TADS-Sans as a fallback when
Arial isn't installed:
Here's an example of selecting a script-style font using the parameterized
font mechanism.
You'll probably use the TADS-Input font a little differently
than the others. This font is meant only for text entered by the player
on command lines; the point is to allow the player to select the font and
style (including color, bold, and italic settings) that should be used
for entering commands. Normally, you should define a commandPrompt
function and a commandAfterRead function like this:
The commandPrompt function displays the usual prompt (">",
using the HTML entity name for the greater-than sign, ">"),
then establishes the TADS-Input font, which uses the font
for text entered by the player. After the player finishes editing
the command and presses Enter, the commandAfterRead function
closes the <FONT> tag to restore the previous font.
Note that the standard library file std.t includes a definition of
the commandPrompt and commandAfterRead functions
as shown above, so if you don't override these functions, you'll
get this new behavior by default.
For these settings, standard HTML defines a set of color names (BLACK,
SILVER, GRAY, WHITE, MAROON, RED, PURPLE, FUCHSIA, GREEN, LIME, OLIVE,
YELLOW, NAVY, BLUE, TEAL, and AQUA), and also accepts explicit hexadecimal
RGB values (for example, COLOR=#203040 specifies a color with hex 20
intensity in red, hex 30 intensity in green, and hex 40 intensity in
blue, with each intensity on a scale from zero to hex FF).
While the HTML color attributes provide considerable flexibility and
control in defining your game's display characteristics, they also remove
control from the player and from the operating system. On some displays,
particular combinations of colors and fonts may produce unreadable text,
and in many cases players may wish to choose certain settings for
themselves because they prefer a certain color scheme.
HTML TADS provides an extension to the standard HTML color system that
provides for some player customization and still lets the game author
specify most of the display characteristics. These new colors are called
"parameterized" colors, because they do not refer to hard-coded RGB values
the way that other HTML colors do, but instead refer to specific parameters
that are chosen at run-time. On some systems, the player can set the
colors through a preferences mechanism, while on others the system may
choose appropriate colors for the display device.
To use the parameterized colors, simply use the parameterized color names
in place of the ordinary HTML color names. For example, the default status
line code in adv.t uses these settings for the status line:
The parameterized color names are listed below.
HTML TADS lets you use a backslash to indicate an end tag, whereas
normal HTML would only accept a forward slash. So, <\TABLE>
is equivalent to </TABLE>. (Since backslashes have no
special meaning in HTML normally, this extension shouldn't create any
ambiguity.)
The following tags from HTML 3.0 are not implemented:
None of the math-related tags or markups are implemented.
The ID, STYLE, and CLASS attributes, which apply to nearly every HTML
3.0 tag, are not implemented (except where otherwise noted below).
The rest of this section lists features of HTML 3.2 that are
implemented in HTML TADS.
The NOWRAP attribute can be used on most block-level tags, in addition
to <P>. NOWRAP works with P, DIV, UL, OL, DL, the heading
tags (H1 through H6), ADDRESS, and BLOCKQUOTE.
The ALIGN attribute can be used with <TAB> to specify the type
of alignment to use. ALIGN can be used on the defining <TAB
ID=abc>, or on each use of <TAB TO=abc>; if no ALIGN is used
in the TO tag, the ALIGN from the ID tag is used by default; LEFT is
used if neither has an ALIGN attribute. ALIGN=LEFT aligns the
material after the <TAB TO> with its left edge aligned at the
tab; ALIGN=RIGHT aligns the material after the <TAB TO> and up
to the next <TAB TO> or the end of the line, whichever comes first,
flush right at the position of the tab. ALIGN=CENTER aligns the
material up to the next <TAB TO> centered on the tab position.
ALIGN=DP aligns at a decimal point (or at any other character
specified with DECIMAL="c", where "c" is the character at which to
align entries).
<TAB ALIGN=CENTER> or <TAB ALIGN=RIGHT>, without a TO
attribute, align the material with respect to the right margin. This
provides a simple way of aligning material against the right margin
(ALIGN=RIGHT), or centered between the end of the text up to the
<TAB> and the right margin.
<TAB INDENT=n> (where n is a number) indents by
a given number of "en" units; it simply adds the given amount of
whitespace to the line. <TAB MULTIPLE=n> indents to
the next multiple of the given number of ens from the left margin.
You can use <:TAB MULTIPLE> to get the effect of tabs set
at regular intervals across the page, without having to set up
a bunch of named indent points and figuring out which one you're
closest to.
In addition to accepting explicit system font names, the FACE attribute
also accepts "parameterized" font names, which let you specify a style
of font that will be mapped to an appropriate system font on each platform.
Refer to the parameterized font documentation
for full information.
The BASEFONT tag accepts the FACE and COLOR attributes; these behave
the same as they do with the FONT tag.
Most block-level tags recognize the CLEAR attribute.
CLEAR on a block-level tag works the same way it does on a BR tag.
The additional tags that accept the CLEAR attribute are DIV, UL,
OL, DL, all of the heading tags (H1 through H6), ADDRESS, and
BLOCKQUOTE.
The UL and LI tags accept the PLAIN attribute to indicate that
the list item (in the case of LI) or all of the items in the list (in
the case of UL) should be displayed without a bullet. If <LI
PLAIN> is specified for an item in an ordered list, the item is
displayed without a number. <OL PLAIN> is also accepted, even
though it probably isn't very useful (although it could conceivably
be used to specify a numbered list where most but not all of the
items are listed without a number; each of those to be listed with a
number would have to specify a TYPE setting to override the default
plain style).
The UL (unordered list) tag takes the SRC attribute to specify the
name of an image to use as the bullet for the items in the list.
This image is displayed in place of the bullet that would normally
be used; if provided, the TYPE attribute is ignored.
The LI (list item) tag also takes a SRC attribute; this overrides
the SRC attribute of the enclosing list, allowing you
to use a special bullet for an individual item in a list.
The CONTINUE attribute (no value) specifies that the list numbering
should continue where the last list left off. For example, if the
last item of the previous list was 5, the new list will start with
item number 6.
The LH tag is implicit for any material between a UL or OL tag and
the first LI tag; that is, if you put material inside a list but
before the first list item, it will be treated as a list header.
This behavior is consistent with most browsers.
The HR tag accepts a SRC attribute, which specifies the URL of an
image to display in the rule. The image is repeated as needed to
fill out the space. If a SIZE attribute is given, it
specifies the height of the rule; otherwise, the height of the image
is used as the height of the rule. The value that <HR SRC>
provides beyond <IMG> is that <HR SRC> repeats the image
to fill a horizontal area, which can scale in proportion to the window
size, whereas <IMG> just draws the image once.
Note that the BODY tag does not require (nor does it allow) a closing
tag.
The ISMAP attribute is accepted but ignored. (In normal browsers,
this attribute is intended for use with CGI server programs; CGI
servers are not applicable to HTML TADS.)
The USEMAP attribute only works with local image maps; i.e., the
image map name can't be a URL referring to some other document,
but must be part of your game's text output. Note that this means
that the attribute value must start with a pound sign (#):
Note that HTML TADS will assume that a pound sign should be present
if you don't include one, hence all URL's will be interpreted as
local, but you should always use a pound sign anyway to ensure
compatibility with future versions.
Two new attributes, ASRC and HSRC, provide simple
roll-over highlighting for hyperlinked images. See
Roll-over Images for details.
The APPEND and NOENTER attributes, described in the notes
on the <A HREF> tag, work the same
way for the AREA tag.
The TABLE element with ALIGN=LEFT or ALIGN=RIGHT is treated
as an in-line item. See the TABLE additions
section for more details.
Essentially, everything related to forms is unimplemented; this probably
isn't a big loss, since forms wouldn't be all that useful in most
adventure games. In addition, the hypertext structure tags, such
as HEAD, ISINDEX, and NXTID, are not meaningful with the non-standard
page model that HTML TADS uses. Style sheets aren't supported (in fact,
they're not supported in HTML 3.2 either; the STYLE tag in HTML 3.2 is
a placeholder for future versions.) Finally, scripting and applets
wouldn't be useful, since HTML TADS is an entirely "client-side" system
to start with.
In addition, note that FRAMESET and FRAME are not supported in HTML TADS.
(These are not actually HTML 3.2 tags, but they're worth mentioning here
because some of the browsers that use HTML 3.2 as a baseline support
frames, hence many HTML authors think of frames as an HTML 3.2 feature.)
However, HTML TADS has a separate tag, BANNER,
that provides substantially the same functionality as frames.
Parameterized Fonts
The FONT tag's FACE attribute (which is an HTML 3.0 extension) accepts,
in addition to actual system font names, a set of "parameterized" font
names. These parameterized names let you specify a style of font more
specifically than you can with any of the HTML phrase-level style markups,
while still retaining portability.
<font face='Arial,Geneva,TADS-Sans'>
"The wedding invitation reads:
<p>
<center>
<font face='TADS-Script'>
Mr.\ and Mrs.\ Dimwit Flathead III
<br>request
<br>The Honour of Your Presence
(etc.)
</font>
</center>";
commandPrompt: function(code)
{
"><font face='TADS-Input'>";
}
commandAfterRead: function(code)
{
"</font>"
}
Parameterized Colors
Several tags have attributes that let you specify a color setting;
for example, you can set the color of a run of text using the FONT
tag with a COLOR attribute:
<FONT COLOR=RED>This is some red text!</FONT>
<body bgcolor=statusbg text=statustext>
<Q>
HTML TADS supports the HTML 4.0 <Q> tag. This tag encloses
a passage in quotation marks (by placing an open quote where the
<Q> tag appears, and a matching close quote where the </Q>
ending tag appears). <Q> uses typographical quotation marks
if available on the interpreter platform, and automatically alternates
between double and single quotes when <Q> tags are nested.
End-tag syntax
HTML 3.0 Additions
Unimplemented HTML 3.0 tags, markups, and attributes
Since HTML TADS is based primarily on HTML 3.2, tags, markups, and
attributes which are not otherwise described as implemented in the
following sections are not implemented. However, in the interest of
completeness, this subsection notes most of the HTML 3.0 features that
are not implemented in HTML TADS; this list is not necessarily
complete.
LANG
AU
PERSON
ACRONYM
ABBREV
INS
DEL
FIG
FN
BQ
BQ is a synonym for BLOCKQUOTE.
CREDIT
The CREDIT tag can be optionally placed at the end of the contents of
a BLOCKQUOTE (or BQ) sequence. CREDIT is a container and requires an
end tag; the contents are the source of the quote.
<BQ>Gnomon is an island
<CREDIT>Trinity</CREDIT></BQ>
NOBR
(This is actually only mentioned in the HTML 3.0 proposal as an
extension implemented by a few of the popular browsers; it's not
clear if NOBR is actually part of the HTML 3.0 proposal.) This is a
container tag. Text between the <NOBR> and corresponding
</NOBR> will not be word-wrapped, so the only line breaks
within the text will be those that are made explicitly by <BR>
tags.
<P NOWRAP>
The NOWRAP attribute can be used on a paragraph to indicate that text
within the paragraph is not to be word-wrapped. The only line breaks
within the paragraph will be at explicit <BR> tags. This is
equivalent to enclosing the text of the paragraph between
<NOBR> ... </NOBR> tags.
BANNER
The BANNER tag allows non-scrolling areas to be added to the window.
HTML TADS uses BANNER to implement the status line (in the
traditional text adventure game sense of the line at the top of the
screen that shows, for example, the name of the current location and
the score). Although the HTML 3.0 BANNER tag has a somewhat
different purpose, its behavior is essentially the same as is needed
to implement adventure game status lines, so I've used this tag
rather than creating a new tag. However, HTML TADS's BANNER tag has
some new attributes; refer to the full
description for more information.
TAB
The TAB tag provides simple alignment capabilities without the more
complex TABLE structure. <TAB ID=abc> defines a tab named 'abc' at
the current horizontal position in the line; this can occur within
ordinary text to indicate an alignment position that can be used in
subsequent lines. <TAB TO=abc> adds horizontal whitespace in the
current line up to the position of the previously defined tab 'abc'.
FONT attributes
The FONT tag accepts the FACE attribute, which takes a
comma-separated list of typeface names. If the first typeface listed
is available on the system, that font is used; if the first isn't
available, the renderer checks the second font, and so on until it
runs out of fonts in the list or one of the fonts is available.
BASEFONT attributes
CLEAR works for most block-level tags
UL extensions
OL extensions
For the OL tag, the SEQNUM attribute is equivalent to the START attribute.
List Headers (LH)
HTML TADS supports the HTML 3.0 <LH> tag. This tag comes
immediately after a UL or OL tag, and prior to the first LI tag in
the list. LH is a container tag; the material between the open and
close tags constitutes the list header. The list header is set in
boldface, on a new line aligned left at the same indent level as the
material immediately preceding the list.
HR SRC
Deviations from Standard HTML 3.2 Tag Behavior
I've tried to keep HTML TADS as faithful to the HTML 3.2 standard as
practical. However, since HTML TADS is a somewhat different application
than the designers of HTML had in mind, I've had to take some liberties
to adapt the language to use in adventure games. For the most part, the
tags that directly pertain to formatting follow the standard; most of
the exceptions are related to the structural differences between an
adventure game's displays and standard HTML documents.
BODY element
The BODY element can appear multiple times per document, unlike
with standard HTML renderers. Each time <BODY> appears, any
attributes (such as the background color or text color) replace the
previous settings for those attributes; these settings affect the
entire window.
TITLE element
The TITLE element is optional, and can appear multiple times (HTML
3.2 requires exactly one TITLE element per document). The text
given in the TITLE element is applied at the point the TITLE
element is reached for the first time in the course of actually
drawing the page (so titles are not re-applied upon scrolling a
previous title back into view); each new title simply replaces any
previous title.
PRE, LISTING, XMP elements
The WIDTH attribute is not supported for these tags, but it is
accepted and ignored by the parser. (This isn't really a deviation,
since WIDTH is only a hint to the renderer, and its behavior is
defined by each renderer.)
OL and UL tags
The COMPACT attribute is accepted but has no effect. (Since the
COMPACT attribute's meaning is renderer-defined, this is not actually
a deviation from the standard).
<A> element
The NAME, REL, and REV attributes are accepted but ignored. The HREF
attribute is interpreted not as a URL, as it would be by a normal
browser, but as a command to be entered if the player clicks on the
link (see the section
on <A HREF> changes.)
IMG element
<IMG SRC="images/navbar.jpg" USEMAP="#navmap">
<MAP NAME="navmap">
... etc ...
MAP element
You can re-use a MAP element's name in multiple maps. At any given
time, the most recent occurrence of a map with a given name simply
replaces any previous occurrences of maps with the same name. This
allows you to generate output containing the map for an image each
time you display the image, without worrying about whether the map
was displayed previously.
AREA element
The SHAPE=POLY feature of the AREA tag is accepted, but is currently
ignored. An AREA defined with SHAPE=POLY will effectively be a null
area, and will never be hit. For now, you should use AREA=RECT or
AREA=CIRCLE instead, approximating the polygon with a set of these
other shapes.
TABLE element
Unimplemented HTML 3.2 tags
The following tags from standard HTML 3.2 are unimplemented:
HEAD
BASE
ISINDEX
STYLE
SCRIPT
LINK
META
NXTID
FORM
INPUT
SELECT
OPTION
TEXTAREA