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

[Mark Nottingham]

On Aug 22, 2004, at 3:02 PM, Ian Hickson wrote:

> On Thu, 5 Aug 2004, Mark Nottingham wrote:
>>
>> * 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.
>
> Why do they need to be uppercase?

RFC2119 explicitly defines them in upper case; see just about any RFC 
for common use. If you don't denote them somehow, people will be 
confused about which statements are normative (see last comment in this 
mail). Some W3C specs that didn't want to use uppercase terms have made 
them links back to the "notational conventions" section, which in turn 
points to RFC2119.


>> * 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).
>
> I'm not aware of any similar situations.

e.g.,

2.4 "The rows and cols attributes of the  textarea element are no 
longer required attributes."

2.6 "The form element's action attribute is no longer a required 
attribute. If omitted, the default value  is the empty string, which is 
a relative URI pointing at the current  document (or the specified base 
URI, if any)."

Elsewhere, you just loosen requirements, whereas size is deprecated.


>> * 2.16 Handling unexpected elements and values, last paragraph -- How 
>> should
>> this be tested? Seems like a recipe for interoperability problems.
>
> I'm not sure which paragraph you are referring to.

"Other invalid cases should be handled analogously."


>> 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.
>
> Not sure what you mean by this.

My concern is that if someone uses an extension method (e.g., "PATCH") 
with a form, the information that it is "PATCH" instead of "GET" will 
get lost in the request. I understand that you need to have a default 
behaviour for unknown methods, but the current text *could* be read as 
saying that when you default to GET, the method gets changed to GET 
too. That would be bad.


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

http://www.w3.org/TR/webarch/#information-resource

You don't fetch a resource; you fetch a representation (you can, 
however, dereference a resource). I can't find this text in the draft 
any more, so it may be a moot point.


>> * 6.2 Seeding a form with initial values -- it's not good practice to
>> put a requirement ("should not") in a note.
>
> It's not a requirement, since it is in a note. It's just advice.
>
> Maybe it should be made normative, though. Any preference?

See first comment in this mail; I'm not sure what's normative. I don't 
have any preference regarding this specific text.

Cheers, many thanks, and keep up the (very) good work,

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