> 1) When COLSPEC is specified on a TABLE with UNITS=RELATIVE, do we assume that
> the table width is to be the total available width (e.g. all the space
> between the margins)?
o The parser should determine the minimum and maximum width requirements
for the table in the usual way.
o If the sum of the minimum widths is greater than the space between the
margins, then set the column widths to their minimum values. You would
probably increase the widths beyond this, sufficient to satisfy the
relative width specification given by the COLSPEC attribute.
o If the sum of the maximum widths is greater than the space between the
margins, then allocate the difference between the space between the
margins and the sum of the minimum widths in such a way as to satisfy
the relative width specification given by the COLSPEC attribute. If
the COLSPEC attribute is missing, then allocate the budgeted space
between the columns proportional to the difference between the
max and min requirements for each column.
o If the sum of the maximum widths is less than the space between the
margins, then use these widths, increasing them where necessary to
satisfy the relative width specification given by the COLSPEC
attribute.
This sounds hard, but is in fact a short piece of code.
> Also, what format are relative column widths in? Are they expressed as a
> percentage of the total width (e.g. 50 being half the width) or are they
> expressed as a floating point number (0.50 being half the width) or what?
I would feel most comfortable with using numbers representing the percentage
of the final table width. This isn't critical though, as you can divide the
numbers given by their summed value to obtain the fractional widths. Are
people happy with a convention for percentage widths?
> 2) When OVERLAY is used with the SEQ attribute, how is the browser to know
> when to display the next overlay in a sequence? For that matter, how is
> the browser to know which overlays are in a sequence? Do they have to all
> have the same size and position, or what?
If the SEQ number is missing or zero, the overlays should be displayed
immediately in the order they occur in the HTML document. If there are
overlays with a non-zero sequence number, the browser should provide a
mechanism for stepping through the overlays in ascending sequence number.
> 3) When image resolution is not possible/turned off, how are the contents of
> a FIG handled? Is the CAPTION ignored? Are anchors with SHAPE ignored?
> If not, how are they treated?
I am not sure I understand this question. If the FIG has width and height
attributes that are different from that of the linked image, then, if
practical, the image should be scaled to the values given by the attributes.
Netscape works this way, I believe. If the image can't be scaled, then, the
hotzones defined by SHAPE attributes should be mapped to the displayed size
of the image from the desired size as defined by the width and height
attributes. Captions should always be shown, although, I guess that browsers
could reduce the font size for small figures with lots of caption text.
> Is it necessary to have the ISMAP attribute on a fig if shaped anchors are
> being used, or does the existance of the anchor as part of the fig imply
> ISMAP?
ISMAP is only needed when you want to send image clicks to the server, e.g.
because some kind of database lookup is needed. Hotzones take priority over
sending clicks to the server, though. Note that future graphics formats,
such as the portable bitmap format (PBF), may include image map data as
part of the graphics format.
> 4) What are the entity names defined in HTMLicons?
This will be included in the Internet Draft. They were created by Bert Boz
and were part of the HTML+ DTD:
<!ENTITY ftp SDATA "ftp" -- ftp server -->
<!ENTITY gopher SDATA "gopher" -- gopher server -->
<!ENTITY telnet SDATA "telnet" -- telnet connection -->
<!ENTITY archive SDATA "archive" -- archive server -->
<!ENTITY filing.cabinet SDATA "filing.cabinet" -- filing cabinet -->
<!ENTITY folder SDATA "folder" -- folder or directory -->
<!ENTITY fixed.disk SDATA "fixed.disk" -- fixed media drive -->
<!ENTITY disk.drive SDATA "disk.drive" -- removeable media drive -->
<!ENTITY document SDATA "document" -- unspecified document type -->
<!ENTITY unknown.document SDATA "unknown.document" -- unrecognised document type -->
<!ENTITY text.document SDATA "text.document" -- text/plain, text.html etc.-->
<!ENTITY binary.document SDATA "binary.document" -- binary data -->
<!ENTITY binhex.document SDATA "binhex.document" -- binhex format -->
<!ENTITY audio SDATA "audio" -- audio sequence -->
<!ENTITY film SDATA "film" -- film or animation, such as an MPEG movie -->
<!ENTITY image SDATA "image" -- photograph, drawing or graphic of any kind -->
<!ENTITY map SDATA "map" -- geographical or a schematic map -->
<!ENTITY form SDATA "form" -- fill-out form -->
<!ENTITY mail SDATA "mail" -- email messages -->
<!ENTITY parent SDATA "parent" -- parent of current document -->
<!ENTITY next SDATA "next" -- next document in current sequence -->
<!ENTITY previous SDATA "previous" -- previous document in current sequence -->
<!ENTITY home SDATA "home" -- home document -->
<!ENTITY toc SDATA "toc" -- table of contents -->
<!ENTITY glossary SDATA "glossary" -- glossary of terms etc. -->
<!ENTITY index SDATA "index" -- searchable index -->
<!ENTITY summary SDATA "summary" -- summary -->
<!ENTITY calculator SDATA "calculator" -- A calculator -->
<!ENTITY caution SDATA "caution" -- Warnign sign -->
<!ENTITY clock SDATA "clock" -- A clock -->
<!ENTITY compressed.document SDATA "compressed.document">
<!ENTITY diskette SDATA "diskette" -- A diskette -->
<!ENTITY display SDATA "display" -- A computer screen -->
<!ENTITY fax SDATA "fax" -- A fax machine -->
<!ENTITY mail.in SDATA "mail.in" -- mail-in tray -->
<!ENTITY mail.out SDATA "mail.out" -- mail-out tray -->
<!ENTITY mouse SDATA "mouse" -- mouse/pointing device -->
<!ENTITY printer SDATA "printer" -- hardcopy device -->
<!ENTITY tn3270 SDATA "tn3270" --tn3270 terminal session -->
<!ENTITY trash SDATA "trash" -- waste paper basket -->
<!ENTITY uuencoded.document SDATA "uuencoded.document" -- uuencoded data -->
The precise list needs to be reviewed for completeness/coverage.
> 5) What is the scope of a TAB definition? Can a tab stop be removed/changed?
The scope of a TAB definition is the rest of this document. Because tab stops
are given unique names (SGML IDs), there is no need to remove/change a tab
stop. You just define a new one with a different name.
> If a TAB has center/right alignment and the next TAB has none defined,
> does the alignment continue for the next TAB or does it revert to left?
My interpretation of this situation is that the text following the right tab
is right justified up to the position of the next TAB element, and text
following that is left justified to that tab stop.
> What if the text goes past the next tab stop without a TAB tag? Does the
> alignment change, or stay the same?
How can this occur with named tab stops? The question still arises as to how
to handle tabs when the text has already gone past this position. I guess there
are two ways: either to simply reposition the text and overwrite any underlying
text, or to ignore the tab stop and continue after some notional whitespace.
The latter seems preferable.
> 6) What are the definitions of the LANG and AU tags?
The LANG attribute is used with the ISO language abbreviations, e.g. en_uk
is English as spoken in the UK, while en_us is English as spoken in the USA.
Is it worthwhile including a list of these in the Internet Draft? The AU tag
is borrowed from ICADD and is used when you want to markup an author's name.
This can be used for searching etc.
> 7) What is the "typical" appearance of a FILE or SCRIBBLE input?
The FILE widget would be button to invoke a file selection dialog plus
a single line text field to show the current selection. If more than one
file is selected then I guess you could show the most recently selected
one or the first one in the list. The Arena multiple selection widget
works this way. I would also allow users to type or paster into this
field directly.
The SCRIBBLE field is sized to the accompanying image when this is
specified with the SRC attribute. Otherwise, the width and height are
given with the SIZE attribute in that order, as in size="100, 32".
Ideally, the mouse cursor would change to a pen or similar when
over a scribble widget. Note that scribble fields can't be relied
on since some users will be using terminal based clients like Lynx
without the means to "scribble". In this situation, we may want to
allow the user to type characters into the field instead. What do
you think?
> 8) What should be done when an AUDIO input is specified but the platform does
> not support audio?
This is a similar case to IMG. Perhaps clients should silently ignore it?
-- Dave Raggett <dsr@w3.org> tel: +44 272 228046 fax: +44 272 228003
Hewlett Packard Laboratories, Filton Road, Bristol BS12 6QZ, United Kingdom