On Sun, 11 Oct 2009 11:38:51 +0200, Ian Hickson <[email protected]> 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
