- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 5 Aug 2004 16:52:23 -0700
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/
Received on Thursday, 5 August 2004 16:52:23 UTC