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

[Mark Kaplun]

Ian Hickson 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, I don't 
> think the magic of changing the default in that case would help authors on 
> the long run. Consider, for instance, an author who sets up his form with 
> a file upload control, gets everything working, and then decides to remove 
> the file upload control because they don't actually use it, or because 
> it's optional and they want a script to add it dynamically. They might 
> find that suddenly their form doesn't work, but as far as they are 
> concerned all they did was remove a form control that wasn't used in the 
> first place.
>
> I think this would be too confusing.
>
>   
I think that in practice no one is writing his own mime handling 
routines to handle the data in a post message, and people just use a 
framework which handles it for them. I am familiar with the way PHP 
handles posts and I know that for the PHP code the mime type is handled 
by PHP itself and you don't care about it in your code. In your example 
the form will work, because the server code never did any assumptions on 
the mime type.

I don't know enough about other server languages but I would assume that 
handling the post mime type automagically is one of the basic candies 
that every modern server language provides.

Maybe I should have started with an example where the current behavior 
hurts:
I am developing plugins and themes for wordpress. An often requested 
feature is to have an image associate with a post/category/whatever. 
Worpress has a plugin api and I can use it to add fields to admin forms, 
so in theory I just need to add a file input. The problem is that all of 
the admin except for one are textual and do not specify an enctype, and 
therefor I have to add some JS code to change the enctype on the client 
side, or develop some pointless buffering and string replacement to set 
the correct enctype.