(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 <font>-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
