Clarify file_handlers.icons semantics

[mgiuca]

There's a note under file_handlers.icons member:

NOTE Semantically, the icons are used to convey the file type itself and also the app. As with name, this is typically only displayed when the app has become the default handler for a file type.

I'm not clear on what "and also the app" means.

Let's firstly make sure my understanding of what this field means is correct: the icons in this member "serve as graphical representations of a file type on a platform", so that means they aren't supposed to represent the app, they're supposed to represent the file type. My understanding is that means you are supposed to put an icon here that would look appropriate as the icon for a file of that type. This is not the icon that represents the application, e.g., in the "Open With" menu. For that, the user agent should simply use the app icon as configured in the top level of the manifest.

With that understanding, "and also the app" is a little confusing. But I think what this is trying to say is that the icon can be "flavoured" to suggest which app it is associated with, even though it primarily represents the file type. As an example from this early design doc, you can expect the file type icons to maybe look like a page with a small representation of the associated app. Here, the Excel .xlsx handler icon shows a page with a spreadsheet on it, with a small green "X" logo. It does not show the full Excel logo (the app icon).

I think we could update this text to make that clearer. Suggested text:

"The icons member is expected to be an image that represents all files that are associated with the handler. This will typically appear like a document (e.g. a piece of paper) as opposed to an application logo, but may include elements such as logos that suggest which application it is associated with. As with name, this is typically only displayed when the app has become the default handler for a file type."

Also in the normative text:

The file handler's icons member lists icons that serve as graphical representations of a file type on a platform.

I don't know what "on a platform" means and would suggest removing these three words.

[evanstade]

The above is mostly correct. The only wrinkle here is that on Linux desktop environments, the icon only represents the file type and not the application. For common/known file types like text/plain, the icon provided by an application would always be ignored. The only point of application-provided icons is when the application is defining a new type, say application/vnd.oasis.opendocument.spreadsheet. So I think "graphical representations of a file type on a platform" attempts to capture "this is how GDE depicts this file type". That said,

• For any vendor-specific MIME type that starts with application/, you're going to be hard pressed to come up with an icon that represents the type but not the application that opens it.
• I don't think end users actually grasp the subtle difference between "this is an Excel spreadsheet file" and "this is an Excel spreadsheet file that will be opened by the Excel app when I double click on it"
• App authors are not likely to somehow accommodate this subtle difference across platforms

So "convey both file type and the application itself" is what we'd want from app authors.

The icons member is expected to be an image that represents all files that are associated with the handler

This reads oddly to me because of the mix of plural and singular, even though I think I know why (there are different sizes, but they're different sizes of the same semantic thing).

[mgiuca]

(Perhaps we can move this to the PR #87 where we can discuss the proposed wording of the fix. I will copy-paste parts of your reply there.)