- From: Marijn Kruisselbrink <notifications@github.com>
- Date: Tue, 02 Jun 2020 10:42:02 -0700
- To: w3c/FileAPI <FileAPI@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/FileAPI/issues/41/637699823@github.com>
I see, it's unfortunate Firefox implemented this change without noticing that this open issue existed, but I guess ultimately that is on us spec editors for not clearly marking these things in the spec. I'm not sure what the Entries API has to do with this. The Entries API does not consume File objects, it produces them. And when it produces them it doesn't do so by invoking the File constructor. The logic here only effect File objects created by javascript it seems completely irrelevant what the Entries API does (well, not irrelevant, it is good to be consistent. But that has nothing to do with being compatible). (also I might be missing something/not finding the right message, but I don't see anything in that discussion thread specifically related to replacing '/' with ':'?) If we do actually want to disallow '/' in the `name` attribute of a script created `File`, I'm not sure why replacing it with ':' makes sense. Wouldn't it make more sense to just reject entirely? Also, non-traditional file systems, like for example Google Drive, do allow '/' in file names. And it's not immediately obvious to me why we would need to stop them from creating File objects with those names. Different platforms/file systems have different limitations, but we're not limiting File objects to the strictest possible subset of filenames (8.3 filenames only anyone?) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/FileAPI/issues/41#issuecomment-637699823
Received on Tuesday, 2 June 2020 17:42:14 UTC