[whatwg] comments on Web Forms 2.0, 27 June 2004
mnot at mnot.net
Mon Aug 23 15:18:31 PDT 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
>>> 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,
> What would you suggest instead? Removing it wouldn't be any better for
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
> I'm not really sure I understand. Could you give an example, or quote
> exact sentence in the spec that you think should change?
> If someone says <form method="patch">, and the UA does not support
> 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"
>> 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
> readable document.
You say tomato... :)
Mark Nottingham http://www.mnot.net/
More information about the whatwg