The W3C vendors did not retain NOTE in the HTML 3.2 draft.
It will degrade gracefully for WWW browsers which do not support
NOTE, except for recognition of the ID attribute as a named
Anchor.
Lynx and HTML Lists
Lynx implements the HTML 3.0 list elements UL (Unordered List),
OL (Ordered List), and DL (Definition List), and their
associated attributes, and elements (LH, LI, DT, and DD) for the
most part as described in that specification. The lists can be
nested, yielding progressively greater indentation, up to six
levels. The HTML 2.0 MENU and DIR elements both are treated as
synonyms for UL with the PLAIN attribute (no bullets, see
below). Note, thus, that neither DIR nor MENU yields a series of
columns with 24-character spacing. A single nesting index is
maintained, so that different types of List elements can be used
for different levels within the nest. Also, the HTML 3.0 FIG,
CAPTION and CREDIT elements are treated as valid within list
blocks. They will be rendered with indentation appropriate for
the current nesting depth, and the CAPTION or CREDIT elements
will have a CAPTION: or CREDIT: label beginning the first line
of their content. The content of any APPLET or OBJECT elements
in the lists also will be indented appropriately for the current
nesting depth, but those will not invoke line breaks unless
indicated by their content, and it should not include markup
which is inappropriate within the list.
Lynx also supports the TYPE attribute for OL elements, which can
have values of 1 for Arabic numbers, I or i for uppercase or
lowercase Roman numerals, or A or a for uppercase or lowercase
letters, that increment for successive LI elements in the list
block. The CONTINUE attribute can be used to continue the
ordering from the preceding list block when the nesting depth is
changed.
Lynx treats the OL attributes START and SEQNUM as synonyms for
specifying the ordering value for the first LI element in the
block. The values should be specified as Arabic numbers, but
will be displayed as Arabic, Roman, or alphabetical depending on
the TYPE for the block. The values can range from -29997 to the
system's maximum positive integer for Arabic numbers. For Roman
numerals, they can range from 1 (I or i) to 3000 (MMM or mmm.).
For alphabetical orders, the values can range from 1 (A or a) to
18278 (ZZZ or zzz). If the CONTINUE attribute is used, you do
not need to specify a START or SEQNUM attribute to extend the
ordering from a previous block, and you can include a TYPE
attribute to change among Arabic, Roman, or alphabetical
ordering styles, or their casing, without disrupting the
sequence. If you do not include a START, SEQNUM or CONTINUE
attribute, the first LI element of each OL block will default to
1, and if you do not include a TYPE attribute, Lynx defaults to
Arabic numbers.
For UL blocks without the PLAIN attribute, Lynx uses *, +, o, #,
@ and - as bullets to indicate, progressively, the depth within
the six nesting levels.
Lynx treats UL, OL, DIR, and MENU blocks as having the COMPACT
attribute by default, i.e., single spaces between LH and LI
elements within those blocks. For DL blocks, double spacing will
be used to separate the DT and DD elements unless the COMPACT
attribute has been specified.
Lynx and HTML Quotes
The HTML 3.0 and later specifications provide for two classes of
quotation in HTML documents. Block quotes, designated by the
BLOCKQUOTE element (or it's abbreviated synonym BQ in HTML 3.0),
have implied paragraph breaks preceding and following the start
and end tags for the block. Character level quotes, designated
by the Q element, in contrast are simply directives in the
markup to insert an appropriate quotation mark.
Lynx renders block quotes with a greater than normal left and
right indentation. Lynx does not support italics, and normally
substitutes underlining, but does not underline block quotes so
as not to obscure any explicit emphasis elements within the
quotation. The BLOCKQUOTE or BQ block can include a CREDIT
container element, whose content will be rendered as an implied
new paragraph with a CREDIT: label at the beginning of its first
line.
Lynx respects nested Q start and end tags, and will use ASCII
double-quotes (") versus grave accent (`) and apostrophe ('),
respectively, for even versus odd depths in the nest.
Any ID attributes in BLOCKQUOTE, BQ or Q elements will be
treated as named Anchors.
Lynx and Client-Side-Image-Maps
HTML includes markup, designed primarily for graphic clients,
that treats inlined images as maps, such that areas of the image
within which a mouse cursor was positioned when the mouse was
clicked can correspond to URLs which should be retrieved. The
original implementations were based on the client sending an
http server the x,y coordinates associated with the click, for
handling by a script invoked by the server, and have been termed
server-side-image-maps. Lynx has no rational way of coping with
such a procedure, and thus simply sends a 0,0 coordinate pair,
which some server scripts treat as an instruction to return a
document suitable for a text client.
Newer HTML markup provides bases for the client to determine the
URLs associated with areas in the image map, and/or for a text
client to process alternative markup and allow the user to make
choices based on textual information. These have been termed
client-side-image-maps.
Lynx recognizes and processes the MAP container element and its
AREA elements, and will create a menu of links for the HREF of
each AREA when the link created for the IMG element with a
USEMAP attribute is activated. The menu uses the ALT attributes
of the AREA elements as the link names, or, if the document's
author has disregard for text clients and sight-challenged
Webizens, and thus did not include ALT attributes, Lynx uses the
resolved URLs pointed to by the HREF attributes as the link
names. Lynx uses the TITLE attribute of the IMG element, or the
TITLE attribute of the MAP, if either was present in the markup,
as the title and main header of the menu. Otherwise, it uses the
ALT attribute of the IMG element. If neither TITLE nor ALT
attributes were present in the markup, Lynx creates and uses a
[USEMAP] pseudo-ALT. The MAPs need not be in the same document
as the IMG elements. If not in the same document, Lynx will
fetch the document which contains the referenced MAP, and locate
it based on its NAME or ID attribute. All MAPs encountered in
documents during a Lynx session are cached, so that they need
not be retrieved repeatedly when referenced in different
documents.
If the IMG element also indicates a server-side-image-map via an
ISMAP attribute, Lynx normally will create a link for that as
well, using an [ISMAP] pseudo-ALT (followed by a hyphen to
indicate its association with the client-side-image-map) rather
than ignoring it, and will submit a 0,0 coordinate pair if that
link is activated. Although, the client-side-image-map may be
more useful for a client such as Lynx, because all of the URLs
associated with the image map can be accessed, and their nature
indicated via ALT attributes, Lynx-friendly sites can map 0,0
such that the server returns a for-text-client document
homologous to the content of FIG elements (see below). Inclusion
of such a link for submissions to the server can be disabled by
default via the configuration file (lynx.cfg), and the default
can be toggled via the -ismap command line switch.
Lynx also recognizes the HTML 3.0 FIG and OVERLAY elements, and
will handle them as intended for text clients. These are the
ideal way to handle client-side-image-maps, because the FIG
content provides complete alternative markup, rather than
relying on the client to construct a relatively meager list of
links with link names based on ALT strings.
The presently experimental OBJECT element encompasses much of
the functionality of the FIG element for client-side-image-maps.
Lynx will render and display the content of OBJECT elements
which have the SHAPES attribute equivalently to its handling of
FIG. Lynx also handles OBJECT elements with the USEMAP and/or
ISMAP attributes equivalently to its handling of IMG elements
with client-side-image-maps and/or server-side-image-maps.
Lynx and Client-Side-Pull
HTML includes provision for passing instructions to clients via
directives in META elements, and one such instruction, via the
token Refresh, should invoke reloading of the document, fetched
from a server with the same URL or a new URL, at a specified
number of seconds following receipt of the current document.
This procedure has been termed client-side-pull. An example of
such an element is: