Rereading comments 1 - 24 of https://bugzilla.mozilla.org/show_bug.cgi?id=143220 as cited below, reveals to me that I was not the only one in the past 7 years to encounter the many use cases (involving client-side access to local images). I was quite disappointed when it finally became disabled in all browsers. (circa 2006 in IE, I think).

Thanks to David B. for pointing out the history of some of the discussion within Mozilla and to Jonas for pointing out the demos of Firefox 3.6 using the new file API from http://www.w3.org/TR/FileAPI/ .

It looks like this will address my use cases (including a client-side animation studio and client-side image manipulation). Between the various proposed methods and canvas, it looks like one will be able to do lots of fancy stuff.

One question I have about the FileAPI: should I address it here or contact the group responsible at public-weba...@w3.org ? That is while I see a method for grabbing "blobs" consecutive bytes from the image file, what might also be quite handy would be the old-fashioned Bit-blit sort of stuff. Specifically, it would be nice to deal with an arbitrary sub-rectangle of an image on the screen. Currently, I believe (correct me if I'm wrong), to use a clip region in either SVG or HTML of an image displayed in the browser (from a local or remote source), one has to essentially create a new version of the image (see either http://srufaculty.sru.edu/david.dailey/javascript/weave/weaver.htm or http://srufaculty.sru.edu/david.dailey/svg/clips2.svg ) to overlay clips. This is expensive in RAM and performance as the data in http://www.svgopen.org/2007/papers/BrowserPerformanceMeasures/index.html would indicate.

By being able to sample, for example a 20 pixel by 20 pixel sub-image of a rectangle as its own bitmap, would be considerably more efficient than the ways I have been doing this sort of thing. But if I understand the BLOB, it would be consecutive bytes from the actual file itself, as compressed in GIF, JPEG or PNG (or SVG???) format?? That would be useful for certain kinds of image "analysis," but for higher level image "manipulation," having to deal with all those bytes in JavaScript would be much slower it seems than something implemented close to the onscreen (or offscreen) drawing.

I like the direction this is going though!

cheers
David

----- Original Message ----- From: "L. David Baron" <dba...@dbaron.org>
To: "Jeremy Orlow" <jor...@chromium.org>
Cc: "Markus Ernst" <derer...@gmx.ch>; "whatwg" <wha...@whatwg.org>
Sent: Sunday, December 13, 2009 3:01 AM
Subject: Re: [whatwg] Uploading directories of files


On Friday 2009-12-11 02:17 -0800, Jeremy Orlow wrote:
But regardless.....I don't think you could argue that having _some_ path
information is worse than _none_, right?

Many of those who commented in
https://bugzilla.mozilla.org/show_bug.cgi?id=143220 and its
duplicates would disagree.  Users may not expect the act of
uploading a file to give the Web site details of their file system
structure.  There also seems to be some concern that those details
may provide information useful to an attacker.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/



Reply via email to