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

[Ian Hickson]

On Sun, 22 Aug 2004, Mark Nottingham wrote:
> 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

Where?


> 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).

Every use of those terms in normative sections of the spec are occurances 
of RFC2119 terms. It shouldn't be that confusing.


> 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.

I have considered doing that (for a while I was thinking of making them 
small-caps in an alternate stylesheet, too) but it would make editing the 
document significantly harder and is not really worth it IMHO.


> > > * 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."

This isn't a similar situation. The "rows" and "cols" attributes aren't 
presentational, they give the wrapping edge of the textarea, which 
affects submission. These attributes shouldn't be deprecated.

They are made optional because I couldn't see any reason for them to be 
required -- I've often needed to omit them, e.g. when there was no 
wrapping involved.


> 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)."

Again, this isn't a presentational attribute, it's just that there are 
several cases where the action attribute is just unnecessary.


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

IMHO, those situations aren't similar.


> > > * 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."

Oh, ok. I don't see how to define the other cases any other way, really. 
What would you suggest instead? Removing it wouldn't be any better for 
interoperability.


> > > 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.

I'm not really sure I understand. Could you give an example, or quote the 
exact sentence in the spec that you think should change?

If someone says <form method="patch">, and the UA does not support another 
specification or vendor extension that modifies the behaviour for this 
method, then for the purposes of submission, it is treated as "get". 
However, nowhere (as far as I can tell) does it say that the DOM is 
affected by this defaulting.


> > > * 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).

With all due respect to the authors of the webarch document, the term 
"representation" is rather confusing and would not, IMHO, lead to a very 
readable document.


> > > * 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.

As it says in section 1.6: "Diagrams, examples, and notes are 
non-normative. All other content in this specification is normative."

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'