W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2005

[whatwg] Wish: Restrict Image Size on Upload

From: Mikko Rantalainen <mikko.rantalainen@peda.net>
Date: Mon, 03 Jan 2005 13:39:13 +0200
Message-ID: <41D92EE1.7040307@peda.net>
what at keepthebyte.ch wrote:
> On Tue, 28 Dec 2004 14:46:08 +1300, "Matthew Thomas" <mpt at myrealbox.com>
> said:
> 
>>Should UAs be able to restrict uploads based on the bit depth of 
>>images? (For some purposes only 1-bit images are desired.) How about 
>>based on whether images are animated or not? (Some forums may want 
>>avatars to be non-animated only.) How about based on the number of 

I agree that most of the uploadable files cannot be filtered by user 
agent. In addition think that file upload dialog *hiding* images 
which don't fit certain pixel sizes would be a bad UI because users 
aren't expecting such behavior from file selection dialog. I would, 
however, support a suggestion to ask UA to scale the uploaded image 
to certain smaller size so that the file would be faster to send 
(think about a photo taken with a 8MP digital camera, for example). 
I can see two positive outcomes from this support:

1) Upload time is less than when using server side scaling
2) User gets in the charge with the scaling algorithm -- e.g. UA 
could allow the user to tweak scaling algorithm and/or JPEG 
compression parameters so that resulting image would look 
sharper/would be quicker to send. Perhaps generate three different 
versions of scaled image and let the user choose the one that looks 
the best.

> Another idea: how about a "compress" flag - the UA compresses (zip) the
> file/s before sending - that could reduce upload time dramatically and
> improve user experience. The document management system vendors would
> love this feature.

How about server just sends
Accept-Encoding: gzip,deflate (or some other encoding)
HTTP header to the UA and UA sends everything compressed if possible?

-- 
Mikko
Received on Monday, 3 January 2005 03:39:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC