Note that I have extended the comments in the 3.0 DTD to try and
clear things up for people. The DTD is now available from CERN at:
and can be found by following the links from the technical pages for html.
> o I'd like to put in a bid for disallowing nested tables, and I also
> question the need for vertical alignment in a table cell. Yeah, you can
> probably think of cases where someone could use them, but are they really
> all that useful?
Vertical alignment is useful when you want to use a table to align the
centers of several cells on the same row. Most table models support this
feature. Neither this, nor nesting present great problems for implementors.
> I also would question whether COLSPEC is truly desirable. What should be
> done in the case where the cell contents are too large for the width
> specified by COLSPEC?
This is up to browsers to decide how to handle. They could simply clip the
cell contents to the specified width, allow over-runs, or revert to sizing
the column based on the contents of all cells in that column. In any case,
authors are recommended to choose the colspec widths to be larger than the
minimum needed to avoid problems. For instance, specifying the column width
in pixels when the cells contain text is asking for problems. When using
em units which scale in terms of the current font, remember that font metrics
vary so include some leeway just to make sure. With relative widths the
problem is avoided as this way the widths are assigned only after determining
the min/max widths needed for each column.
The reason for specifying explicit widths (em/pixels) is to allow the browser
to start displaying the table with out having to wait until its parsed all
the rows. This can be important with large tables and slow network connections.
> o Since FN has been revealed to be a footnote element, is it semantically the
> same as the HTML+ FOOTNOTE element, or is it different?
FN is indeed the same. I have adopted the shorter name after a suggestion
from Yuri for compatibility with ICADD. It would best be rendered as a simple
pop-up pane (on GUI) interfaces; alternatively as a hypertext link to (say)
the end of the document as used by the emacs w3 browser.
> o What is the need that is being addressed by the POSITION attribute on the
> BODY element? I can see how ALIGN would be useful for specifying default
> horizontal alignment in a body section, but what is this business about
> attaching it to one side of the window?
The idea here is to allow authors to divide the browser window up into
one or more fixed panes which don't scroll with the rest of the document.
These can be used for navigation elements, for copyright and security
messages (e.g. company confidential) or for brand messages/icons.
> o I take it that the BLEEDLEFT and BLEEDRIGHT alignment values on the FIG
> element have been superceded by the CLEAR attribute?
No. These are alignment positions. Figures can be aligned with the text
margins (align=left or align=right). They can also be flush left/right
to the window borders (align=bleedleft or align=bleedright). An example
of the difference is included with the Arena demo.
> o So, when a FIG has ALIGN=CENTER the browser automatically positions
> subsequent elements down past the FIG?
Yes, and the same holds for tables. (I seem to forgotten to add the colspec
and align attribute to the table element and will fix this right away).
> o What does ALIGN=JUSTIFY do?
If the browser supports this, the text is adjusted by altering the spacing
between words (and optionally characters), to align the left and right ends
of text lines with the margins, just like you see in printed material.
Most browsers will treat this as align=right and produce text with a ragged
right margin. I have included it in the draft HTML 3.0 DTD to allow
commercial developers to differentiate themselves from simpler implementations.
-- Dave Raggett <email@example.com> tel: +44 272 228046 fax: +44 272 228003 Hewlett Packard Laboratories, Filton Road, Bristol BS12 6QZ, United Kingdom