[whatwg] comments on Web Forms 2.0, 27 June 2004

[Mark Nottingham]

First of all, I'd like to congratulate the WG on producing such a high 
quality specification so quickly. Please find below a few smallish 
issues, mostly editorial, that I noticed when I had the pleasure of 
reading it.

* 1.6 Conformance Requirements -- Web Forms says that conformance is 
indicated by RFC2119 terms, but doesn't use any AFAICT; while there are 
many lower-case must, may and should's in the document, they need to be 
uppercase to qualify as requirements.

My first suggestion would be to uppercase terms where appropriate. If 
that is felt undesirable, I'd suggest either dropping the RFC2119 
reference (i.e., section 1.6) altogether (preferred), or adding 
language to the effect that conformance terms are lowercase (not 
preferred, as this is non-standard use).

* 1.6 Conformance Requirements, paragraphs 7 and 8 -- What is the 
significance of "over HTTP" for the media types; does this imply that 
they may be served with different media types over other protocols?

Suggest dropping the phrase.

* 2.1 Extensions to the input element (no impact on this specification) 
-- I understand the WG intends that CSS dictate the presentation of the 
various controls (e.g. a clock vs. a text field for date entry). When 
doing so, I'd ask that consideration be given to the possibility for 
alternate, user-selectable modes on the same form; e.g., I as a user 
may want to override the clock method of entry for a particular form, 
so that I can use the text field mode, even though the CSS specifies a 
clock.

* 2.1 Extensions to the input element, last paragraph -- "The size 
attribute of the input element is deprecated in favour of using CSS to 
specify the layout of the form." This approach isn't used elsewhere 
(i.e., AFAICT, other similar situations don't result in deprecation). 
Also, what is the force of deprecation WRT conformance?

I suggest removing this paragraph.

* 2.1.1 Ranges -- "values allowed by the above types" --> "values 
allowed by some of the above types"

* 2.1.2 Precision -- "fractional number" --> "decimal number"?

* 2.12 The autocomplete attribute -- Nothing is said about the scope of 
completion when the value is "on"; e.g., is a value on form on 
http://www.example.com/foo able to be used for completion for a form on 
/bar?

I suggest explicitly stating that the scope is unspecified if that is 
so, or else specifying it.

* 2.16 Handling unexpected elements and values, second paragraph -- if 
you want this specification to be taken seriously, please act 
accordingly.

* 2.16 Handling unexpected elements and values, "For parsing errors in 
HTML" -- giving advice to reverse-engineer products may not be wise 
(IANAL) and certainly isn't good practice for specifications, even if 
it is realistic.

* 2.16 Handling unexpected elements and values, last paragraph -- How 
should this be tested? Seems like a recipe for interoperability 
problems.

* 2.4 Extensions to the textarea element -- it would be interesting if 
a media type for the textarea could be specified; e.g., if it were 
"text/html" the textarea would become a HTML editor, or a rich text 
editor for "text/rtf".

* 5.6 Submitting the encoded form data set -- Have the consequences of 
making method fall back to GET been considered, WRT phasing in new 
methods? I don't have a strong preference here, but the issues may be 
subtle. In the event that the current approach is kept, it should be 
made explicit that the actual method remains what is specified, rather 
than changing to GET, so that no information is lost.

* 5.6 Submitting the encoded form data set -- "resource is fetched" --> 
"representation is fetched"

* 6.2 Seeding a form with initial values -- it's not good practice to 
put a requirement ("should not") in a note.

Kind regards,

--
Mark Nottingham     http://www.mnot.net/