In a visually sophisticated environment, it is desirable for software to be able to request symbolic variations of particular icons. These variations are usually monochrome, mostly matching the surrounding text color, and often involve simpler shapes than their non-symbolic equivalents.
Examples
Since gnome-panel is displayed on screen almost all the time, an OS designer may prefer the status icons displayed within it to be symbolic variations of the equivalent icons outside the panel. For example, a low-battery icon would be a basic two-dimensional outline that is mostly the same color as the text in the panel, with a red sliver inside it — while the equivalent icon in the power control panel might be three-dimensional, more detailed and make more subtle use of color.
- Inside a text field, various icons are sometimes used for special functions. There may be a magnifying glass icon to indicate that the field is a search field, a “clear” icon to clear the contents of the field, a calendar icon to open a calendar for selecting a date, and so on. It is appropriate for these icons to be simple and monochrome (like the ▼ symbol indicating a combo box is), while at the same time any equivalent icons in a toolbar would be more three-dimensional, detailed, and colorful.
- The Chromium Web browser currently defaults to completely custom icons in its toolbar, so that they can be monochrome in line with Chromium’s overall goal of an unobtrusive interface. At the same time, a file manager might reasonably continue to use standard colored icons for the same functions in its toolbar. If Chromium was able to reference symbolic variations of the standard icons, the icons would still at least use the same basic shapes across applications.
- Notification bubbles and other on-screen displays often use highly symbolic icons, monochrome with much less detail than the equivalent icons elsewhere. The color scheme of these icons should match the color scheme being used for the on-screen display in general, which may be different from the rest of the interface.
- The icons on either slide of a slider are often symbolic — for example, for muting or maxing volume, or for zooming in and out. The equivalent icons elsewhere (in a toolbar, or in standalone buttons) would usually be more detailed and colorful.
No, I disagree!
Some OS designers or theme designers may disagree with this basic premise. Or artists may not have time to produce symbolic variations of all the icons for which software developers desire them. Therefore, there should be a mechanism for developers to request a symbolic variation of an icon, such that it will gracefully fall back to the non-symbolic equivalent if — whether intentionally or unintentionally — no symbolic variation has been provided.
How this will work
This text should be added to the Icon Naming Specification:
Beneath the lowest level of specificity, there is a -symbolic namespace for all icon names. If a theme does not include a requested -symbolic icon, it falls back to the more generic version of the icon from the same theme.
- There should be some mechanism for symbolic icons to use, without being limited to, the same color as the text of the surrounding interface element. This color might be different in different places. For example, text in a panel may use a different color from text in an entry field, and symbolic icons should follow suit.