On Wednesday, May 15, 2013 at 7:12 AM, Jonas Sicking wrote:
> On Fri, May 10, 2013 at 10:19 AM, Marcos Caceres <[email protected]
> (mailto:[email protected])> wrote:
> > Hi,
> > I'm reevaluating the app manifest format as part of the standardization
> > effort at the W3C - trying to generalize it for use on the Web. I have some
> > concerns about how the current manifest format deals with icon sizes and
> > display densities, which I would like to change in the W3C version of the
> > manifest format [1].
> >
> > Our current manifest format declares icons like this:
> >
> > "icons": {
> > "16": "/img/icon_16.png",
> > "48": "/img/icon_48.png",
> > "128": "/img/icon_128.png"
> > }
> >
> >
> > # Problems, as I see them
> > Declaring one of the dimensions is redundant (the image has the dimensions
> > built it) and error prone for formats that have an intrinsic size. It also
> > doesn't scale well for usage on high density devices, meaning that
> > redundant data may get downloaded. It also limits the control that
> > developers have over which icons get displayed for which pixel density.
> > Furthermore, the "16", "48", "128" dimensions appear to be FxOS specific
> > (and so is the requirement that icons be square).
> >
> > # Proposal
> > I would like to propose we change this to accepting an array of URLs:
> >
> > "icons": ["/img/small.png", "/img/med.png", "/img/large.png"]
>
> I'm not overly excited about forcing implementations to download all
> images just to see what size they are. Though given that this doesn't
> have to be done terribly often, maybe I'm overly sensitive.
I think that's a fair concern - and it depends on how this is implemented.
Right now, when I install an app from the Firefox store, Firefox desktop
browser on Mac is creating an application bundle on my hard drive, and it's
converting the icons from the application into an "appicon.icns" file. As there
is no way to know a head of time what the screen density of the display of my
computer will be, it is appropriate to d/l all the icons (I could d/l this on
my MacBook retina, but then plug this into a single density display - scaling
the 2x icons on my single density display would be inappropriate because they
would blur [1]).
[1] http://bjango.com/articles/designingforretina2/
On mobile devices/platforms, it might be ok to discard low and very high
density icons. This is why keying the icons off density might be a solution (so
you only download the ones related to the screen). That way, the UA can match
on density and ignore the ones that are not right for the device pixel ratio
(potentially saving bytes).
icons: [
{src: "foo"},
{src: ["/foo", "/bar"], density: 2},
{src: ["/bar", "/baz", "/mega"], density: 3}
]
The model above also makes icon objects more extensible, in case we need to add
more things in the future (e.g., roles). And takes away the pain of keying off
size for developers (i.e., "here are my icons! user agent, figure it out!").
But yes, the tradeoff is downloading stuff the UA might not need.
> > Then the UA can derive the dimensions automatically and decide what icon is
> > best to display for an application based on the available display area.
> >
> > # Supporting SVG
> > For formats with non-intrinsic sizes (i.e., SVG), we should allow either a
> > URL or an object:
> >
> > {src: "icon.svg", width: "...px", height: "...px", density: "1x"}
> > (where the "density" is the device pixel ratio density)
>
> Do we really need densities or width/height? The idea is that it's the
> same picture just in different pixel sizes, right?
For SVG, you need a width and height because the SVG file may not have an
explicit size. It may also be inappropriate to use on a 1x density device
because anti-aliasing would make it illegible/blurry. Sub-pixel anti-aliasing
on a 2x or 3x screen would again make this icon suitable for display to a user.
> So if it's an SVG
> we can just scale it to whatever size we need.
Unfortunately, no. SVG only really works for very large icons (anti-aliasing
makes a mess at lower resolutions) - [4] states that anything lower than 48px
is problematic. Please see the first graphic from [4], which shows the problem
clearly. See also [2] (last image), which shows what happens when you scale up!
As stated in [2], and echoed in [1] and [3]:
"It’s simply not possible to create excellent, detailed icons which can be
arbitrarily scaled to very small dimensions while preserving clarity. Small
icons are caricatures: they exaggerate some features, drop others, and align
shapes to a sharp grid. Even if all icons could be executed as vectors, the
largest size would never scale down well."
Vector graphic performance is also cited as an issue in both [2] and [3]
(though no primary source is given).
Also, tool support for exporting SVG is limited/expensive/crappy so it's
unlikely a lot of people will use it. We can probably already gather data on
SVG usage for icons from the apps that are already in the FxOS store to see if
there are any.
[2] http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes
[3]
http://mobile.smashingmagazine.com/2010/11/17/designing-for-iphone-4-retina-display-techniques-and-workflow/
[4]
http://www.firewheeldesign.com/sparkplug/2006/April/icon_design_bitmap_vs_vector.php
> And if we have a
> high-density display then we can just use the picture with a high
> resolution?
Sometimes, yes. Generally, icons of different sizes contain different levels of
detail. See, section 3:
http://psd.tutsplus.com/articles/7-principles-of-effective-icon-design/
> I guess there could be an argument for enabling an app to provide a
> picture which has fewer details which is more appropriate to use for
> really small icons.
This is not really an argument. That's standard practice. Open up any app's
content on your computer and find the icon set for it - you will see exactly
this.
Icons can also contain different details at the same size and for different
pixel densities (because you can pack more detail and legibility into a retina
icon) - plus they could be "art directed" (though I imagine this is rare - an
example of "art direction" would be adding a graphical "HD" stamp for 2x
density and up - or simply adding more lines and details because aliasing is
not as noticeable).
As stated in [1]:
"iOS needs a full set of 1× and 2× images. If iOS (or Xcode) bitmap scaled your
2× images down, the quality of your assets would be reduced."
Again, you can see good examples and discussion of this in [1].
> But the above doesn't seem optimized for that
> scenario. At the very least you'd want to express the size in mm
> rather than pixels for that.
Under ideal conditions, you are correct; but on screen you can only really
design for 2 things:
1. pixels
2. pixel density
And both 1 and 2 vary in size from one display to the next. Tricky things, them
pixels :)
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
