- From: SULLIVAN, BRYAN L <bs3131@att.com>
- Date: Wed, 29 May 2013 22:34:10 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Charles Pritchard <chuck@jumis.com>, "piranna@gmail.com" <piranna@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
-----Original Message----- From: Jonas Sicking [mailto:jonas@sicking.cc] Sent: Wednesday, May 29, 2013 3:25 PM To: SULLIVAN, BRYAN L Cc: Charles Pritchard; piranna@gmail.com; public-webapps@w3.org Subject: Re: Filesystem events On Wed, May 29, 2013 at 3:17 PM, SULLIVAN, BRYAN L <bs3131@att.com> wrote: > From: Charles Pritchard [mailto:chuck@jumis.com] > Sent: Wednesday, May 29, 2013 3:08 PM > To: piranna@gmail.com > Cc: public-webapps@w3.org > Subject: Re: Filesystem events > > > > We didn't come to much of a resolution. > It was suggested that the current behavior in browsers was incorrect; that > the File should become inaccessible if/when it changes. > > <bryan> I disagree, the fact that re-accessing a file object loads the > latest version of the file is a valuable feature IMO, even if it was not > intentional. I don't know if preventing that is what you meant, but further > to require that the user reselect a file if it has changed would be a UX > killer. File objects should be immutable. That was one of the core design principles that they were built around. If we want <input type=file> to provide "live" access to on-disk files, then new File objects should be returned from HTMLInputElement.files whenever the on-disk files change. That would need to be defined by the HTML spec though. <bryan> OK, but that sounds like one of those "good UA design" principles that ignores the actual effect upon apps and users. I would prefer to keep this "bug" around until the new/better design is implemented.
Received on Wednesday, 29 May 2013 22:34:51 UTC