Note: This document is a draft, comments are requested, please direct comments to lynx-drafts@trill-home.com.
There are several aims this document attempts to fulfill, yet two among them are most important. The chief aim of this document is to provide web authors with a simple guide to the most essential HTML elements supported by Lynx and by means of pithy descriptions permit them to evaluate Lynx's behaviour and make decisions on the style of marrkup they use. In the process it is hoped that authors will realize just how little it takes to make a document readable for Lynx users and how readily they can create documents that are "Enhanced for Lynx" which would loosely translate into "available to almost anyone, using a functional web browser".
Lynx supports all HTML 3.0 and 3.2 tags and contains support for the Cougar DTD and the Object draft. There are several excellent guides to HTML listed in the Table of Contents, this document is not one of them. It has a very limited scope and vision and largely revolves around the Lynx browser. However, it is a general rule that Lynx is inherently suited to rendering documents structured by HTML. Therefore it seems reasonable that someone concerned about the manner in which their resources are made available to Lynx users will also consider the larger implications of markup, and particularly of HTML. For this document, and for my own work, I've used the HTML 3.0 draft as the benchmark.
[ToC]
The use of frames is controversial since they are not a part of the HTML DTD, in addition it appears as if frames (as they are being used) are a poor substitute for HTML 3's BANNER element. For some general comments about the current FRAMEs implementation, take a look at What's wrong with frames. Regardless, Lynx does provide some support for Frames (in Lynx 2.6 and later). A typical Frame will result in the following rendered document in Lynx:
Sarnath: Adventures in Quailspace
(p1 of 2)
FRAME: header
FRAME: quailspace
FRAME: main
FRAME: sarnath
A Message from Quailspace
.....
A link is created for each frame (using the NAME attribute) and activating that link takes the user to the URL specified with the SRC attribute for the Frame. In this manner, the content of the frame is made accessible to the user. Since frames are primarily of use to graphical clients, and character-based browsers cannot support frames as authors intend to use them, we recommend that an alternate block of text be supplied using the NOFRAMES tag for users working with character-based browsers.
The official demise of HTML3 and the FIG element -- both of which would have, in my opinion, greatly enhanced the functionality of HTML -- is particularly sad for Lynx users since FIG would have provided a real alternative to images and imagemaps. In any case, since v2.5 Lynx can auto-generate links for all image tags in a document. Generally, the contents of the ALT attribute are used to generate the text that is anchored to the URL defined in the IMG tag's SRC attribute. However, in the special case where the IMG is itself anchored to another document, Lynx will create a link to the image's URL labelled [IMAGE] and set it off from the ALT text by inserting a hyphen '-'. For example, the markup:
would be rendered as:
Me-[IMAGE]
Where Me would be anchored to my-page.html and [IMAGE] would be anchored to my-pic.gif Lynx's ability to links to images on the fly should not affect the use of ALT, except perhaps to encourage the inclusion of some information regarding the size of the image (when appropriate). Read A.J. Flavell's notes on authoring for text-mode browsers for a longer deliberation on how to write a contextually appropriate ALT tag. If you're using FORMs and <INPUT TYPE=image> (perhaps to gather information for a cgi that processes imagemap-like information) take a look at Alan's INPUT TYPE=IMAGE page.
Lynx contains support for the OBJECT tag, which is a general purpose tag to provide for the inclusion of various objects within HTML documents. OBJECT is preferred to IMG or FIG since it is more general and provides the functionality of FIG when it comes to marked-up alternative text.
Currently Lynx can do very little with Tables, it does break lines at every new table row and will insert spaces between every new table cell, but it cannot align columns. There are options available to webmasters, server side includes which will preformat tables for Lynx, and these are listed under Patches for Lynx. It is possible that Lynx may have better table handling in the future, but this currently requires so much work that no one has come forward to work on it. We can only suggest that tables be used only when necessary, unless column alignment is unimportant for the content to be readable/comprehensible.
A. J. Flavell's comprehensive TABLEs on non-table browsers page lists various techniques that can be used to arrive at a markup style that formats tables correctly on as many browsers as possible
The use of client side imagemaps is encouraged. The preferred method for creating CLient Side Imagemaps is by using the OBJECT tag with teh SHAPES attribute. The OBJECT draft provides more details on how to use OBJECT to create cline side maps.
Lynx 2.5 and later also include support for USEMAPs. The use of alt text for the AREA element within MAP is encouraged. Similarly, defining a TITLE attribute for MAP will give Lynx users an inkling of what the map is. Lynx handles maps by generating a link to another document, the linked text contains the value of the TITLE attribute for the MAP element. If this attribute is not defined, Lynx uses the alt text for the associated img tag. If no ALT text is provided for the image, Lynx will use [USEMAP] as the link text. Activating the link will generate a document containing a list of the various URLs contained in the MAP. If the AREA elements have alt tags, Lynx will use this text to generate links to the URL defined as the HREF attribute. A short guide to Client Side Imagemaps describes USEMAP implimentation. The Internet draft defines the USEMAP functionality accurately
There are a number of markup tags that describe characters enclosed within them. Lynx recognizes these and does as much as it can with them. <B>, <EM>, <I>, <STRONG>, <U> and <BLINK> are generally rendered as underlined text. <DEL>, <S> and <STRIKE> are rendered with the text to be struck enclosed within "[DEL: " and " :DEL]" for example:
<s>This text is to be struck from the record</s>
will be rendered as:
[DEL: This text is to be struck from the record :DEL]Where the [DEL: and :DEL] will be underlined. Similarly, insertion marked-up by <INS> are rendered by text within [INS: and :INS]
<BIG>, <CODE>, <DFN>, <KBD>, <SAMP>, <SMALL> and <TT> are given no special treatment by Lynx since all text is rendered in one monotype font.
Lynx links | Subir Grewal | lynx-drafts@trill-home.com.