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.
