On 17/06/13 18:43, Marcos Caceres wrote:
> 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).
Yes. Just ignore the entry if there is no 'href'.
> Also, maybe "src" might be a more appropriate name for the member as it
> matches img tag.
"src" might be better than "href" indeed. I honestly don't care.
Supporting both would also be fine for me.
>> 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".
I do not have a strong opinion on that. I agree that 1x 2x 3x are
commonly used and it might be a bit bothering to risk mistakes by
requesting the x.
In the other hand, we have no idea what is going to be the next common
thing. Will developers soon use "XXXdpi", "YYYdpi", "ZZZdpi". In that
case not having to specify "dpi" would be great for them.
Basically, not having a default would prevent us from having the wrong
default later but I do not have a strong opinion on that matter and we
should definitely have this discussed with people who know more on that
topic.
>> 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)
That's a good point. I think 1 isn't a good solution because it wouldn't
work if the content is dynamically generated. In other words, it might
quite the same as using extensions.
How reliable would the header be?
--
Mounir
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
