On May 15, 2013, at 1:12 AM, Jonas Sicking <[email protected]> wrote:
> On Fri, May 10, 2013 at 10:19 AM, Marcos Caceres <[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. This was my concern too. It seems unrealistic to require the user agent to download all images just to determine their sizes. There could be some large images in there, like 512 px that a mobile user agent will never use anyway. I'm pretty sure that's why the size hints were added in the first place but I don't know the history of the spec. > >> 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? So if it's an SVG > we can just scale it to whatever size we need. And if we have a > high-density display then we can just use the picture with a high > resolution? > > 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. 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. > > / Jonas > _______________________________________________ > 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
