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"]
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)
If svg is included just as a URL, then <svg width/height> can be used, or if
the dimensions are missing, SVG can be used for when large icons are needed
(i.e., when the raster graphics no longer fit the display area).
#High-density displays
To better support high density icon selection (and potentially save some
bandwidth), we could allow for a multiplier using CSS image-set's Nx syntax:
"icons": [
"/img/small.png", "/img/med.png", "/img/large.png",
"/img/small_retina.png 2x", "/img/med_retina.png 2x", "/img/large_retina.png
2x",
"/img/small_shd.png 3x", "/img/med_shd.png 3x", "/img/large_shd.png 3x"
]
When the multiplier is missing 1x is assumed, of course. Then the UA is free to
ignore icons with multipliers higher than that of its display density. I don't
like having to repeat the multiplier, but would like to avoid overcomplicating
the data structure used to represent what is needed to meet the use cases.
#Backwards compat
If the W3C format starts using an array instead of an object, backwards
compatibility can be retained with existing FxOS content (if type is object ===
Mozilla format; if type is array === W3C format). Of course, if we start using
the W3C format, we would need to deprecate using an object.
Thoughts?
[1] http://www.w3.org/2012/sysapps/manifest/
--
Marcos Caceres
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
