W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2002

RE: Is it possible to paste an image into a form?

From: Jukka Korpela <jukka.korpela@tieke.fi>
Date: Mon, 28 Oct 2002 09:25:02 +0200
Message-ID: <621574AE86FAD3118D1D0000E22138A95BDF0F@TIEKE1>
To: w3c-wai-ig@w3.org

David Woolley wrote:

> > Is it possible to paste an image into a form?
> The file upload mechanism supports it at the protocol level.  
> I doubt that any browser implements it at the user interface level.

File input in forms is widely supported, although the quality of support
varies from rather poor to poor. It can be used for images too. Naturally
the form handler needs to be prepared to processing such submissions. For
details on file input and its implementation, see

There is no requirement that a browser have any special functions for
actually _constructing_ a file, such as drawing a picture, and no browser
that I know of has such a feature. Such possibilities are naturally not
excluded either. But would it be useful to have, say, a built-in drawing
program inside a user agent? Maybe not in general. People have their
favorite drawing programs, and yet another (presumably very simple) one
wouldn't help much. But for rather specialized user agents, like browser for
people with serious problems with written language, maybe even illiterates,
drawing-like input (as a functionality built into a browser) might be

>(It might be worth checking xforms -
> any extension to forms is likely to have to come through that 
> route, if not done as a proprietory, commercial, extension.)

Maybe... though XForms is quite a challenge to implementors, and it's
incompatible with HTML forms (so authors would need to provide both an HTML
form and an XForms form, for the foreseeable future). The current XForms
draft describes an "upload" element (the name of which is somewhat a
misnomer, IMHO), which "enables the common feature found on Web sites to
upload a file from the local file system, as well as accepting input from
various devices including microphones, pens, and digital cameras".

That's not really new. Even <input type="file"> _could_ be implemented as
accepting input from such sources; the common "browse folders and pick up a
file" implementation is just the simple approach that was originally
outlined in RFC 1867 and partly (!) implemented in browsers.

What's new is that the XForms draft then lists some methods of input that
_should_ be supported by user agents. In particular: "Implementations with a
digital camera/scanner interface or screen capture should support acquire
image-in-place upload of images from an attached device." What this really
means is a bit obscure. If a browser runs on a PC with an attached scanner,
does this say that the browser needs to be able to take input directly from
scanner? It might seem so, but the browser vendor could simply say that the
_browser_ hasn't got a scanner interface!

It's actually a bit surprising that it doesn't mention the obvious: a user
agent that operates in an environment where graphics can be created by the
user, e.g. using a screen and a mouse, should support interfaces to graphics
software that can be used that way, accepting direct input from them. Maybe
they thought this was _too_ evident? Or too much of a burden to
implementors, since this would apply to most browsers? :-)

But the XForms draft is clearly oriented towards encourageing the
implementation of _different_ ways to include non-text data into a form
submission. That's important, even if it's just one part of the picture (no
pun intended) - processing user input in non-text format is the great

Jukka Korpela, senior adviser 
TIEKE Finnish Information Society Development Centre
Diffuse Business Guide to Web Accessibility and Design for All:
Received on Monday, 28 October 2002 02:25:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:08:48 UTC