Under 9.1 Anchor:
It is generically classified as Level 0 but some of the attributes are new to
level 2 (ie TITLE, URN, METHODS). I think that labeling all of them as Level 0
is misleading and that those new attributes should be labeled as such.
Under 10.6.1 Definition List:
There is a paragraph that talks about single occurences of <DT>'s and no
<DD>'s but the converse is true as well. A similar paragraph should be
inserted to cover this.
The text about half way down says "The opening list tag must be <DL> and must
immediately followed by the first term (<DT>)." This is wrong since you can
have a Definition List with NO <DT>'s and all <DD>'s. Ammend the last part to
be "...by the first term (<DT>) or the first definition (<DD>)."
The COMPACT attribute is only described for DL's. Shouldn't it also be
applicable to all other lists (UL & OL; DIR/MENU maybe??)
Under 10.6 List Elements:
There is a explicit description of all tags related to lists except LI. Its
implicitly described under OL, UL, DIR, and MENU. Should it get its own
section since it is a separate tag?
Under 11 Form-based Input Elements:
"Each variable field is defined by an Input, Textarea, or Option element"
should be "..., Textarea, or SELECT element".
In the paragraph describing the different conventions for TAB and Shift keys
on different platforms, the description says "using Enter key to submit the
form." This isnt true if the cursor is in a TEXTAREA field (on any browser I
tried). A nit probably but semi-misleading.
In the same paragraph, "The SUBMIT button is used to e-mail or send its
contents to the server as specified by the ACTION attribute," should be changed
to include the METHOD attribute too. Something like, "The SUBMIT button is
used to e-mail or send its contents to the server as specified by the ACTION
and METHOD attributes,"
Under 11.1 Form:
Describe the allowable attributes explicitly, not by example. This is done
for _every_ other tag except FORM.
In the next to last paragraph there is "The names are _usually_equal_ to the
NAME attributes of the various _interactive_ elements in the form". What other
way is there to name inputs?? Also, what about non-interactive elements (ie:
HIDDEN fields)? Remove "interactive" and that should ok.
Under 11.2 Input:
For NAME, "The NAME attribute is required for _most_ input types...". When
can an input field not have a name and still be an input?? Just how would a
non-named input be returned, by value only? With > 1 non-named input, that
could be very very bad!
For SRC, "A URL or URN specifying..." is not uniform. I think it should be
split out into SRC and URN (ala Anchors!) to be consistant.
For CHECKBOX, how does the default value of "on" map up with any explicit
values that are provided? For example, if a checkbox's value is "on" by
default and the author specifies explicit values for the it (ie "yes"), just
what should a browser send back if the user does not touch the checkbox on the
form, "on" or "yes"?
For PASSWORD, what about rephrasing "except that the text is not displayed as
it is entered" to something like "except that the text is obfuscated or changed
as it is entered so that it is not plainly visible to the user". The original
text semi-implies that PASSWORD fields can be either obfuscated or not
displayed at all. A nit really...
Under 11.4 Select:
How is it possible to select nothing from a list when "If no option is
initially marked as selected, then the first item list is selected."?? This
means an author is required to create a "No choice" option and make it the
first option. I think this last part should be removed from the draft or
inverted.
As brought out at IEFT, SIZE has a different meaning for Select than any
other FORM input. If it were renamed to something like LINES or ITEMS then it
would be less ambiguous.
Under 11.5 Text Area:
The title should be one word, Textarea.
A for FORM, list the allowable attributes explicitly, not be example!
My proxy server is down this AM so I cant see if these changes need to be in
any more recent draft than 3/31 so disregard any that have already been covered.
Bruce
===============================================================================
Bruce Kahn INet: Bruce_Kahn@iris.com
Iris Associates Phone: 508.392.5335
Standard disclaimers apply, even where prohibited by law..