W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

[whatwg] Is there any reason for the continued existence of enctype attribute at the form element

From: Simon Pieters <simonp@opera.com>
Date: Sun, 11 Oct 2009 12:12:45 +0200
Message-ID: <op.u1mrzjt5idj3kv@simon-pieterss-macbook.local>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC