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

On Mon, 23 Aug 2004, Mark Nottingham wrote:
> 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.

Ah, right. The reason is that as far as I could tell, "size" was the only 
remaining presentational attribute in HTML4 Strict's form elements.


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

They are the same issues as with the align="" attribute on <p> elements, 
for instance, which were deprecated in HTML4.


> > > > > * 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 agree that they should be specified. I was just giving implementors a 
general guideline for any that may have been forgotten.


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

Yes. #1 is the approach used by UAs, the draft just codifies current 
interoperable practice. (I think. That was my intent, at least.)


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

I fear that #3 would end up corrupting the protocols. For example, if for 
the HTTP method we defined an X-Original-Method header, you'd end up with 
people doing GET requests when they should be doing FOO requests, and end 
up with this new header being the way to chose the method.

If the method the author wants isn't supported by UAs, but he wants to use 
it anyway, and wants to know when the UA failed to use it, he can just 
specify the method in a hidden form field.


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

#2 would violate one of WHATWG's basic principles, which is to not expose 
users to authoring errors.

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

Received on Saturday, 28 August 2004 08:10:28 UTC