Specify how filenames from the OS map to File's `name` property about fileapi HOT 2 OPEN

I agree that dropping files entirely is probably not ideal, and dropping file content definitely isn't. Not sure if how file names are mapped from the OS to the name property should be specified; that really seems more like an implementation detail to me.

I once started trying to spec some of this a little bit better as part of #154, i.e. see https://pr-preview.s3.amazonaws.com/w3c/FileAPI/pull/154.html#create-a-file-backed-file-object with my thought being that the html spec for input type=file and drag&drop would then call out to that to create actual File objects. Currently that just has the name conversion being done in a "user agent defined manner", and is otherwise pretty hand-wavy about OS integration as well. I think that should be good enough though.

From an implementation side, fixing this in chrome is somewhat tricky as it will require some fundamental changes to how File objects are created. These are changes we want to make anyway, but unfortunately isn't likely to happen in the near future.

from fileapi.

It's fine if things are left implementation-defined, but maybe it'd be worth it to add a note about expected behavior:

Although the conversion from a native filename into a string is implementation-defined, it is expected to be a straightforward mapping. In particular, if the system's filenames are represented as sequences of code units, the resulting strings should be identical; and if they are represented as byte sequences, they should be decoded from the OS's default encoding with the "replacement" error mode.

I think at the very least the spec should make clear that the empty string fallback should be for OS errors when reading the filename – decoding the filename should always succeed.

from fileapi.