- From: Simon Pieters <simonp@opera.com>
- Date: Sun, 11 Oct 2009 12:12:45 +0200
On Sun, 11 Oct 2009 11:38:51 +0200, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 5 Oct 2009, Mark Kaplun wrote: >> >> I have only learned now that there is a "text/plain" option that I have >> never heard of, so maybe I'm wrong, but my impression is that there are >> only two forms of form, a textual and a file upload. IMHO the browser >> can inspect the form before submitting it and decide by itself what is >> the correct encoding to use. >> >> Can the use of this attribute be deprecated, be valid only for backward >> compatibility? > > On Mon, 5 Oct 2009, Boris Zbarsky wrote: >> >> You can use multipart/form-data with a form that doesn't include any >> file uploads (and people do this). Presumably they might have reasons >> for this (e.g. they happen to have a sane multipart MIME parsing library >> and don't want to deal with the url-encoding mess the >> application/x-www-form-urlencoded option produces. > > On Tue, 6 Oct 2009, Mark Kaplun wrote: >> >> Fair enough. Can the spec be changed in regard to the default encoding, >> and make it depend on the content of the form instead of being >> application/x-www-form-urlencoded, and then like today, the enctype >> attribute can be used to override the default encoding? > > While I agree that it is probably an authoring error if the author > included a type=file control on a page with the default enctype, Should thus validators flag this as an error? -- Simon Pieters Opera Software
Received on Sunday, 11 October 2009 03:12:45 UTC