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

On Aug 23, 2004, at 3:58 AM, Ian Hickson wrote:

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

Sorry, I wasn't questioning that. My concern was that whereas "row" and 
"cols" become optional -- something that's entirely reasonable, and 
backwards-compatible -- "size" is deprecated, which is unique within 
the document; AFAICT nothing else is deprecated.

Usually, things that are deprecated are explicitly disallowed in the 
future, thereby breaking backwards-compatibility; is that the intent 
here, and do the issues surrounding "size" warrant this?


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

Leaving it in isn't either, and gives implementers an excuse to handle 
things in different ways. If there are more situations, they should be 
specified.


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

Let me try again;

There are a few approaches that could be taken to unrecognised methods;
1) default to GET and hope for the best
2) raise an error
3) come up with scheme-specific "unknown method" rules

#1 is the approach taken in the current draft. Unfortunately, it loses 
information on the wire; i.e., there's no way for the server to know 
that GET isn't what the client wanted. If a new method is later 
specified and supported by clients, servers will still have to look out 
for GET requests that are coming from old clients that don't understand 
the new method.

Because of this, there aren't many situations where the currently 
specified behaviour does something useful, and it makes phasing in new 
methods more complicated.

My preference would be for approach #3; it should be possible to encode 
the method into the request so that no information is lost, and old 
clients can interoperate with servers using new methods (with a bit of 
work on the server side).

#3 could also mean that the client sends a well-understood "my client 
doesn't understand that method" request to the server, so it could 
present an appropriate notification or alternate form to the user.

Failing that, #2 seems more straghtforward than #1.


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

You say tomato... :)

Cheers,

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

Received on Monday, 23 August 2004 15:18:31 UTC