- From: Arnoud <galactus@htmlhelp.com>
- Date: Sun, 17 Nov 1996 20:23:37 +0100
- To: www-html@w3.org
-----BEGIN PGP SIGNED MESSAGE-----
These are some observations on the HTML 3.2 draft from 05 november 1996[0].
First, the latest full version of the DTD that I could find at
http://www.w3.org/ was dated August 21st. The version of the DTD included
in the PR draft was dated September 18th.
While I would love to engage in a rant about how the current draft
is aimed towards graphical browsers beginning with N or I, I won't
do that here. I can only say I hope the next version will promote
the platform-independent solutions instead of the HTML hacks included
in "Wilbur".
In the section on LINK, the explanation on the REV attribute suggests the
use of "made" as value, to include a link to the author's homepage or the
use of mailto URL with his e-mail address. This suggestion does not appear
in the list of common values.
In the section on the BODY element, the text states that the 16 color names
given are widely understood. It is my experience that not all user agents
which understand body colors also understand the color names, and those that
do do not always use the same color values. I would suggest that the
specification at least recommends the use of color codes instead of
color names.
The section on BLOCKQUOTE notes that block quotations are often rendered
as indented text. Is such a note necessary? It often leads to confusion
about the purpose of this element -- on Usenet, I see daily claims that
<BLOCKQUOTE> is the "indent tag".
The section on FORM states that the ACTION attribute may only contain an
HTTP or mailto URL. Even though they are the most popular ways to handle
a form, why this restriction? I do not see a reason why other ways to handle
forms would not be possible.
And surely "HTTP server" should be "HTTP URL"?
In the section on tables, there is a paragraph which reads:
A common approach, introduced by Netscape, renders tables in
bas-relief, raised up with the outer border as a bevel, and individual
cells inset into this raised surface. Borders around individual cells
are only drawn if the cell has explicit content. White space doesn't
count for this purpose with the exception of .
This introduces the question whether is now defined as whitespace
or not. If the entity is not whitespace, the "exception" makes no sense.
However, if the entity *is* to be regarded as whitespace, the specification
should note that repeate use should be treated like repeated spaces and
should be collapses. This would be contradicting "common use". As I have
asked before, can the HTML 3.2 specification define the effects of
multiple entities in a row?
The definition of the caption reads
<!ELEMENT CAPTION - - (%text;)* -- table or figure caption -->
which raises the question what "figure" this refers to.
In the section of phrase elements:
CITE used for citations or references to other sources
Should this be interpreted as "short citations from other works", as in
<CITE>To be or not to be?</CITE>? If not, a note that this is *not* an
element to mark up short citations would be advisable.
In the section on IMG it should be noted that currently only GIF, JPEG and
PNG images can be inlined. The explanation on the ALT attribute should note
that no markup, only entities, can be used therein, and that it is also
used in graphical browsers where image loading is disabled.
And a note that some user agents incorrectly truncate ALT text if it does
not fit in the "box" defined by the WIDTH and HEIGHT attributes would be
helpful.
The explanation on WIDTH and HEIGHT states "suggested width|height" of the
image. Does this mean that specifying image size which is not the same as
the actual size is not in error, and that the browser should use the values
from these attributes to render the image?
Slightly lower:
border
When the IMG element appears as part of a hypertext link, the
user agent will generally indicate this by drawing a colored
border (typically blue) around the image. This attribute can be
used to set the width of this border in pixels. Use border=0 to
suppress the border altogether.
The colored border is not typically blue, it is typically the color used
to indicate links, as specified by the LINK attribute on BODY.
derived URL will be: "/cgibin/navbar.map?10,27". It is generally a
good idea to suppress the border and use graphical idioms to indicate
that the image is clickable.
This is a design issue, and not something that should be recommended in
a specification.
In the section on APPLET:
[on the contents of this element]
browsers ignore this extra HTML code. You can use it to show a
snapshot of the applet running, with text explaining what the applet
does. Other possibilities for this area are a link to a page that is
more useful for the Java-ignorant browser, or text that taunts the
user for not having a Java-compatible browser.
While I agree with the concept of encouraging people to use the contents
of APPLET to provide an alternative, something like "Click here to
download a Java-enabled browser" should never be recommended in a
specification. What if the user _has_ a Java-compatible browser (or OS)
but has turned this off for security reasons?
The term "Java-ignorant" suggests that having Java support is somehow
better than not having it. Would something like
Other possibilities for this area are a link to a document that
presents the content of the document without the requirement
for Java support.
Slightly lower:
alt = alternateText
This optional attribute specifies any text that should be
displayed if the browser understands the APPLET tag but can't
run Java applets.
Surely it would be possible that a Java-capable browser renders the
contents of the APPLET element when Java support is disabled by the
browser? Since the ALT text is nowhere near as useful as the content
of APPLET, I don't see any reason to include it.
The DTD specifies FONT's attribute COLOR as
color CDATA #IMPLIED -- #RRGGBB in hex, e.g. red: color="#FF0000" --
but the discussion on color below states
Used to set the color to stroke the text. Colors are given as
RGB in hexadecimal notation or as one of 16 widely understood
color names defined as per the BGCOLOR attribute on the BODY
element.
which seems in conflict with the comment in the declaration above.
Some user agents also support a FACE attribute which accepts a comma
separated list of font names in order of preference. This is used to
search for an installed font with the corresponding name.
I would suggest that a note about using style sheets instead of FONT is
recommended.
As for the following paragraph:
The following shows the effects of setting font to absolute sizes:
size=1 size=2 size=3 size=4 size=5 size=6 size=7
as well as the next examples, these do not make sense to me. Either this
is an attempt to demonstrate how to enumerate from 1 to 7, or an attempt
to demonstrate what FONT SIZE "does". I have seen this quite a few times
in "HTML references" which use the element itself to demonstrate how it
"works", but never in a specification. If I use Lynx to read this part,
I could now conclue that setting the font to absolute sizes has no
effect at all!
The discussion on the BR element's attribute CLEAR seems to suggest that
it only applies to floating images. Since tables can also be floating
(as in <TABLE ALIGN=LEFT>) it would seem that the BR element can be used
to start rendering below the floating table.
In the section on client-side imagemaps (MAP):
The MAP element provides a mechanism for client-side image maps. These
can be placed in the same document or grouped in a separate document
although this isn't yet widely supported. The MAP element requires
I would suggest that the note on no widespread support for maps in
separate documents be removed. This is clearly a bug in Netscape, just
like the inability to honor <TABLE ALIGN=CENTER> properly. And there's
no note in the TABLE section that CENTER is not widely supported.
<!ENTITY % SHAPE "(rect|circle|poly)">
<!ATTLIST AREA
shape %SHAPE rect
coords %COORDS #IMPLIED -- always needed except for shape=default --
As noted before on this list, the 'default' shape is missing. This is
an annoyance, since it prevents me from defining a default action in
a client-side imagemap.
There is no explanation on the ALT attribute for AREA.
If two or more regions overlap, the region defined first in the map
definition takes precedence over subsequent regions. This means that
AREA elements with NOHREF should generally be placed before ones with
the HREF attribute. AREA elements with shape=default should be placed
last of all, as otherwise none of the other AREA elements will have
any effect.
This paragraph is somewhat confusing to me. Why should a NOHREF area
be placed before HREF areas? And why would in the next example
<AREA SHAPE=default HREF="http://www.htmlhelp.com/reference/wilbur/">
<AREA SHAPE=circle COORDS="10,10,5" HREF="http://www.w3.org/">
every location in the image go to the Wilbur reference? It seems to
me that the *intention* of the (undefined) default shape is to cater
for undefined areas only.
The note on HTML content models states:
<!--
HTML has three basic content models:
%text character level elements and text strings
%flow block-like elements e.g. paragraphs and lists
%bodytext as (b) plus headers and ADDRESS
- --> ^^^
|||
but I do not see a section (b) in this list. Shouldn't this be "as %flow
plus headers and ADDRESS"?
Typos
(I'm not sure if this belongs on this list, but I noticed them anyway :-)
Line 557: "attributes" should be "Attributes"
Line 1,087: "&nsbp;" probably should be "&nbsp;"
Line 1,681: "cgibin" should be "cgi-bin" as this is more common.
Line 1,795: "such é" should be "such as é"
Line 2,077: 19960821 should read 19960918
Line 2,081: 19960821 should read 19960918
Line 2,200: "#HHHHHH @@ details?" probably needs to be updated
[0] http://www.w3.org/pub/WWW/TR/PR-html32-961105
Galactus
who will now update his reference to adhere to the latest version :-)
- --
E-mail: galactus@htmlhelp.com .................... PGP Key: 512/63B0E665
Maintainer of WDG's HTML reference: <http://www.htmlhelp.com/reference/>
-----END PGP SIGNED MESSAGE-----
Received on Sunday, 17 November 1996 15:02:40 UTC