On 10/05/13 18:19, Marcos Caceres 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"]
>
> 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.
I like that idea :)
> # 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).
I join Jonas here: isn't SVG, by definition, able to render at any size
quite nicely? The only issue being the level of detail the image might
have. Shouldn't we have {min,max}-{width,height} instead then? We could
also simply have width/height as a "preferred size" but the heuristic
used to pick the best image might not please the app maybe? or maybe
max-width/max-height are enough to ask the UA to use this icon until a
specific size and another one for bigger sizes? I'm thinking out loud
here but I'm basically not sure width/height is the information we want.
I'm not sure why we need "density" for SVG but I don't know much about
that kind of problems so maybe I'm missing something.
> #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.
Again, this question might be naïve but if the UA knows that it wants to
show an icon at a specific size, it knows the number of pixels being
needed to render the icon, right? Why do we need this density ration?
Can't the UA simply pick the icon with the most appropriate size?
--
Mounir
_______________________________________________
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
