Clarify file_handlers.icons semantics

[mgiuca]

Rewrote the note to clarify the purpose and intent of file handler icons.

This properly explains that file handler icons should represent the file type, not the application, but that it can include the application logo to imply which app will open the file.

Also makes a minor change to normative text (remove "on a platform").

Closes #86.

---

Preview | Diff

[mgiuca]

@evanstade may also want to be across this minor wording change. See #86 for details.

[mgiuca]

Responding to @evanstade 's comments on #86:

(I think this part is in response to removing "on a platform")

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.

I don't think the spec needs to take into account all the ways in which a platform can ignore the icon. That doesn't change the fact that the application provides an icon that represents the file type, even if some platforms ignore that icon because they have their own.

The only point of application-provided icons is when the application is defining a new type, say application/vnd.oasis.opendocument.spreadsheet.

Maybe on Linux, but on Windows certainly the icon is set to the application-supplied icon for whichever application is the default handler.

So I think "graphical representations of a file type on a platform" attempts to capture "this is how GDE depicts this file type".

(Is "GDE" Gnome Desktop Environment?) I'm afraid I don't follow how "on a platform" conveys "your window manager can override this icon".

• 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 am trying to draw a clear distinction between an icon that represents the file type and an icon that represents the application (a source of continual confusion since I first started writing about this feature in 2014). An icon for a file type specific to a single application is not the same thing as an icon that represents that application.

This is an icon that represents the .PSD file format:

This is an icon that represents the Photoshop application:

Even though PSD is an application-specific file format, and the file type icon is branded with the stylized "Ps" logo, it is still representing the document, not the application. The goal here is to make sure the document files don't look like they are applications. (For an incredibly long-lived counterexample, see the fact that when Chrome is the default PDF handler on Windows, all PDFs have the Chrome logo and look like applications. I filed an issue for this nine years ago and happily it seems to be getting fixed.)

(A long-standing and common convention is to use a "piece of paper" motif as shown in the PSD icon above, which I mentioned in the note in this PR.)

I think this is covered by the sentence "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 the file is associated with."

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

I don't think that matters. The file format icon is not intended to convey the identity of the app that will open it (nor should users rely on that for security), it is solely intended to convey the file format. It may even be useful for a third-party Excel editor to use a green "X" to convey that this is an Excel spreadsheet, even though it is not going to open in Excel. I think that is desirable, not a bug.

To this end, if you like, we could reword "suggest which application the file is associated with" to "suggest the primary application responsible for this file format" or similar.

• App authors are not likely to somehow accommodate this subtle difference across platforms

App authors should not attempt to create differences across platforms. The standard should allow them to describe the most complete information and then the user agent should adapt it for individual platforms. All that app authors need to understand is that they should be making a picture of a piece of paper with a logo on it, not an app logo, as the value for this member, and I don't think the current text quite conveys that.

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

Updated with a parenthetical "(or collection of images at different sizes)" to address this.

[evanstade]

We are in agreement on all points, I was just providing some additional context to explain the current state of the text. I commented on the issue rather than the PR because I don't work on this area any more and coming up with perfect text is quite hard :)

Responding to @evanstade 's comments on #86:

(I think this part is in response to removing "on a platform")

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.

I don't think the spec needs to take into account all the ways in which a platform can ignore the icon. That doesn't change the fact that the application provides an icon that represents the file type, even if some platforms ignore that icon because they have their own.

Agree that how the icon may be ignored is not relevant to the composition of the icon. But there is a difference that could hypothetically affect that: on Linux, the icon represents just the file type. On Windows, it represents the file type and the application.

The only point of application-provided icons is when the application is defining a new type, say application/vnd.oasis.opendocument.spreadsheet.

Maybe on Linux, but on Windows certainly the icon is set to the application-supplied icon for whichever application is the default handler.

Yep.

So I think "graphical representations of a file type on a platform" attempts to capture "this is how GDE depicts this file type".

(Is "GDE" Gnome Desktop Environment?) I'm afraid I don't follow how "on a platform" conveys "your window manager can override this icon".

"on a platform" conveys that this icon is to become the platform-wide graphical representation for that file type. It could be shown in a file browser, but also other UI surfaces. It could be shown in surfaces that are not even used to launch an app to handle the file.

• 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 am trying to draw a clear distinction between an icon that represents the file type and an icon that represents the application (a source of continual confusion since I first started writing about this feature in 2014). An icon for a file type specific to a single application is not the same thing as an icon that represents that application.

On some platforms (Linux) those are indeed the two categories of icon. On Windows, the categories are "application" and "file type AND application". For the web, we boil it down to two categories. We are basically taking the Windows categories and ignoring the one that's unique to Linux. But that's probably ok, because anyway the "file type AND application" type of icon is hard to distinguish from the "file type" type of icon when the file type is proprietary.

For the non-normative text, we could write something like:

"The icon is expected to represent the file type in platform UI surfaces such as the file browser. For some OSes (e.g. Windows), this icon will only be utilized when the application has become the default handler, although for others (e.g. desktop Linux) it will be applied if and only if the desktop environment lacks an icon for that file type. As such, these icons should generally convey the file type AND contain hints to the identity of the opening application (such as logos)."

But again, the text is hard, so I'm fine with whatever.

[mgiuca]

Thanks for the detailed reply @evanstade and sorry for the late response.

I'm still sort of struggling to understand what you mean by on Windows the icon represents "file type AND application". (Particularly in contrast to Linux where you say it only represents file type.)

What I think you are getting at is that on Windows, a file type icon for a generic (non-vendor-specific) file type often will in some way convey the app it's going to open in. I think there is an incentive for commercial software to slap their logo on things. But I don't think this is a) the norm, or b) something we should say developers "should" do.

For a counter-example, look at the default apps on Windows: Notepad's .txt file association is a simple white page. Media Player's .mp3 file association is a page with a musical note and the text "MP3" below it:

(source)

The design of the system appears to be "when you make a file type icon, let it convey the file type only, not the application it will open in" (as I mentioned above, for vendor-specific file types like Photoshop, these will be app-branded, but that's still a property of the file format, not the application). Of course, if the system lets the default handler set the icon, they can brand it with their app icon, but I don't believe this is the way things "should" work.

Therefore, I think my softer wording "but might include elements (such as logos) that suggest which application the file is associated with" is appropriate.

Thanks for the discussion. As there are no strong objections, I'll merge this now.