Re: Toward Closure on HTML
William M. Perry (firstname.lastname@example.org)
Tue, 5 Apr 94 13:31 EDT
Jay C. Weber writes:
>> From: Dave Raggett <email@example.com>
>> What we really need is some work on a MIME multipart/related format
>> for transferring form contents, as the current URL based approach is
>> running out of steam.
>We'd probably want to leave FORM method=GET behavior just the way it is,
>and update method=POST.
>Support on the server side is easy: CGI scripts accepting POSTs could just
>start branching on the content-type, e.g., processing a new type
>multipart/www-form. A day's worth of hacking.
>On the client side, generating multipart/www-form isn't much work
>(factoring out the user interface complexity of supporting image
>scribbles, etc.), but backwards-compatibility is a bear. The only way a
>server can declare format preferences in advance is through anchors,
>really; so the only alternative I see is something like a FORM
>Dave, do you want to try this with your browser? We'll support it on the
Does anyone support the ENCTYPE attribute for forms yet? Why not just
define a new ENCTYPE of multipart/www-form, and have the default still be
application/x-www-form-urlencoded? It shouldn't take more than 20 minutes
to implement this on my browser. How should multipart/www-form be defined?
Content-types for each input area?