On Tuesday, 18 June 2013 at 13:35, Mounir Lamouri wrote:
> On 17/06/13 18:43, Marcos Caceres wrote:
> > On Monday, June 17, 2013 at 5:11 PM, Mounir Lamouri wrote:
>
> > 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.
We should only support support one (IMO, "src") - otherwise, it will be
confusing.
> > > 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.
People seem familiar with dppx because of iOS safari's window.devicePixelRatio.
However, it's not clear most people understand what dppx actually is or how it
works, as it's hard to grasp because it's a relative unit to CSS pixels.
Regardless, places where icons are displayed generally will run as if <meta
viewport=devicewidth>, in which case dppx should be *roughly*:
1 = non-retina
2 = retina
3 = ultra high density. Starting so see some of these (see [1] for a list)
4 = 8k displays (~beyond 2016) 7680x4320 on 13" - can't predict the future, but
it's a possibility that there may be devices packing this many pixels into a
small display around 2020.
I think also dpi might become kinda meaningless when icons interact with
virtual viewports based on CSS pixels - like if the OS was run on a device
supporting 3dppx but virtualized to run as if it was 2dppx (kinda like what iOS
does with legacy 1dppx iPhone apps running on the new iPad).
> 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.
Sure, we are not codifying this in stone right now. We are using it as the
basis of a proposal to take back to the W3C. We should hit the CSS WG for
guidance here (or CSS people at Moz, like Elika).
We can also reach out to the W3C's Responsive Images Community Group for
discussion. There are a lot of excellent designers in that CG with experience
working on these kinds of problems.
> > > 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.
I'm not sure I follow? If you have:
{src: "foo", width: "64", height: "64", type: "image/svg"}
The UA assumes that the generated content is going to be "image/svg"?… more
below.
> In other words, it might
> quite the same as using extensions.
>
> How reliable would the header be?
>
Given the above:
1. User agent that doesn't support SVG can ignore this icon (based on type
member).
2. User agent that support SVG can confidently download this icon for usage:
- if the author made a mistake and it's not SVG, then the Content-Type header
is authoritative (e.g., image/png). If the Content-Type header is missing or in
error - content type sniffing applies.
- if the content is unrecognised once downloaded - then it's just ignored.
What am I missing?
[1]
https://github.com/ResponsiveImagesCG/picture-element/wiki/Display-technologies:-beyond-Retina
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
