Why do extensions include a leading "."
mkruisselbrink opened this issue · 9 comments
I'm trying to unify a bit how accepted file types are specified in the Native File System API with how they are specified here. While doing so I noticed that currently all the examples include a leading period for extensions. The Native File System API currently requires websites to NOT include a leading period (primarily because the file dialog implementation in chrome requires not including leading periods). I was wondering if there was any particular reason for the leading periods? And what happens if a website does not include a leading period?
(fwiw, the explainer mentions that the chrome apps API for this didn't have leading periods either).
If I recall correctly, the reason we require a leading "." came out of discussions around the idea that "the web does't know what a file extension is". The argument posed to us (I believe this was internal to Google) was that there are no "file extensions" on the web, only MIME types, so we shouldn't be capturing based on extensions, but MIME types, and we should have a private internal list of extension -> MIME mapping.
This wasn't acceptable, since it requires browsers to map extensions to MIME types, and creates cross-browser incompatibility. So our compromise was to add file extensions, but not call them "extensions". Rather, we phrase it as a "filename suffix". The idea is that you supply a "filename suffix" and we match any file that ends with that string. By convention, the suffix starts with a period and contains 3-5 letters, but it doesn't have to start with a period, in which case it will match any suffix. This then sidesteps the need to precisely define what an "extension" is; for example, whether "example.tar.gz" matches ".gz", ".tar.gz" or both.
If you've already specced extensions in Native File System API then I would prefer to change this to lean on that existing work and for consistency. But it would be a breaking change.
Thanks @fallaciousreasoning for providing extra context that this was for Web Share Target compat.
In making this decision, I think it's more important to be consistent with Native File System (which is directly linked to this API) than Web Share (which is only conceptually linked to this API).
So nothing about the Native File System API is set in stone yet. In WICG/file-system-access#185 I'm trying to (get closer to) consistency with file handling (which I even noticed the difference). I would have a slight preference for not including the '.', just because doing anything else will either mean a non-trivial refactoring of the file dialog code in chrome, or not supporting suffixes that don't start with a '.'. Both don't seem great.
Possible compromise: define it as a suffix but require an explicit leading '.' in APIs/file formats, with a note that this matches current platform conventions but that this could be revisited in the future. Suffixes without a leading '.' are ignored (or error, depending on context). Implementation can validate then drop the '.' internally if it's easier for plumbing.
I don't know what that means for handling of .tar.gz though. That might still require plumbing changes?
Supporting suffixes without a delimiter seems weird, e.g. registering T or secrets.dat. So disallow for now but be open to supporting that in the future?
I like @inexorabletash 's compromise. TBH I feel the "arbitrary suffix" feels weird and I don't see why anyone would want to do that, other than as a solution to the multiple-extensions (.tar.gz) thing. I would prefer to either do Josh's suggestion, or just change the syntax to not have the explicit ".".
Either compromise seems fine... Having an API where you can supply strings but those strings have to always start with a "." feels like a very weird API to me. On the other hand, this matches what several existing APIs do already, as pointed out in https://bugs.chromium.org/p/chromium/issues/detail?id=829689#c85 (a difference though, in both pre-existing APIs mime types and extensions are mixed in one array, while here they are separated). So I guess changing the native file system API to reject if some extension doesn't start with a "." doesn't seem too terrible. I don't really see a future where we'd allow arbitrary suffixes. For one the Mac file dialog as far as I can tell does not support arbitrary suffixes/globs.
So either solution seems fine to me. Not having the explicit "." is what is currently spec-ed and implemented in the native file system API, but if we want to require explicit ".", we can still change that until we ship in M86.
WICG/file-system-access#219 will resolve the difference by aligning the native file system API with what is currently speced here.
The difference has been resolved, so I think this issue has been fixed now.