On Monday, June 17, 2013 at 5:11 PM, Mounir Lamouri wrote:
> Hi,
>
> I would like to resurrect this thread with the following proposal:
> "icons" will contain an array of objects that will have one mandatory
> property named 'href'.
"Mandatory" here means that if href is missing or not a URL, then it is in
error and the object is ignored (and a warning is reported in the error
console). Also, maybe "src" might be a more appropriate name for the member as
it matches img tag.
> There will be three optional properties: 'width', 'height' and
> 'density'. 'width' and 'height' will be a number expressing the size of
> the icon in pixels and 'density' will for the moment be something in the
> following set { "1x", "1.5x", "2x", "3x" }.
We probably don't need to declare "x", as it's redundant in that the member is
"density". If we want to support other types of "density" in the future, we can
qualify those. Right now, the semantics of density is "device pixel ratio".
Also, my personal experience with "2x" and "3x" is that it's easy to get wrong,
because people are very used to writing "x2" and "x3".
Note that the above also applies for width and height. It should be optional to
have to add "px" at the end of a value (i.e., "width": "50" should be
equivalent to "50px", but not to "50xp" which is unsupported and hence ignored).
> "1x" will be the default
> value if the property is missing or has an invalid value. We might
> extend this property to include dpi values.
If we do that, we can then support "{number}{dpi | x | etc.}"
> If the entry doesn't contain a width/height information and the image is
> a bitmap image, the UA will have to download the entry to find out its size.
It may ignore 1x entries, if 2x one are available.
> When the entry is a vectorial based image, if it has no size
> information, it will be used every time an image with a size not in the
> array is requested.
There is currently no information that allows one to determine the type of an
image.
Options:
1. type member (e.g., "type": "image/svg")
2. head request (expensive - and might not yield anything useful)
3. heuristics, like checking for a file extension (can be unreliable - doesn't
help for dynamically generated content or content with no extension… could also
download the first few bytes to check the magic number, but it's also
expensive)
> If a vectorial based image has some size information
> that will be considered as "best viewed as x*y". In which case, it will
> be preferred to be scaled to another size but if a bitmap image has a
> quite closer size it will not.
> For example, a bitmap image of 60*60 will
> still be preferred compared to a SVG image of 8*8 if we want to show a
> 64*64 image (the bitmap image will be scaled).
>
> An example:
> "icons": [
> { "href": "foo.png" },
> { "href": "bar.png", "height": "16px", "width": "16px" },
> { "href": "bar_2.png", "height": "32px", "width": "32px", "density":
> "2x" },
> { "href": "foobar.svg" }
> ],
>
> How does that look? Vivien and Tim? Would you like to implement that in
> Gaia?
>
--
Marcos Caceres
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
