Ability to define platform-specific icon/splash style

[kornelski]

Different platforms have different guidelines regarding their icon style, and an app may need to follow them to look "native".

Wrong style, even if slightly wrong, can create "uncanny valley", e.g. multiple OSes use square icons with rounded corners, but with a different radius. Icon with a wrong corner radius looks like an amateurish knock-off.

The spec currently only matches icons on size and density, but not style/theme, so sites would need to resort to user-agent sniffing if they wanted to serve system-specific icons.

A theoretical solution available in HTML, with help of Moz's nonstandard media queries, is:

<link rel=icon href="generic.png">
<link rel=icon media="all and -moz-windows-theme:luna-blue" href="xp.png">
<link rel=icon media="all and -moz-windows-theme:aero" href="vista.png">

[raucao]

We need this, too.

[alxlu]

This would be useful for us as well as we have some unique icon sizes.

[kenchris]

Different sizes are already handled. Anything missing there @alxlu ?

[raucao]

The point is that different platforms have different requirements as well as interface guidelines for app icons, especially in regards to shape, whitespace, and transparency. Size doesn't matter for that.

[alxlu]

Looking back at this, I think what I had in mind may be somewhat out of scope for this topic. The reason I brought icon size into this is because we have an unconventional size (basically a wide rectangle) for one of our icons that I anticipate many developers will not bother creating an icon for.

As a result, we will probably end up taking a square icon and putting it on top of a solid color rectangle. It would be great to have some type of field for icon background color added to our vendor specific field—as some icons may look strange on top of certain colors. I figure this is something developers are more likely to do than create a custom icon for us.

[marcoscaceres]

@alxlu I'm also thinking of adding background color to the "image object" definition... we need the same thing for #9.

@pornel although you are more or less correct, it seems bad to target specific platforms (though you could use UA sniffing to send the right icon if really needed).

I did look into this problem about a year ago - but found they only differ a little bit in most cases:

https://groups.google.com/forum/#!topic/mozilla.dev.webapps/Dqie9L41XKg

For example:

[marcoscaceres]

@skddc, could you post images of your icons for reference?

[marcoscaceres]

@alxlu added feature request for background color: #366

[kornelski]

@marcoscaceres I disagree about the "a little bit". Even examples you've shown differ enough that a wrong icon would give impression of app creator not having a good taste or not caring about the platform.

This is very important for the "native" feel, rather than giving a second-rate almost-but-not-quite feel. Here's a screenshot from Android. Can you guess which FT icon belongs to the native app?

And FT's icon is already as simple as it gets.

Now imagine a complex icon that's a colorful 3D model (KitKat or OS X 10.9 style) used among flat white silhouettes on Windows "Metro". Yuck!

So I'm quite serious with media-query-like mechanism that can target exact styles. That's the reality. We have designers who will follow style set by iOS, Material design, Metro, and whetever comes next.

It would be silly to be vague about it, because then both browsers and authors would have to figure out how to map spec-euphemisms to the specific OS they target.

Specced media query is always better than browser sniffing (e.g. not many authors will design for Tizen or Ubuntu, but niche vendors will be able to pick which one of the more popular styles is closer to their preferred one, without twisting User-Agent even more).

[marcoscaceres]

Ok, a problem remains that you then even need to go down to the OS version (think of how drastically different iOS 6 was vs 7)... so the whole media query above would need to be rethought even for that.

[kornelski]

It's not OS, it's style. Single OS can have many styles, e.g. Windows has Classic, Luna, Aero, Metro (and most versions could switch between couple of these at any time, so even exact OS version is not enough).

In case of iOS the styles would probably end up being named "iphoneos" or "ios" and then the new one would be "ios7" or "vibrant" (like they did in OS X).

So it may be good to be able to specify an arbitrary list of tokens (styles) an icon fits, and let browsers pick whichever one they want. This way browser/OS vendors will be defining the tokens as they see fit, and will be free to invent new ones when fashion changes.

[marcoscaceres]

Ok, yeah - theme could work so long as the theme doesn't change from one version to another.

[marcoscaceres]

I wonder if the same applies to splash screens...

[kornelski]

Yes, it might apply to splash screens as well, e.g. if the splash screen mimics initial application layout it'll have different location and sizes of toolbars on different platforms (and screen sizes)

[marcoscaceres]

So yeah, it feels like we are probably going to need a generic means of targeting platforms and themes. If anyone has a proposal for how to make this work sanely in JSON, I'm all ears. I'll try to come up with something in the next week or so (gotta finish up the Gecko implementation of the base members + CSP).

[marcoscaceres]

Safari's "favorites" also shows this issue... iOS icons mixed with, um, "web" icons...

[tigt]

Should there be an option for icon processing? Many OSes perform icon processing to massage them into the system's look and feel:

• iOS 1-6 had the -precomposed flag to opt-out of icons getting rounded and glossed
• All iOS versions will fill in transparency with black
• Android still rounds off very sharp corners. Some versions, especially older ones, will also shrink the icon and apply a drop shadow.
• Firefox OS always applies a drop shadow

Some sort of precomposed parameter to opt out of this processing would be good for designers who want to do these sorts of operations themselves for maximum visual control.

[marcoscaceres]

@tigt, yeah, probably... I've been kinda hoping implementers would stop doing that (as happened with iOS).

[marcoscaceres]

Upping the priority on this one... let's see if we can put something together by this friday.

[kenchris]

I don't think the point here is supporting any theme or OS, but there are very big iconography differences between ie Windows and other platforms. I think it would work if we added some hints instead which (the icon) will be ignored by platforms not understanding the hint.

[kenchris]

Also every time I request icons from our graphics team, they ALWAYS send me different icons for iOS and Android, even without me requesting it

[marcoscaceres]

We need to add some spec text about how to do this server-side... similar to i18n.

[kornelski]

Server-side? Ewww :(

Server-side solution is favouring incumbents and it's hostile to new platforms, because any new platform won't be recognised by all existing sites.

OTOH if the solution was declarative, then the UA could make a decision which of available styles is the closest fallback, so if somebody makes "ShinyRounded OS" tomorrow, it'll be able to fall back to iOS icons without having to fake an iOS User-Agent.

icons: [{
        "src": "a.png",
        "theme": "material"
      },{
        "src": "b.png",
        "theme": "ios-precomposed"
      },{
        "src": "c.png",
        "theme": "samsung-rounded-ish"
      }]

and have UA pick the theme it wants. Because the UA picks the theme, you don't even have to define which values are valid (just define which icon is picked as the default in case none of the themes are recognized by the UA).

HTML already solves this with vendor-specific link rel= values, so going back to UA sniffing would be regression even from current de-facto standards.

[marcoscaceres]

Personally, I agree 100% with @pornel. It's a matter of getting implementations behind this (though technically, I would prefer to reuse the platform member). It think we are going to have to sit on this for a bit.

[marcoscaceres]

I'm going to make platform available on image objects and "let god sort it out". The platform member is open ended enough that it can take the values of "theme"... let's see if some defacto standard emerges.

Will send a PR.

[patrickkettner]

+1