Symptoms:

In the manual page titled 'HTML coding and style guidelines for Ghostscript
documentation', there are some guidelines that contradict their intended goals:

Chapter 'Anchors: <a name="...">' uses an empty anchor format that is prone to
accidental editing mistakes.

Chapter 'Anchors: <a name="...">' suggests that anchor should be placed inside a
structure such as a paragraph, indented paragraph, list item, or head.  If there
is a need to add block level items (eg: paragraphs, list items, or headings)
between an anchor and the contents immediately after the anchor, it may play
havoc to automated web page composers, and .

Chapter 'Lists: <ul>, <ol>, <dl>' claims that 'Where entries in a descriptive
list <dl> contain extended descriptions <dd> -- especially if the descriptions
contain paragraph breaks or tables -- improve the spacing between entries by
making each entry a separate list.'  However, this advice does not take into
instances where use of recursive lists are required, such as describing file
format structures containing 2 or more levels.  In addition, it is generally a
bad idea to use HTML tags for text formatting, especially when Ghostscript
manual already uses CSS.

In a similar fashion, chapter 'The use of different font faces' is recommending
<font> for table headings and extended <pre> examples, <b> for emphasis, <small>
for superscripts.  These tags are clearly designed for changing document's
presentation, not structures.  Using them defeats the purpose of stylesheets.

In chapter 'Specific guidelines for coding tables', guideline 4 is using
attribute rather than CSS to align cell contents.  Guideline 5's requirement of
begin every other column on a separate line can reduce document's readability,
when a table consist lots of small cells.  Guildeline 6, which suggests adding
empty column of nonbreaking spaces between 2 columns of substantive material,
only serves to mangle document structure and offer no benefits over CSS-based
cell spacing and padding.  Guidelines 7 and 8 serves no purposes but to create
bloated code and encourage the use of broken browsers.  Even Internet Explorer
properly aligns visually empty cells that do not have nonbreaking spaces, making
Guideline 8 obsolete.

In chapter 'Tags not used', it forgets to mention that if an HTML document uses
a non-W3C default DTD, elements <dd>, <dt>, <li>, <p>, <tr>, <th>, and <td> may
require closing elements (in the case of XHTML, there is no optional end tags).
 In addition, there is no mention of whether Ghostscript manual should be
written in HTML or XHTML, or what type of HTML DTD to be used.

In chapter 'Miscellany', manually adding angle brackets to email addresses can
lead to accidental errors by HTML author, and should be replaced by automatic
mechanism.  The guideline also recommends the use of <small> tag, rather than
relying on CSS.

The guide does not address the any requirement for character encoding used by
the document iteself, which can cause problems for localization developers.

The guide does not address the default visual formatting models for any element
specified by the 'HTML coding and style guidelines', which can lead to
non-standard display of doucments when contributors use CSS to format
Ghostscript manuals, especially when CSS 2 or later is used.

Suggested fix, if any:

Chapter 'Anchors: <a name="...">' should use an empty anchor format '<a
name="..." />', which is legal in HTML and XML specifications, and is tested to
work with standard compliant browsers.

Chapter 'Anchors: <a name="...">' should be changed to place an anchor
immediately before the beginning of a paragraph (indented paragraph, list item,
head, etc.), to make Ghostscript manual more maintainable when using automated
web page composers.

In chapter 'Lists: <ul>, <ol>, <dl>', descriptive list should NOT enclose each
entry in a separate list.  To achieve the intended visual formatting, use
'margin' property for <dt> element in Ghostscript's default stylesheet (gs.css).
 Similarly, chapter 'The use of different font faces' should recommend only <em>
for emphasis, only <strong> for strong emphasis, only <thead> and <th> for table
headings, only <sup> for superscripts.  Any specific formatting requirements for
the texts within the tags should be implemented using default stylesheet.

In chapter 'Specific guidelines for coding tables', guideline 4 should describe
a generic method of aligning cell contents to the top.  Guideline 5's
requirement of begin every other column on a separate line should be limited to
rows with at least 1 cell containing multi-line contents.  Guideline 6 should be
replaced by CSS-based cell spacing or padding alternative.  Guidelines 7 and 8
should be removed.  To accomodate the change of Guideline 6, horizontal cell
spacing should be set to at least 1 em space.  The goal of original guideline 7
must be changed by using 'border' property in CSS to add borders only on top or
bottom of a table row.  For any guideline, any references of HTML formatting
should be put into default stylesheet.

In chapter 'Tags not used', it should be changed to 'If a document's own format
and DTD combination supports optional end tags for a given element, do not use
the end tag.  For specific tags that supports end tags, consult HTML
specification and the DTD settings used by Ghostscript manual.'  For a long term
solution to avoid any future problems on handling optional end tags, HTML coding
and style guidelines should require compliant Ghostscript HTML document to use
only pure HTML (not XHTML) 4.01 document, using standard DTD
(http://www.w3.org/TR/html4/loose.dtd
 for transitional DTD, http://www.w3.org/TR/html4/strict.dtd for strict DTD,
http://www.w3.org/TR/html4/frameset.dtd for frameset DTD).

In chapter 'Miscellany', visible email addresses should be enclosed by angle
brackets using content generators provided by CSS, by adding 'content' property
to ':before' and ':after' pseudo-elements.  For accomodate user agents that
don't support 'content' property, square bracket should be used instead of angle
brackets to reduce file size and improve HTML source readability.  Exponents
should be enclosed by only <sup>, and use CSS property on <sup> to emulate the
visual effect of <small>.  As a result, the example in the chapter becomes the
following:

Something^<sup>exponent</sup>

To accomodate the need of localized manuals, HTML coding and style guidelines
must require Ghostscript HTML document to include explicit declaration of
document encoding.  For the default English Ghostscript HTML document, that
means adding following code to the <HEAD> section:

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

Unless there are relevant accessibility issues when using fully standard
compliant user agents to read Ghostscript manuals, HTML coding and style
guidelines must require all HTML elements to use default visual formatting
models.  For example, when CSS 2.1 is used, that means only HTML elements TABLE,
TR, TBODY, THEAD, TFOOT, COL, COLGROUP, TD, TH, CAPTION can use CSS 'display'
property values 'table', 'table-row', 'table-row-group', 'table-header-group',
'table-footer-group', 'table-column', 'table-column-group', 'table-cell',
'table-cell', and 'table-caption' respectively.  If alternate visual formatting
models are needed, those settings must not replace Ghostscript's default
settings.  A standard approach is to put alternate stylesheet settings into
separate files.