My comments are presented in three sections:
- Consistency issues
- Minor clarifications or improvements
- Editorial/typographical
A few points of consistency I've recently noted which are
likely to add future confusion.
1) The SIZE= attribute has two different meanings:
<input type=text... visible size of the field
<select ... depth of the field (number of rows)
As a result there two attributes which define the depth or
number of rows.
Recommendation: Use a consistent attribute name on all tags
Possible Approaches:
a) Define SIZE= to always mean the display width, use
ROWS= on <SELECT>, change TEXTAREA use also use SIZE=
(Obsolete/deprecate COLS= on TEXTAREA)
b) Obsolete/deprecate SIZE= and COLS= everywhere. Use
ROWS= (or add DEPTH= and deprecate ROWS=) for visible display
lines. Add LENGTH= (or WIDTH=) for visible display width.
The problem is that SIZE= as depth on <SELECT> seems to already
be recognized by some (all?) browsers which suggests some form
of option (b) as causing the least grief.
>>> The inconsistant use of size didn't seem to concern anyone else.
2) The <PRE> tag WIDTH= attribute doesn't have a common practice
interpretation as far as I can tell empirically.
a) Replace WIDTH= with whatever the 'standard' attribute is for
display width from point 1 above.
b) Recommend that the sentence "If the WIDTH attribute is not
present, a width of 80 is characters is assumed." be
replaced with: "If the WIDTH attribute is not present, the
width of the longest line in the <PRE> element will be used
to control horizontal presentation."
>>> The concensus was to follow my recommendation in 2.b and since
>>> my SIZE= concern wasn't shared no change to the actual keyword
>>> is needed.
3) There is no requirement that one radio button be selected by
default if the HTML doesn't designate one as checked. Yet the
<SELECT> requires that the first item listed be selected if
not is initially marked as selected.
Recommend: Remove the default selection and instead recognize
the possibility that none will be selected.
>>> The concensus seemed to be that radio buttons really meant one
>>> must be selected which is in conflict with my recommendation but
>>> does require the standard be changed to require an implicit
>>> default of showing one (the first?) button selected if none
>>> are so indicated in the HTML. (I still prefer that the none
>>> selected be provided for both selection lists and radio button
>>> groups as I view a group of radio buttons as simply a different
>>> form of selection list.
4) Conceptually, I believe it would be more consistent to document
the <BR> tag as beginning a new line rather than ending a
previous line.
Recommend: Alter examples to show <BR> at the beginning of lines.
>>> Somehow there seemed to be a concern that novice users would feel
>>> required to write constructs of the form:
>>> <li><br>W X Y z
>>> if we lighten the implication that <br> ends a line.
>>> There was a strongly stated opinion that <br> should never have
>>> attributes which noone disagreed with. As long as <br> never
>>> has attributes I don't care if some people want to feel it ends
>>> a line and others want to feel it begins a new line as either is
>>> simply a line break. My prime concern is/was that there was a
>>> post to this group which suggested that a <br> attribute would
>>> modify the element which preceded it.
5) The COMPACT attribute only appears on the DL list. It should
appear on all list types.
>>> The concensus was that COMPACT should appear on all lists and
>>> the current form was a typo. I have now further checked and
>>> the DTD actually calls for COMPACT so this is an omission in
>>> the descriptive text only. Also, I missed it previously,
>>> section 10.6.4 shows COMPACT as an attribute for ordered lists.
>>> 10.6.2 (<DIR>), .3 (<MENU>), and .5 (<UL>) don't.
Suggested refinements:
1. The <PRE> tag should be clarified by adding:
Presentation of text on a new line will correspond to line
breaks in the input. <FORM> input fields within a <PRE>
element will utilize the same fixed-width font utilized for
surrounding text.
to the end of the first paragraph of section 10.2.
>>> I believe there was concenus that this was desireable but some
>>> concern that this wouldn't be easy for browsers depending on
>>> the features of their platform tool kits for control implementation.
>>> As I recall, the conclusion was that wording should be changed
>>> (added) but allowing for possiblity it was impossible.
2. Add whatever the common display width attribute is to the
<SELECT> tag to specify the visual width. When the 'combo'
box pops up a selection list, use the width required by the
longest selection.
>>> I think the only concensus here was that this was out of scope
>>> for consideration at this time.
3. Do we need to point out to browser developers that SELECT lists
which don't fit in the current window should be scrollable?
>>> Don't think this was discussed.
5. It should be possible for a user to deselect all radio buttons
and/or all OPTIONs in a SELECT short of resetting the FORM.
>>> Discussion mentioned above. I believe the concenus was that
>>> one radio button should always be selected and hence if the HTML
>>> didn't indicate the default, a standard default should be
>>> specified (First?).
Editorial/Typographical
1. Page 9: What happened to the   entity?
2. Page 13/para 4.2: Do we really mean to require <TITLE>
for every HTML file? ("It requires the Title element between ...")
3. I don't understand 5.3 ISINDEX -- it looks awful chicken/eggish
to me. Either the interpreter already has the document in which
case why would the user request a search by "adding a question
mark to the end of the document address" or the interpreter
(?? should this say 'user agent' or 'browser'??) doesn't have
the document in which case the <ISINDEX> tag is not seen.
I don't understand how a document URI can be unknown to the
interpreter. (page 14)
4. Page 16 refers the use of the non-breaking space and soft hyphen
indicators and discourages use.
a) At the minimum the phrase should be changed from
"because they are not" to "until they are"
b) BUT it seems to me that unless we are going to document
these entities (and we should) as part of the supported
standard this whole paragraph should be deleted. As well
as any references to these characters in the previous
paragraph.
5. (opinion) Either ignore horizontal tabs everywhere or make their
use meaningful. For example, provide a <TABGRID ...> tag
and require it to apply everywhere. Very simple tabular data
can be achieved without the mystery of tables.
6. Page 19 (section 8). Change the last paragraph to read:
Character format elements may be nested within the content of
other character format elements. HTML interpreters are
encouraged to render nested character formats distinctly
from non-nested elements:
This change doesn't make differentiation a requirement but it
expresses a stronger intent on the part of the standard.
It is very useful to use normal, italic, bold, bold-italic
as a progression of emphasis or typographic differentiation.
We shouldn't discourage the support. The example should
also change.
>>> There was discussion and concensus that a change like that
>>> proposed should be made.
7. Page 28 (sect 11) ... the last line of the page ends with
The SUBMIT button is used to e-mail the form or send
its contents to the server as specified ...
should be replaced with:
The SUBMIT button is used to send the form's contents to
the server as specified ...
if e-mail is desired, that would be an action protocol,
wouldn't it?
8. First paragraph on page 29 (same as in item 7 above)
The last sentence of the paragraph is not precise. Either
the author of a FORM can expect the ENTER key to submit
in absence of a SUBMIT button or they can't.
"It may be appropriate" is not standards language.
9. The third paragraph on page 29 reads:
To let users enter more than one line of text, use the
Textarea element.
This reads like advice to authors. As a descriptive part of
the standard it should read something like:
The TEXTAREA element is used to accept more than one line
of user input.
10. The note near the bottom of page 29 should be changed beginning
with the third sentence to read:
Any field altered by the user should be included in the
returned list of name/value pairs except that unselected
radio buttons, checkboxes and SELECT items should never
be returned. Other fields with null values may be omitted
from the returned name/value pair list. All fields with
non-null values (even if the value was not altered) should
be included.
The last sentence of the preceding paragraph should have the
word 'usually' deleted. (Or the alternatives listed).
11. Page 30 - SIZE= attribute -- delete "or precision". Even
if we later add a REAL field type, SIZE is a different concept
from precision.
12. Page 30 - TYPE=CHECKBOX last paragraph states:
The default value for checkboxes is "on".
Surely that should read either "off" or "unselected".
13. Page 30 and page 19. What is the correlation between the
<img ISMAP> attribute and the <input type=IMAGE>. I can't
find where the input from clicking <img ISMAP> is documented.
Also, is <img ismap> meaningful outside of an anchor?
14. Point of confusion for me ... page 19 refers to src=URL
while the DTD calls for a URI.
15. Page 21 - section 9.1.1 HREF second actual paragraph, last
phraComments re. March 29 HTML Draft (postscript version). A
summary of these comments was presented at the IETF. Since
I was in the middle of the discussion I'm not sure I can
present a summary of the feedback but as promised I wanted to
get all the details posted here as there are many typos which
were not in the summary. Look for >>> below for my summary
of the sense of the meeting feedback.
My comments are presented in three sections:
- Consistency issues
- Minor clarifications or improvements
- Editorial/typographical
A few points of consistency I've recently noted which are
likely to add future confusion.
1) The SIZE= attribute has two different meanings:
<input type=text... visible size of the field
<select ... depth of the field (number of rows)
As a result there two attributes which define the depth or
number of rows.
Recommendation: Use a consistent attribute name on all tags
Possible Approaches:
a) Define SIZE= to always mean the display width, use
ROWS= on <SELECT>, change TEXTAREA use also use SIZE=
(Obsolete/deprecate COLS= on TEXTAREA)
b) Obsolete/deprecate SIZE= and COLS= everywhere. Use
ROWS= (or add DEPTH= and deprecate ROWS=) for visible display
lines. Add LENGTH= (or WIDTH=) for visible display width.
The problem is that SIZE= as depth on <SELECT> seems to already
be recognized by some (all?) browsers which suggests some form
of option (b) as causing the least grief.
>>> The inconsistent use of size didn't seem to concern anyone else.
2) The <PRE> tag WIDTH= attribute doesn't have a common practice
interpretation as far as I can tell empirically.
a) Replace WIDTH= with whatever the 'standard' attribute is for
display width from point 1 above.
b) Recommend that the sentence "If the WIDTH attribute is not
present, a width of 80 is characters is assumed." be
replaced with: "If the WIDTH attribute is not present, the
width of the longest line in the <PRE> element will be used
to control horizontal presentation."
>>> The consensus was to follow my recommendation in 2.b and since
>>> my SIZE= concern wasn't shared no change to the actual keyword
>>> is needed.
3) There is no requirement that one radio button be selected by
default if the HTML doesn't designate one as checked. Yet the
<SELECT> requires that the first item listed be selected if
not is initially marked as selected.
Recommend: Remove the default selection and instead recognize
the possibility that none will be selected.
>>> The consensus seemed to be that radio buttons really meant one
>>> must be selected which is in conflict with my recommendation but
>>> does require the standard be changed to require an implicit
>>> default of showing one (the first?) button selected if none
>>> are so indicated in the HTML. (I still prefer that the none
>>> selected be provided for both selection lists and radio button
>>> groups as I view a group of radio buttons as simply a different
>>> form of selection list.
4) Conceptually, I believe it would be more consistent to document
the <BR> tag as beginning a new line rather than ending a
previous line.
Recommend: Alter examples to show <BR> at the beginning of lines.
>>> Somehow there seemed to be a concern that novice users would feel
>>> required to write constructs of the form:
>>> <li><br>W X Y z
>>> if we lighten the implication that <br> ends a line.
>>> There was a strongly stated opinion that <br> should never have
>>> attributes which no-one disagreed with. As long as <br> never
>>> has attributes I don't care if some people want to feel it ends
>>> a line and others want to feel it begins a new line as either is
>>> simply a line break. My prime concern is/was that there was a
>>> post to this group which suggested that a <br> attribute would
>>> modify the element which preceded it.
5) The COMPACT attribute only appears on the DL list. It should
appear on all list types.
>>> The consensus was that COMPACT should appear on all lists and
>>> the current form was a typo. I have now further checked and
>>> the DTD actually calls for COMPACT so this is an omission in
>>> the descriptive text only. Also, I missed it previously,
>>> section 10.6.4 shows COMPACT as an attribute for ordered lists.
>>> 10.6.2 (<DIR>), .3 (<MENU>), and .5 (<UL>) don't.
Suggested refinements:
1. The <PRE> tag should be clarified by adding:
Presentation of text on a new line will correspond to line
breaks in the input. <FORM> input fields within a <PRE>
element will utilize the same fixed-width font utilized for
surrounding text.
to the end of the first paragraph of section 10.2.
>>> I believe there was consensus that this was desirable but some
>>> concern that this wouldn't be easy for browsers depending on
>>> the features of their platform tool kits for control implementation.
>>> As I recall, the conclusion was that wording should be changed
>>> (added) but allowing for possibility it was impossible.
2. Add whatever the common display width attribute is to the
<SELECT> tag to specify the visual width. When the 'combo'
box pops up a selection list, use the width required by the
longest selection.
>>> I think the only consensus here was that this was out of scope
>>> for consideration at this time.
3. Do we need to point out to browser developers that SELECT lists
which don't fit in the current window should be scrollable?
>>> Don't think this was discussed.
5. It should be possible for a user to deselect all radio buttons
and/or all OPTIONs in a SELECT short of resetting the FORM.
>>> Discussion mentioned above. I believe the consensus was that
>>> one radio button should always be selected and hence if the HTML
>>> didn't indicate the default, a standard default should be
>>> specified (First?).
Editorial/Typographical
1. Page 9: What happened to the   entity?
2. Page 13/para 4.2: Do we really mean to require <TITLE>
for every HTML file? ("It requires the Title element between ...")
3. I don't understand 5.3 ISINDEX -- it looks awful chicken/eggish
to me. Either the interpreter already has the document in which
case why would the user request a search by "adding a question
mark to the end of the document address" or the interpreter
(?? should this say 'user agent' or 'browser'??) doesn't have
the document in which case the <ISINDEX> tag is not seen.
I don't understand how a document URI can be unknown to the
interpreter. (page 14)
4. Page 16 refers the use of the non-breaking space and soft hyphen
indicators and discourages use.
a) At the minimum the phrase should be changed from
"because they are not" to "until they are"
b) BUT it seems to me that unless we are going to document
these entities (and we should) as part of the supported
standard this whole paragraph should be deleted. As well
as any references to these characters in the previous
paragraph.
5. (opinion) Either ignore horizontal tabs everywhere or make their
use meaningful. For example, provide a <TABGRID ...> tag
and require it to apply everywhere. Very simple tabular data
can be achieved without the mystery of tables.
6. Page 19 (section 8). Change the last paragraph to read:
Character format elements may be nested within the content of
other character format elements. HTML interpreters are
encouraged to render nested character formats distinctly
from non-nested elements:
This change doesn't make differentiation a requirement but it
expresses a stronger intent on the part of the standard.
It is very useful to use normal, italic, bold, bold-italic
as a progression of emphasis or typographic differentiation.
We shouldn't discourage the support. The example should
also change.
>>> There was discussion and consensus that a change like that
>>> proposed should be made.
7. Page 28 (sect 11) ... the last line of the page ends with
The SUBMIT button is used to e-mail the form or send
its contents to the server as specified ...
should be replaced with:
The SUBMIT button is used to send the form's contents to
the server as specified ...
if e-mail is desired, that would be an action protocol,
wouldn't it?
8. First paragraph on page 29 (same as in item 7 above)
The last sentence of the paragraph is not precise. Either
the author of a FORM can expect the ENTER key to submit
in absence of a SUBMIT button or they can't.
"It may be appropriate" is not standards language.
9. The third paragraph on page 29 reads:
To let users enter more than one line of text, use the
TEXTAREA element.
This reads like advice to authors. As a descriptive part of
the standard it should read something like:
The TEXTAREA element is used to accept more than one line
of user input.
10. The note near the bottom of page 29 should be changed beginning
with the third sentence to read:
Any field altered by the user should be included in the
returned list of name/value pairs except that unselected
radio buttons, checkboxes and SELECT items should never
be returned. Other fields with null values may be omitted
from the returned name/value pair list. All fields with
non-null values (even if the value was not altered) should
be included.
The last sentence of the preceding paragraph should have the
word 'usually' deleted. (Or the alternatives listed).
11. Page 30 - SIZE= attribute -- delete "or precision". Even
if we later add a REAL field type, SIZE is a different concept
from precision.
12. Page 30 - TYPE=CHECKBOX last paragraph states:
The default value for checkboxes is "on".
Surely that should read either "off" or "unselected".
13. Page 30 and page 19. What is the correlation between the
<img ISMAP> attribute and the <input type=IMAGE>. I can't
find where the input from clicking <img ISMAP> is documented.
Also, is <img ismap> meaningful outside of an anchor?
14. Point of confusion for me ... page 19 refers to src=URL
while the DTD calls for a URI.
15. Page 21 - section 9.1.1 HREF second actual paragraph, last
phrase:
URI specification for print readers.
what is a "print reader" ... I think the phrase should be:
URI specification [1].
David Morris