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: Ian Hickson <ian@hixie.ch>
Date: Mon, 12 Oct 2009 11:36:30 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0910121134150.25383@hixie.dreamhostps.com>
On Sun, 11 Oct 2009, Simon Pieters wrote:
> On Sun, 11 Oct 2009 11:38:51 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > 
> > 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?

As a warning, maybe. Making it a conformance error seems a bit drastic. 
Maybe we should, though?


On Sun, 11 Oct 2009, Mark Kaplun wrote:
>
> 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.

On Sun, 11 Oct 2009, Boris Zbarsky wrote:
> 
> While this may be true (and I'm not sure it's as true as one would like) 
> some of these "frameworks" are more or less capable than others.  Some 
> expect the data in a _very_ particular format (such that changing the 
> order of elements in the submitted data, for example breaks them); I 
> would not expect them to switch easily between different enctypes.
> 
> A surprising amount of form POST processing seems to happen in an exe on 
> the server, not in any sort of modern scripting language.  At least 
> based on the bugs we've gotten filed whenever we change anything about 
> it.

On Sun, 11 Oct 2009, Mark Kaplun wrote:
>
> Boris, I have agreed with your first response that I don't know enough 
> about all the crazy things that people might be doing, to make this 
> attribute to disappear. However I don't see how changing the default 
> mime type will have any affect on the existing web pages and for web 
> pages which will be authored in the next few years, as long as there are 
> tested against IE8.
> 
> IMHO this attribute is a bug in the specification which is causing 
> annoyance to any web developer which do not use IDE's to create forms. 
> Changing the default the way I described might create a different 
> annoyance, but in my opinion it will be a much lesser one.

I've certainl written CGI scripts without libraries where the CGI script 
only supports one enctype. I doubt I'm alone in this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 12 October 2009 04:36:30 UTC

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