Re: [whatwg] img srcset for responsive bitmapped content images
On 2012-05-10 09:58, Edward O'Connor wrote: Hi, When authors adapt their sites for high-resolution displays such as the iPhone's Retina display, they often need to be able to use different assets representing the same image. Doing this for content images in HTML is currently much more of a pain than it is in CSS (and it can be a pain in CSS). I think we can best address this problem for bitmap[1] content image by the addition of a srcset= attribute to the existing img element. The srcset= attribute takes as its argument a simplified variant of the image-set() microsyntax[2]. It would look something like this: img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. ... Inventing a new microsyntax is tricky. - comma separated implies you'll need to escape a comma when it appears in a URI; this may be a problem when the URI scheme assigns a special meaning to the comma (so it doesn't affect HTTP but still...) - separating URIs from parameters with whitespace implies that the URIs are valid (in that they do not contain whitespace themselves); I personally have no problem with that, but it should be kept in mind Best regards, Julian
Re: [whatwg] img srcset for responsive bitmapped content images
On Wed, 16 May 2012 11:22:07 +0200, Julian Reschke julian.resc...@gmx.de wrote: Inventing a new microsyntax is tricky. - comma separated implies you'll need to escape a comma when it appears in a URI; this may be a problem when the URI scheme assigns a special meaning to the comma (so it doesn't affect HTTP but still...) Indeed. Edward did not write it all as a spec, though, so cases like that might be a bit detailed for a first proposal. Hixies extension of srcset does however have some spec text, and that does in fact handle your first case: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates - separating URIs from parameters with whitespace implies that the URIs are valid (in that they do not contain whitespace themselves); I personally have no problem with that, but it should be kept in mind Me neither. I'm no big fan of non-valid URIs. :-) -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] img srcset for responsive bitmapped content images
On 2012-05-16 11:51, Odin Hørthe Omdal wrote: On Wed, 16 May 2012 11:22:07 +0200, Julian Reschke julian.resc...@gmx.de wrote: Inventing a new microsyntax is tricky. - comma separated implies you'll need to escape a comma when it appears in a URI; this may be a problem when the URI scheme assigns a special meaning to the comma (so it doesn't affect HTTP but still...) Indeed. Edward did not write it all as a spec, though, so cases like that might be a bit detailed for a first proposal. Hixies extension of srcset does however have some spec text, and that does in fact handle your first case: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates ... It looks like that, but it's non-trivial to check (that's why I prefer declarative definitions). Best regards, Julian
[whatwg] img srcset for responsive bitmapped content images
Hi, When authors adapt their sites for high-resolution displays such as the iPhone's Retina display, they often need to be able to use different assets representing the same image. Doing this for content images in HTML is currently much more of a pain than it is in CSS (and it can be a pain in CSS). I think we can best address this problem for bitmap[1] content image by the addition of a srcset= attribute to the existing img element. The srcset= attribute takes as its argument a simplified variant of the image-set() microsyntax[2]. It would look something like this: img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. img srcset takes one or more comma separated image specifiers. An image specifier consists of a URL to an image asset and an associated scale factor, expressed as a number followed by the literal character 'x'. (The value of img src is treated as if it had a 1x scale specified, so you can avoid duplicate references to the base asset.) User Agents may make their asset selection before fetching any of the assets, thus avoiding multiple asset loads the associated performance problems in constrained bandwidth environments. The intrinsic size of the img can be computed by dividing the intrinsic size of the actual image asset chosen with that asset's associated scale factor. Suppose that foo-lowres.jpg is 100x100 and foo-highres.jpg is 200x200 in the above example. If the UA chooses foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) = 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic size as (200/2)x(200/2) = 100x100. A nice thing about this proposal is its backwards compatibility story. Browsers which don't yet support img srcset will simply use the asset referenced by img src. A polyfill could easily be written to check for img srcset swap out a different asset into img src, much like existing libraries which check for data-fullsrc= or the like. Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we're asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just media-queriable things like device resolution but also any scaling applied to the img with CSS, its width= and height= attributes, or even things like the current page zoom level. Of course there are other things like bandwidth availability, data plan usage, etc. that web developers might want to take into account when choosing which image assets to load. This is definitely something worth exploring. In the future we could extend the asset descriptors to cover such cases. Something like this, maybe: img srcset=foo-lowres.jpg 1x low-bandwidth, foo-highres.jpg 2x high-bandwidth I'm purposefully not making a proposal for how to describe bandwidth, data plan usage, or such things here. Ultimately I don't think addressing the multiple-resolution case needs to wait for a solution to these other cases. We don't need to SOLVE ALL THE PROBLEMS! right now. One downside to this proposal is that the srcset= attribute takes a microsyntax, and as a rule we try to avoid novel microsyntaxes in attribute values. I think this particular microsyntax is pretty straightforward and shouldn't cause all that much confusion for authors. I think this is preferable to adding a suite of attributes with complex inter-relationships, such as in Anselm Hannemann's proposal from last August[3]. In such a proposal, we would either need to have a pre- approved list of image scales (like Anselm's xs, s, m, l, xl), which over-constrains designers' ability to create, or we would be introducing user data into attribute names which—with the one exception of the data-*= attributes—is something I really don't think we should do. Some have argued that we should just use conneg to serve the best image. This isn't an acceptable solution for at least three reasons: * The server doesn't have all of the relevant information needed to pick the best image, and sending that information with every image asset request is bandwidth-intensive and enables increased user fingerprinting. * HTML is used in a lot of contexts, such as in EPUB, in which there's no server to negotiate with in the first place.[4] * The UA should be able to swap out one asset for another transparently after the page has loaded. For instance, the UA might want to swap things out when the user zooms in. I also think this approach is better than minting a new image element, but I'll make that argument in another email. Ted 1. What responsive image problem? Just use SVG! :) 2. I've proposed image-set() for CSS4 Images. Here's the relevant post to www-style: http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html An implementation of image-set() has recently
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, May 10, 2012 at 10:58 AM, Edward O'Connor eocon...@apple.com wrote: The srcset= attribute takes as its argument a simplified variant of the image-set() microsyntax[2]. It would look something like this: img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. img srcset takes one or more comma separated image specifiers. An image specifier consists of a URL to an image asset and an associated scale factor, expressed as a number followed by the literal character 'x'. (The value of img src is treated as if it had a 1x scale specified, so you can avoid duplicate references to the base asset.) User Agents may make their asset selection before fetching any of the assets, thus avoiding multiple asset loads the associated performance problems in constrained bandwidth environments. I'd like to throw in another use-case that might be addressable by the same feature: allowing Save As... to save a different version of the image (e.g., higher-res) than is actually displayed. Wikipedia, for instance, often has very high-res images that get scaled down for article viewing to save bandwidth and avoid possibly-ugly rescaling. (At least historically, some browsers used very bad rescaling algorithms.) It would be nice if when users saved the image, they saved the full-res version. Perhaps browsers could save the highest-res image available, rather than the one that happens to be used for display right now. Another obvious use-case I'd like to point out is print. It's not quite as trendy as the iPhone Retina display -- in fact maybe it's getting passé :) -- but print is generally higher-res than display, and it's common for images to appear pixelated when printing. This use-case might have the same requirements as the iPhone Retina display, but it should be kept in mind in case it doesn't. A fourth use-case I'd like to suggest is vector images. Last I checked, many authors don't want to serve SVG directly because too many browsers don't support it in img (or at all). Perhaps it should be possible to specify vector or something in place of a scale factor, to indicate that the image should be suitable for all resolutions. (A possible problem with this: very detailed SVGs can be much larger than the equivalent bitmaps, so the bandwidth tradeoff might not always be good. But authors can worry about that themselves, I guess, and not specify such vector images as possible sources.) It's possible that the best solution won't accommodate all of these use-cases, but I'm just throwing them out here so that they can be taken into account.
Re: [whatwg] img srcset for responsive bitmapped content images
Aryeh wrote: I'd like to throw in another use-case that might be addressable by the same feature: allowing Save As... to save a different version of the image (e.g., higher-res) than is actually displayed. […] Another obvious use-case I'd like to point out is print. Yes, these are both excellent reasons for us to adopt such a feature, and the img srcset proposal can handle both cases. A fourth use-case I'd like to suggest is vector images. Last I checked, many authors don't want to serve SVG directly because too many browsers don't support it in img (or at all). I'm not sure about this one. If a browser doesn't support SVG, I want to be able to provide a bitmap fallback regardless of how I included the SVG—in both the img src or inline svg element cases. img srcset isn't about providing fallback, so this might best be addressed with a different feature. It's possible that the best solution won't accommodate all of these use-cases, but I'm just throwing them out here so that they can be taken into account. *nod* Thanks, Ted
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, May 10, 2012 at 2:44 PM, Edward O'Connor eocon...@apple.com wrote: I'm not sure about this one. If a browser doesn't support SVG, I want to be able to provide a bitmap fallback regardless of how I included the SVG—in both the img src or inline svg element cases. img srcset isn't about providing fallback, so this might best be addressed with a different feature. There's already an easy script-free way to support fallback in inline svg -- add an img inside some element that SVG ignores. (I can't remember which one is recommended, but IIRC there is one that's suitable.) A browser that doesn't support svg will ignore all the SVG tags as unrecognized wrappers, and just display the img. A browser that supports svg will ignore the img. There's no good existing fallback for img that I know of. In practice, any browser that supports srcset will support SVG-in-img, and in principle vector images can be thought of as infinite-res, so it seems like it might be a useful feature to tack on. But this is the weakest use-case given, I agree, and it might be best not to solve it.
Re: [whatwg] img srcset for responsive bitmapped content images
You should look into the previous discussions at http://www.w3.org/community/respimg/ There's also a prototype using media queries at https://github.com/scottjehl/picturefill. I realize you specifically said you think media queries don't solve all of the problems, but it seems worth looking at. On Thu, May 10, 2012 at 3:58 AM, Edward O'Connor eocon...@apple.com wrote: Hi, When authors adapt their sites for high-resolution displays such as the iPhone's Retina display, they often need to be able to use different assets representing the same image. Doing this for content images in HTML is currently much more of a pain than it is in CSS (and it can be a pain in CSS). I think we can best address this problem for bitmap[1] content image by the addition of a srcset= attribute to the existing img element. The srcset= attribute takes as its argument a simplified variant of the image-set() microsyntax[2]. It would look something like this: img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. img srcset takes one or more comma separated image specifiers. An image specifier consists of a URL to an image asset and an associated scale factor, expressed as a number followed by the literal character 'x'. (The value of img src is treated as if it had a 1x scale specified, so you can avoid duplicate references to the base asset.) User Agents may make their asset selection before fetching any of the assets, thus avoiding multiple asset loads the associated performance problems in constrained bandwidth environments. The intrinsic size of the img can be computed by dividing the intrinsic size of the actual image asset chosen with that asset's associated scale factor. Suppose that foo-lowres.jpg is 100x100 and foo-highres.jpg is 200x200 in the above example. If the UA chooses foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) = 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic size as (200/2)x(200/2) = 100x100. A nice thing about this proposal is its backwards compatibility story. Browsers which don't yet support img srcset will simply use the asset referenced by img src. A polyfill could easily be written to check for img srcset swap out a different asset into img src, much like existing libraries which check for data-fullsrc= or the like. Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we're asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just media-queriable things like device resolution but also any scaling applied to the img with CSS, its width= and height= attributes, or even things like the current page zoom level. Of course there are other things like bandwidth availability, data plan usage, etc. that web developers might want to take into account when choosing which image assets to load. This is definitely something worth exploring. In the future we could extend the asset descriptors to cover such cases. Something like this, maybe: img srcset=foo-lowres.jpg 1x low-bandwidth, foo-highres.jpg 2x high-bandwidth I'm purposefully not making a proposal for how to describe bandwidth, data plan usage, or such things here. Ultimately I don't think addressing the multiple-resolution case needs to wait for a solution to these other cases. We don't need to SOLVE ALL THE PROBLEMS! right now. One downside to this proposal is that the srcset= attribute takes a microsyntax, and as a rule we try to avoid novel microsyntaxes in attribute values. I think this particular microsyntax is pretty straightforward and shouldn't cause all that much confusion for authors. I think this is preferable to adding a suite of attributes with complex inter-relationships, such as in Anselm Hannemann's proposal from last August[3]. In such a proposal, we would either need to have a pre- approved list of image scales (like Anselm's xs, s, m, l, xl), which over-constrains designers' ability to create, or we would be introducing user data into attribute names which—with the one exception of the data-*= attributes—is something I really don't think we should do. Some have argued that we should just use conneg to serve the best image. This isn't an acceptable solution for at least three reasons: * The server doesn't have all of the relevant information needed to pick the best image, and sending that information with every image asset request is bandwidth-intensive and enables increased user fingerprinting. * HTML is used in a lot of contexts, such as in EPUB, in which there's no server to negotiate with in the first place.[4] * The UA should be able to swap out one asset for another transparently after the page has loaded. For instance, the UA
Re: [whatwg] img srcset for responsive bitmapped content images
This proposal has a similar issue to image-set() - if the 2x means
twice the resolution (which it should), this will *not work by
default*. If you make a 5 inch wide image and save it as 200dpi, when
you send it to the browser its automatic size will be 10 inches wide.
Browsers are constrained by back-compat to always display images at
96dpi. You can get around this by explicitly setting img width, but
we shouldn't require that if we can avoid it.
This isn't hard to fix, of course; the fix just isn't included right now.
CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size). You can say image-resolution:
from-image; to get it to use the image's native resolution, whatever
it is. So, we need to add a rule to the UA stylesheet that says
img[srcset] { image-resolution: from-image; }.
In the closely-related case of using image-set() in CSS, we can just
have the winning image set the default resolution. An earlier
version of the image() function let you set an image's resolution
immediately, but we punted it for simplicity at level 3. This would
do the same thing.
That all said, I don't like the 2x notation. It's declaring this
image's resolution is twice that of a normal image. This has two
problems. For one, we already have a unit that means that - the dppx
unit. Using 2dppx is identical to the meaning of 2x. Since
image-set() is newer than the dppx unit, we should change it to use
resolution instead.
For two, I'm not sure that it's particularly obvious that when you say
2x, you should make sure your image was saved as 196dpi. You have
to already know what the default resolution is. As well, I think that
values like 300dpi are pretty common, and they don't map to integral
'x' values. If people say screw it and use 3x, this'll be
slightly wrong and I think will cause ugly blurring. If we make this
take resolution, people can just use the dpi unit.
I agree overall that this is the right approach - declaring relevant
information to the browser and letting it decide what to do is better
than trying to set up constraints by yourself. For example, using MQ
could result in the silly situation of downloading a high-res image at
first because you're on 4G, then throwing them away and downloading
low-res images when you drop to 2G. Using image-set() or @srcset
would let the browser keep the images it had already downloaded.
~TJ
~TJ
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
This proposal has a similar issue to image-set() - if the 2x means
twice the resolution (which it should), this will *not work by
default*. If you make a 5 inch wide image and save it as 200dpi, when
you send it to the browser its automatic size will be 10 inches wide.
Browsers are constrained by back-compat to always display images at
96dpi. You can get around this by explicitly setting img width, but
we shouldn't require that if we can avoid it.
This isn't hard to fix, of course; the fix just isn't included right now.
We should indeed fix it.
CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size). You can say image-resolution:
from-image; to get it to use the image's native resolution, whatever
it is. So, we need to add a rule to the UA stylesheet that says
img[srcset] { image-resolution: from-image; }.
Do we want from-image here? Or do authors prefer to serve 96dpi images
that are bigger, and specify the intended dpi in the markup?
In the closely-related case of using image-set() in CSS, we can just
have the winning image set the default resolution. An earlier
version of the image() function let you set an image's resolution
immediately, but we punted it for simplicity at level 3. This would
do the same thing.
That all said, I don't like the 2x notation. It's declaring this
image's resolution is twice that of a normal image. This has two
problems. For one, we already have a unit that means that - the dppx
unit. Using 2dppx is identical to the meaning of 2x. Since
image-set() is newer than the dppx unit, we should change it to use
resolution instead.
For two, I'm not sure that it's particularly obvious that when you say
2x, you should make sure your image was saved as 196dpi. You have
to already know what the default resolution is. As well, I think that
values like 300dpi are pretty common, and they don't map to integral
'x' values. If people say screw it and use 3x, this'll be
slightly wrong and I think will cause ugly blurring. If we make this
take resolution, people can just use the dpi unit.
Can we just use CSS's 'dpi' instead?
img src=default.jpg srcset=highres.jpg 300dpi
I agree overall that this is the right approach - declaring relevant
information to the browser and letting it decide what to do is better
than trying to set up constraints by yourself. For example, using MQ
could result in the silly situation of downloading a high-res image at
first because you're on 4G, then throwing them away and downloading
low-res images when you drop to 2G. Using image-set() or @srcset
would let the browser keep the images it had already downloaded.
Indeed.
--
Simon Pieters
Opera Software
Re: [whatwg] img srcset for responsive bitmapped content images
Hi, This proposal has a similar issue to image-set() - if the 2x means twice the resolution (which it should), this will *not work by default*. Just a quick update for the list—Tab and I chatted about this F2F just now and we agree that there isn't really a problem here, so long as the spec text is sufficiently detailed. Ted
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, May 10, 2012 at 3:47 PM, Simon Pieters sim...@opera.com wrote:
On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size). You can say image-resolution:
from-image; to get it to use the image's native resolution, whatever
it is. So, we need to add a rule to the UA stylesheet that says
img[srcset] { image-resolution: from-image; }.
Do we want from-image here? Or do authors prefer to serve 96dpi images that
are bigger, and specify the intended dpi in the markup?
Can you clarify what you mean by this? Do you mean serving a 10inch
wide image at 96dpi rather than a 5inch wide image at 192dpi, and then
telling the browser to scale it by the x factor?
The two are identical in the image's data (they're all 960 pixels
wide), only the metadata differs.
I suspect both:
1. A lot of authors would find it very confusing if they couldn't save
an image at 300dpi and have it just work, and
2. A lot of authors will be confused to discover that that they have
to save their image as 300dpi to get it to work.
For two, I'm not sure that it's particularly obvious that when you say
2x, you should make sure your image was saved as 196dpi. You have
to already know what the default resolution is. As well, I think that
values like 300dpi are pretty common, and they don't map to integral
'x' values. If people say screw it and use 3x, this'll be
slightly wrong and I think will cause ugly blurring. If we make this
take resolution, people can just use the dpi unit.
Can we just use CSS's 'dpi' instead?
img src=default.jpg srcset=highres.jpg 300dpi
If you take dpi, you might as well take all of the resolution units.
There's only 3 so far - dpi, dpcm, and dppx. There's no good reason
to limit to only one of them, since they're all constant multiples of
each other.
~TJ
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 9:47 AM, Simon Pieters wrote:
On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
This proposal has a similar issue to image-set() - if the 2x means
twice the resolution (which it should), this will *not work by
default*. If you make a 5 inch wide image and save it as 200dpi, when
you send it to the browser its automatic size will be 10 inches wide.
Browsers are constrained by back-compat to always display images at
96dpi. You can get around this by explicitly setting img width, but
we shouldn't require that if we can avoid it.
This isn't hard to fix, of course; the fix just isn't included right now.
We should indeed fix it.
CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size). You can say image-resolution:
from-image; to get it to use the image's native resolution, whatever
it is. So, we need to add a rule to the UA stylesheet that says
img[srcset] { image-resolution: from-image; }.
Do we want from-image here? Or do authors prefer to serve 96dpi images that
are bigger, and specify the intended dpi in the markup?
In the closely-related case of using image-set() in CSS, we can just
have the winning image set the default resolution. An earlier
version of the image() function let you set an image's resolution
immediately, but we punted it for simplicity at level 3. This would
do the same thing.
That all said, I don't like the 2x notation. It's declaring this
image's resolution is twice that of a normal image. This has two
problems. For one, we already have a unit that means that - the dppx
unit. Using 2dppx is identical to the meaning of 2x. Since
image-set() is newer than the dppx unit, we should change it to use
resolution instead.
For two, I'm not sure that it's particularly obvious that when you say
2x, you should make sure your image was saved as 196dpi. You have
to already know what the default resolution is. As well, I think that
values like 300dpi are pretty common, and they don't map to integral
'x' values. If people say screw it and use 3x, this'll be
slightly wrong and I think will cause ugly blurring. If we make this
take resolution, people can just use the dpi unit.
Can we just use CSS's 'dpi' instead?
img src=default.jpg srcset=highres.jpg 300dpi
Hey guys. Don’t know if it’s too early to chime in with this, but we were told
by some members of the Chrome team that any browser that supports DNS
prefetching — including assets — wouldn’t consider “looking-ahead” on the img
tag as an option. The original src would be fetched in any case, saddling users
with a redundant download.
I’ve been living and breathing this topic in the Responsive Images Community
Group for months now, so I’m psyched to see the problem getting some attention!
I agree overall that this is the right approach - declaring relevant
information to the browser and letting it decide what to do is better
than trying to set up constraints by yourself. For example, using MQ
could result in the silly situation of downloading a high-res image at
first because you're on 4G, then throwing them away and downloading
low-res images when you drop to 2G. Using image-set() or @srcset
would let the browser keep the images it had already downloaded.
Indeed.
--
Simon Pieters
Opera Software
Re: [whatwg] img srcset for responsive bitmapped content images
On 5/10/12 10:19 AM, Mathew Marquis wrote: Hey guys. Don’t know if it’s too early to chime in with this, but we were told by some members of the Chrome team that any browser that supports DNS prefetching — including assets — wouldn’t consider “looking-ahead” on the img tag as an option. Why not? In any case, _DNS_ prefetching would be the same for both the low-res and high-res image, I would think. The original src would be fetched in any case, saddling users with a redundant download. That sounds like image prefetching, not DNS prefetching. I see no obvious reason it couldn't look at multiple attributes. -Boris
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, 10 May 2012 16:19:13 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Thu, May 10, 2012 at 3:47 PM, Simon Pieters sim...@opera.com wrote:
On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr.
jackalm...@gmail.com
wrote:
CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size). You can say image-resolution:
from-image; to get it to use the image's native resolution, whatever
it is. So, we need to add a rule to the UA stylesheet that says
img[srcset] { image-resolution: from-image; }.
Do we want from-image here? Or do authors prefer to serve 96dpi images
that
are bigger, and specify the intended dpi in the markup?
Can you clarify what you mean by this? Do you mean serving a 10inch
wide image at 96dpi rather than a 5inch wide image at 192dpi, and then
telling the browser to scale it by the x factor?
Yeah.
The two are identical in the image's data (they're all 960 pixels
wide), only the metadata differs.
Right. I gathered that from-image would use the metadata.
I suspect both:
1. A lot of authors would find it very confusing if they couldn't save
an image at 300dpi and have it just work, and
This is the situation today for img src, and I guess we can't change it
now. We can provide an opt-in, though, that could also work for img src
(like CSS image-resolution).
2. A lot of authors will be confused to discover that that they have
to save their image as 300dpi to get it to work.
Yeah. Since the author needs to specify the resolution in the markup to
inform the browser which image to download, we might as well use that
information since it's more likely to be the intended dpi.
Can we just use CSS's 'dpi' instead?
img src=default.jpg srcset=highres.jpg 300dpi
If you take dpi, you might as well take all of the resolution units.
There's only 3 so far - dpi, dpcm, and dppx. There's no good reason
to limit to only one of them, since they're all constant multiples of
each other.
WFM.
--
Simon Pieters
Opera Software
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 8:36 AM, Scott González wrote: You should look into the previous discussions at http://www.w3.org/community/respimg/ There's also a prototype using media queries at https://github.com/scottjehl/picturefill. I realize you specifically said you think media queries don't solve all of the problems, but it seems worth looking at. I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg On Thu, May 10, 2012 at 3:58 AM, Edward O'Connor eocon...@apple.com wrote: Hi, When authors adapt their sites for high-resolution displays such as the iPhone's Retina display, they often need to be able to use different assets representing the same image. Doing this for content images in HTML is currently much more of a pain than it is in CSS (and it can be a pain in CSS). I think we can best address this problem for bitmap[1] content image by the addition of a srcset= attribute to the existing img element. The srcset= attribute takes as its argument a simplified variant of the image-set() microsyntax[2]. It would look something like this: img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. img srcset takes one or more comma separated image specifiers. An image specifier consists of a URL to an image asset and an associated scale factor, expressed as a number followed by the literal character 'x'. (The value of img src is treated as if it had a 1x scale specified, so you can avoid duplicate references to the base asset.) User Agents may make their asset selection before fetching any of the assets, thus avoiding multiple asset loads the associated performance problems in constrained bandwidth environments. The intrinsic size of the img can be computed by dividing the intrinsic size of the actual image asset chosen with that asset's associated scale factor. Suppose that foo-lowres.jpg is 100x100 and foo-highres.jpg is 200x200 in the above example. If the UA chooses foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) = 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic size as (200/2)x(200/2) = 100x100. A nice thing about this proposal is its backwards compatibility story. Browsers which don't yet support img srcset will simply use the asset referenced by img src. A polyfill could easily be written to check for img srcset swap out a different asset into img src, much like existing libraries which check for data-fullsrc= or the like. Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we're asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just media-queriable things like device resolution but also any scaling applied to the img with CSS, its width= and height= attributes, or even things like the current page zoom level. Of course there are other things like bandwidth availability, data plan usage, etc. that web developers might want to take into account when choosing which image assets to load. This is definitely something worth exploring. In the future we could extend the asset descriptors to cover such cases. Something like this, maybe: img srcset=foo-lowres.jpg 1x low-bandwidth, foo-highres.jpg 2x high-bandwidth I'm purposefully not making a proposal for how to describe bandwidth, data plan usage, or such things here. Ultimately I don't think addressing the multiple-resolution case needs to wait for a solution to these other cases. We don't need to SOLVE ALL THE PROBLEMS! right now. One downside to this proposal is that the srcset= attribute takes a microsyntax, and as a rule we try to avoid novel microsyntaxes in attribute values. I think this particular microsyntax is pretty straightforward and shouldn't cause all that much confusion for authors. I think this is preferable to adding a suite of attributes with complex inter-relationships, such as in Anselm Hannemann's proposal from last August[3]. In such a proposal, we would either need to have a pre- approved list of image scales (like Anselm's xs, s, m, l, xl), which over-constrains designers' ability to create, or we would be introducing user data into attribute names which—with the one exception of the data-*= attributes—is something I really don't think we should do. Some have argued that we should just use conneg to serve the best image. This isn't an acceptable solution
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, May 10, 2012 at 4:45 PM, Mathew Marquis m...@matmarquis.com wrote: On May 10, 2012, at 8:36 AM, Scott González wrote: You should look into the previous discussions at http://www.w3.org/community/respimg/ There's also a prototype using media queries at https://github.com/scottjehl/picturefill. I realize you specifically said you think media queries don't solve all of the problems, but it seems worth looking at. I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg The Responsive Images work is intended to solve a different issue than the send high-res versions if you have the screen and bandwidth to do so. It's for serving different images based on various MQ conditions, just baked into HTML markup rather than hacking it in via backgrounds. MQs, though, are a fundamentally unsound method for doing bandwidth-responsive image serving. I gave the basic example of why it fails in an earlier message in this thread. ~TJ
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 6:24 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: That all said, I don't like the 2x notation. It's declaring this image's resolution is twice that of a normal image. This has two problems. For one, we already have a unit that means that - the dppx unit. Using 2dppx is identical to the meaning of 2x. Since image-set() is newer than the dppx unit, we should change it to use resolution instead. dppx has the downside that not even CSS Working Group members can consistently spell it correctly. Regards, Maciej
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 6:47 AM, Simon Pieters sim...@opera.com wrote: On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: For two, I'm not sure that it's particularly obvious that when you say 2x, you should make sure your image was saved as 196dpi. You have to already know what the default resolution is. As well, I think that values like 300dpi are pretty common, and they don't map to integral 'x' values. If people say screw it and use 3x, this'll be slightly wrong and I think will cause ugly blurring. If we make this take resolution, people can just use the dpi unit. Can we just use CSS's 'dpi' instead? img src=default.jpg srcset=highres.jpg 300dpi CSS's 'dpi' is confusing, because it actually defines the ratio of device pixels to CSS inches, not device pixels to physical inches, as most users would expect 'dpi' to mean in the context of a graphics program. So 300dpi would mean the same thing as 3.125x, and would likely itself result in ugly blurring, since scaling by a fractional scale factor rarely looks crisp. Regards, Maciej
Re: [whatwg] img srcset for responsive bitmapped content images
On May 10, 2012, at 7:26 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/10/12 10:19 AM, Mathew Marquis wrote: Hey guys. Don’t know if it’s too early to chime in with this, but we were told by some members of the Chrome team that any browser that supports DNS prefetching — including assets — wouldn’t consider “looking-ahead” on the img tag as an option. Why not? In any case, _DNS_ prefetching would be the same for both the low-res and high-res image, I would think. The original src would be fetched in any case, saddling users with a redundant download. That sounds like image prefetching, not DNS prefetching. I see no obvious reason it couldn't look at multiple attributes. Indeed. I'm reasonably familiar with WebKit's preloading code and I see no reason it couldn't look at the srcset attribute. This would work fine for scale factor selection. Unfortunately, it would not work for the suggestion to have srcset pick images to fit available space based on width and height. Available space is not known until layout time, which happens too late for preloading decisions. So width/height fitting would defeat prefetch, regardless of specific syntax used. Perhaps this is what the Chrome engineers were thinking of; hard to say without more detail. Regards, Maciej
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, 10 May 2012 16:02:22 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg The Responsive Images work is intended to solve a different issue than the send high-res versions if you have the screen and bandwidth to do so. It's for serving different images based on various MQ conditions, just baked into HTML markup rather than hacking it in via backgrounds. MQs, though, are a fundamentally unsound method for doing bandwidth-responsive image serving. I gave the basic example of why it fails in an earlier message in this thread. Indeed. I think there's a confusion around this in general, and responsive images mean different things to different people. While the solution that Responsive Images group leans towards is appropriate for solving layout problems, the description of group's goals sounds more like solving optimisation/dpi problems. I think these are orthogonal issues and both of them may be worth solving. I've tried to sort problems/use-cases here: http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/ -- regards, Kornel Lesiński
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, 10 May 2012 21:18:41 +0100, Maciej Stachowiak m...@apple.com wrote: For two, I'm not sure that it's particularly obvious that when you say 2x, you should make sure your image was saved as 196dpi. You have to already know what the default resolution is. As well, I think that values like 300dpi are pretty common, and they don't map to integral 'x' values. If people say screw it and use 3x, this'll be slightly wrong and I think will cause ugly blurring. If we make this take resolution, people can just use the dpi unit. Can we just use CSS's 'dpi' instead? img src=default.jpg srcset=highres.jpg 300dpi CSS's 'dpi' is confusing, because it actually defines the ratio of device pixels to CSS inches, not device pixels to physical inches, as most users would expect 'dpi' to mean in the context of a graphics program. So 300dpi would mean the same thing as 3.125x, and would likely itself result in ugly blurring, since scaling by a fractional scale factor rarely looks crisp. I doubt whether support for non-integer scale factors/arbitrary DPI is going to be useful in practice. While it's relatively easy to resize photos for any DPI, it's not desirable from caching/processing perspective (hosting and serving as many different variants of a file as there are screen densities). A pragmatic solution is to have few sizes and serve a good enough size, which may as well be integer multiplies of a CSS pixel. And when it's important to serve pixel-perfect images for arbitrary DPI, then probably it's equally important to have pixel-perfect CSS as well. Unfortunately, it's very hard to write device-pixel-perfect CSS for non-integer multiplies of a CSS pixel. I don't expect many (if any) authors to actually write `border: 0.6024096386px solid` to achieve this. Most artists won't spend time to prepare dozens of pixel-perfect manually resized versions of icons for varying screen densities, so most of the time assets for resolutions between 1x and maximum will be automatically resized one way or another. Therefore, I expect browsers/systems to continue using fake 96dpi/192dpi snapped to device pixels, and artists to focus only on those ratios. It's simplest for everybody and gives device-pixel-perfect rendering on varying screen densities. -- regards, Kornel Lesiński
