search

WICG / file-handling

API for web applications to handle files
Other
82 stars 15 forks source link

Why do extensions include a leading "." #43

Closed mkruisselbrink closed 3 years ago

mkruisselbrink commented 4 years ago

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).

mgiuca commented 4 years ago

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.

fallaciousreasoning commented 4 years ago

Ah so I think we did this originally because we wanted to be as similar as possible to the WebShareTarget API. I believe that we include the '.' because the web doesn't have a concept of extensions, so it was sold as a "file name suffix" rather than an extension.

@mgiuca is probably the best person to ask about context, or @ericwilligers

From: Marijn Kruisselbrink notifications@github.com Sent: Thursday, June 11, 2020 8:49:36 AM To: WICG/file-handling file-handling@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [WICG/file-handling] Why do extensions include a leading "." (#43)

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).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/WICG/file-handling/issues/43, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB2SQSAJUKEQU46SHSQ4YFDRWAEYBANCNFSM4N23GWAA.

mgiuca commented 4 years ago

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).

mkruisselbrink commented 4 years ago

So nothing about the Native File System API is set in stone yet. In https://github.com/WICG/native-file-system/pull/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.

inexorabletash commented 4 years ago

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?

mgiuca commented 4 years ago

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 ".".

mkruisselbrink commented 4 years ago

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.

mkruisselbrink commented 4 years ago

https://github.com/WICG/native-file-system/pull/219 will resolve the difference by aligning the native file system API with what is currently speced here.

dway123 commented 3 years ago

The difference has been resolved, so I think this issue has been fixed now.