> 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. 

This isn't backwards compatibility since existing devices that implement the 
old standard will still break.

There is at least one bug on file (disclaimer: I filed it) for another issue, 
which is platform-specific icons. The icon guidelines for Windows apps, for 
instance, are difference from the icon guidelines for Android apps. A developer 
wishing to tailor his icon to look native on each platform can't do that at the 
moment.

There is a lot that can be done with icons, but removing information from the 
manifest in a backwards-incompatible way probably isn't the right way to go.


----- Original Message -----
From: "Marcos Caceres" <[email protected]>
To: "dev-webapps" <[email protected]>
Sent: Friday, May 10, 2013 10:19:23 AM
Subject: Icon sizes and display densities

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
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps

Reply via email to