Re: File API: File's name property

On Thu, Aug 29, 2013 at 10:14 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> On Thu, Aug 29, 2013 at 4:10 PM, Glenn Maynard <glenn@zewt.org> wrote:
> > I don't think it makes sense to expect filenames to round-trip through
> > File.name, especially for filenames with a broken or unknown encoding.
> > File.name should be a best-effort at converting the platform filename to
> > something that can be displayed to users or encoded and put in a
> > Content-Disposition header, not an identifier for finding the file later.
>
> File has a constructor. We should be clearer about platforms too I suppose.
>

All constructing a File does is give a name (and date) to a Blob.  It
doesn't create an association to an on-disk file, and shouldn't be
restricted to filenames the local platform's filesystem can represent.

Given that the URL parser treats them identically, we should treat
> them identically everywhere else too.
>

URL parsing does lots of weird things that shouldn't be spread to the rest
of the platform.  File.name and URL parsing are completely different
things, and filenames on non-Windows systems can contain backslashes.

-- 
Glenn Maynard