I think we have a few options here: * Use some sort of naming scheme for icons, like size-platform or size-platform-version. * Create some more general per-platform-override mechanism, similar to the language-override feature. * Rely on UA detection and let servers serve different manifests for different platforms. * Do nothing and see how much people complain.
The last two are essentially the same, though we could enable UA-detection in the marketplaces that we can control over, i.e. the firefox marketplace. This actually seems like one of those rare cases where UA detection actually might make sense. Authors are literally wanting to send different look-and-feel depending on what platform the application is going to run on. I can't say that I feel strongly either way. The fact that there's an escape hatch in the form of UA detection means that there is an out for people that feel that they absolutely need to do this. And it means that we will get data on how common of a requirement this is. On the other hand, I don't see that much harm in adding an icon-specific feature here. Other look-and-feel issues can always be implemented using application logic. Only thing that I definitely don't think we should do at this stage is the second option in the list above. / Jonas On Tue, May 14, 2013 at 7:53 PM, Matt Basta <[email protected]> wrote: > My official proposal is as follows: > > - Apps icons can specify icons with keys targeting platforms and versions in > the format "size[-platform[-version]]" > - The platform will choose to use the most specific icon that's applicable to > itself > - The manifest is invalid if an icon targeting a platform does not specify an > icon for that size. (i.e.: you can't have "128-android" without "128") > - The manifest is invalid if an icon targeting a platform version does not > specify an icon for that platform. (i.e.: you can't have "128-android-4.2" > without "128-android") > > This prevents developers from unfairly targeting a platform, leaving out > platforms unintentionally, or causing havoc with backwards-compatibility. I > think that addresses the concern(s) in your first point, yes? I'll leave the > other questions you raise to the rest of dev-webapps. > > > ----- Original Message ----- > From: "Travis Choma" <[email protected]> > To: "Matt Basta" <[email protected]> > Cc: "dev-webapps" <[email protected]>, "Marcos Caceres" > <[email protected]> > Sent: Tuesday, May 14, 2013 5:01:07 PM > Subject: Re: platform-specific icons > > What about making at least one non-platform specific default icon required? > This way you don't run into the situation where one platform is > using/supporting icons from another and/or missing an icon all together. > > Providing optional platform specific icons provides some flexibility, > although there is less pressure these days to conform to a specific platform > style, i.e. iOS glossy icons are not at all popular anymore even though that > is the default recommended style. But this ability to target platforms is > worth considering, sometimes getting featured on a particular marketplace > depends on having assets that are appropriate for it. > > Also let's say open web apps run on iOS down the road, iOS's icon sizes are > completely different: 57x57, 72x72, 114x114, and 144x144 so people might > start using size differences as a way of targeting specific platforms > anyways, without formal support for it. > > Best, > -Travis > > ----- Original Message ----- > From: "Matt Basta" <[email protected]> > To: "Marcos Caceres" <[email protected]> > Cc: "dev-webapps" mozilla.org> > Sent: Tuesday, May 14, 2013 4:40:40 PM > Subject: Re: platform-specific icons > >> That's when the problems start (FxOS users will get no icons at all). > > The object that you provided would be invalid. Older devices would not find a > suitable icon and the Marketplace's validator would consider that an error. > It does not meet the spec as it's currently written. > > Overridden, platform-specific icons should only be provided if a less > specific variant has already been listed. > >> Pleasing a small handful of developers at the expense of introducing another >> form of vendor-prefixing could outweigh the benefits. > > This feature is entirely opt-in. > >> I don't see how you can say it's not an alternative when the dominant mobile >> platform already implements it > > 1. Icons are currently not submitted in the full-bleed variety that iOS > requires to make that magic happen > 2. Platforms that don't implement their own clipping/reworking (or older > devices that don't support it) will see an ugly square icon. > 3. Some platform style guidelines physically can't be implemented > programmatically. > 4. We shouldn't force recomposition across platforms in ways that developers > might not expect. Don't have an Unbuntu machine? Too bad, you can't see how > your icon is going to look in the dash. > 5. This isn't a built-in feature for *any platform that Mozilla currently > supports*, meaning it would have to be built from scratch everywhere. > >> And for those cases, the developer can disable platform styles. iOS does >> this with "apple-touch-icon-precomposed". > > Whose platform styles? What if the developer doesn't like one platform's and > not another's? How is opt-out recomposition of developers' icons a suitable > solution to this problem? > >> It's even a standard feature of things like the HTML5 boilerplate. > > It's a standard feature of the HTML5 boilerplate because Apple introduced a > proprietary feature to one of their popular products. My proposal is an > amendment to an open standard which is cross-platform, backward-compatible, > and meets our scalability needs. > > > > ----- Original Message ----- > From: "Marcos Caceres" <[email protected]> > To: "dev-webapps" mozilla.org> > Cc: "Matt Basta" <[email protected]> > Sent: Tuesday, May 14, 2013 4:20:19 PM > Subject: Re: platform-specific icons > > (might be time for others to chime in… Matt and I are sounding like broken > records :)) > > > On Tuesday, 14 May 2013 at 23:16, Matt Basta wrote: > >> > With a hosted web app, there is no restriction on the shape. I can publish >> > whatever shape I want - I'm not bound by any app store or guidelines. >> >> >> No, you're not bound. But for developers that *want* to, we should give them >> that option. > Which developers in particular? Do you have a bug with developers asking for > this? Is it more devs than are asking for WebP or a solution for responsive > images? Also, could we speak to these developers about the alternatives and > see if it makes sense? It's our job to listen to what people need and come up > with good solutions that not only meet their use cases, but also sustain the > health of the Web platform. If we just addressed all immediate needs on the > Web, we would have a lot more -like tags. >> > Seems very few devs actually care on Android about consistency in the >> > icons - yet still works fine. >> >> >> No, not all do. But some do, and that's what matters. > We need to think carefully as to what we enable on the platform, as all > choices have costs and benefits. Pleasing a small handful of developers at > the expense of introducing another form of vendor-prefixing could outweigh > the benefits. > > Again, how many is a few? Why would this get resources over other features? >> > If we are going to be too restrictive about icons, then that might put >> > developers off >> >> >> Nothing about my proposal is mandatory, and it's in no way >> backwards-incompatible. This simply gives the developer to provide >> platform-specific icons. The following object would be perfectly acceptable: >> >> { >> "64": "64.png", >> "128": "128.png", >> "128-android": "android-128.png", >> "128-android-4.2": "android-4_2-128.png" >> } >> >> It's purely optional. As we increase our partner base and transition >> traditionally desktop and native apps to HTML5, more partners are going to >> look for features like this. > Right, but again, what if they only do this? > > { > "128-ios": "ios-128.png", > "128-android-4.2": "android-4_2-128.png" > > > "128-windows-9": "windows9.png" > > } > > That's when the problems start (FxOS users will get no icons at all). > Assuring everyone, not just people on iOS and Android, gets an icon should be > the priority. > > Then suddenly we have to start supporting another platform's icons (like > Opera had to start supporting -webkit- in Presto). > >> > they can use UA sniffing to target a platform. >> This is a bad practice > > No worst than platform prefixing. >> and also is impossible for packaged apps. > > The problem goes away with the solution I'm proposing. >> > Again, *you let the user agent do it for you*. >> >> Can the user agent adjust the direction of the lighting? Can it adjust the >> perspective of the image? Can it isolate the shape and turn it white for >> Metro? Absolutely not. > > And for those cases, the developer can disable platform styles. iOS does this > with "apple-touch-icon-precomposed". > > >> Beyond rounding the corners or adding a glare, the user agent can't do a >> whole lot. This is not an alternative. > > I don't see how you can say it's not an alternative when the dominant mobile > platform already implements it - and has been available since iOS 1.1.3. It's > not like some theoretical thing: it's something that people use today on the > Web. It's even a standard feature of things like the HTML5 boilerplate. >> Windows (classic and metro), OS X (flat and not flat), and Linux (...) are >> first-class citizens in the long term goals of the app ecosystem and we >> should not be ignoring the ability for developers to provide dedicated >> assets for these platforms. > > I agree. We should support all platforms equally. > > > _______________________________________________ > dev-webapps mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapps > _______________________________________________ > dev-webapps mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
