Re: [whatwg] responsive images srcalt proposal
I was thinking that having simplified rules in your markup that try to describe image sizes related directly to device size would be tricky to match with more advanced rules in CSS [...] everything mentioned in srcoptions is related to element-width as opposed to device-width [...] Yes, that's what I though when I came up with srcalt. If the markup (and the effects it has in practice) are too complex, hardly anybody will be able to use it (effectively)... The naming convention isn't set in stone - that was what the urlpattern was for. [...] I meant that, compared to srcalt, it lacks the ability to refer to an image transformation by name, like in img srcbase=/path/to/image.jpg srcalt=?s=small 200x300 5kB, ?s=large 400x600 12kB / I don't think that most websites have more than 3 to 5 differently sized candidates per image, so srcalt attribute size would normally not be a problem. Josh.
Re: [whatwg] responsive images srcalt proposal
There are still some pre-loader issues. Google is promoting that the CDN dynamically optimize the content, that the user agent share enough info to allow the CDN to do so - effectively moving a UA function to the cloud and making a service out of it! From a user privacy perspective this is not good. To counter this, any proposal needs to be competitive, and needs to support the pre-loader being able to make the same decisions that the CDN with some UA info could - it does not need to be any better. This is the Client Hints by Ilya correct? I'm not a big fan of that because a) most people expect a URI to uniquely identify a piece of data and b) control is taken away from the user: the client does not know which candidates are available and how to influence selection. Instead, if the server should take an active role, I'd much rather have this: img src=image.jpg srclist=image.jpg?list / Where an HTTP request on image.jpg?list gets a 300 Multiple Choices response with an extensible format describing all image candidates and their properties (dimensions, file size, quality, format). Ideally the img src attribute request itself should get this response, but that would break compatibility. However browsers could start accepting such a response, and srclist could then later be deprecated. This puts the user-agent back in control to make bandwidth/quality decisions. The cost is one additional request per image, but that shouldn't be a problem in a SPDY future. Maybe Ilya could weigh in on this? As to srcalt being competitive with Client Hints: I don't think there is a difference, because for bandwidth optimized resource selection, a CH-RW header is needed, and that only becomes available after initial layout, just like srcalt requires. Thank you for reading. Josh.
Re: [whatwg] responsive images srcalt proposal
Thank all of you for your feedback. For clarification, the srcalt proposal is NOT intended to specify an (image) pre-loading mechanism. The pre-loading strategy I described earlier is just a suggestion for an implementation that I came up with to show that page loading performance does not need to suffer from srcalt, and might in fact be improved. The srcalt proposal is basically just img src=image0.jpg srcalt=image0.jpg 200x150 10kB, image1.jpg 100x75 4kB, image2.jpg 400x300 16kB/ and the fact that the browser has great freedom in deciding when to load which image when srcalt is present (even until after the page load event has been fired). The source alternatives (imageN.jpg in the example) are supposed to be visually identical, and differ only in resolution/quality/file size. I completely agree with Fred that too much emphasis is on pre-loader optimization, but that is exactly what srcalt intends to avoid. Most of the other proposals that I read seem to be about spoon-feeding the pre-loader. Srcalt just tells what image sources are available to pick from. An advantage of srcalt for authors is that they only need to worry about display resolutions, physical screen size and design breakpoints when they are writing their stylesheets, and can leave the choice of img source to the browser. An advantage of srcalt for users is that they can instruct their browser to safe bandwidth/increase speed through always loading the smaller sources, because all sources are supposed to be visually identical (unlike in other proposals). Srcalt leaves switching between visually different images to stylesheets, treating images and other content equally: div class='smallscreen' img src='closeup.jpg' srcalt='...' / little bit of text /div div class='largescreen' img src='overview.jpg' srcalt='...' / lots of text /div I was wondering how people feel about this separation of concerns. In my opinion having one img element representing one conceptually unique piece of information is superior to the 'it depends on external conditions what it represents' approach of other proposals (the art-direction/media features use cases). Anyone like to comment on this? Thank you for reading. Josh.
Re: [whatwg] responsive images srcalt proposal
We could minimize it dramatically if only a url-pattern and the available
options are exposed instead of a long list of explicit urls:
img src=/path/to/foo-320w-240h-1x.jpg width=320 height=240
srcoptions=/path/to/foo-{width}-{height}-{dpr}.{format},320w 480w
640w, 1x 1.33x 2x, webp jpg/
Wouldn't this sort of thing be much easier to learn/read/write? Both
humans and machines.
I won't bother you with all the details here - I've tried to flesh out the
idea in this gist: https://gist.github.com/rasmusfl0e/6727092
I think srcset refers to maximum device size, and your srcoptions to image
sizes, so I'm not sure about the equivalence mentioned in the linked
document.
Wouldn't srcoptions produce many URL aliases? I'd say these are the same
image:
/path/to/foo-320w-240h-2x.jpg
/path/to/foo-640w-480h-1x.jpg
This would cause cache misses (in proxy servers), or introduce complexity
in the server for making redirects.
If srcoptions also intends for each image to be visually identical, I don't
see the point in including pixel densities anyway.
Furthermore, the naming convention will be incompatible with many existing
practices.
If compacting/DRYing of markup is an issue, I would propose the following
extension to srcalt:
img srcbase=/path/to/ srcalt=image200.jpg 200x300 5kB, image400.jpg
400x600 12kB /
img srcbase=/path/to/ srcalt=thumbnails/image.jpg 200x300 5kB, normal
/image.jpg 400x600 12kB /
img srcbase=/path/to/image.jpg srcalt=?w=200 200x300 5kB, ?w=400
400x600 12kB /
img srcbase=/path/to/image.jpg srcalt=?s=small 200x300 5kB, ?s=large
400x600 12kB /
where the URI reference in srcbase is resolved against the document base
URI, and the references in srcalt are in turn resolved against that. A
number of alternative naming schemes are shown. The last two offer the
greatest opportunity for compacting markup.
Josh.
Re: [whatwg] responsive images srcalt proposal
I was thinking that having simplified rules in your markup that try to
describe image sizes related directly to device size would be tricky to
match with more advanced rules in CSS (eg. responsive images inside nested
rows)... That's why everything mentioned in srcoptions is related to
element-width as opposed to device-width. That said - I'm all for making
layouts simpler (avoid nested rows and whatnot) to be able to get
bulletproof preloading. It's just nearly impossible when image layout
absolutely _has_ to follow a fluid grid system.
Device-pixel-ratio can be quite relevant to include in urls; with an 2x
image compression artifacts in lossy formats (jpg, webp) are less visible
which in turn means you can crank up compression without losing visible
quality while getting an image that'll weigh roughly the same as the
equivalent 1x image. It's a very nice trick :)
The naming convention isn't set in stone - that was what the urlpattern was
for. Tweaking of how the actual options should be written is open for
suggestions. It might as well be written like this if that suits better:
img src=/path/to/image-200-300-1x.jpg width=200 height=300
srcoptions=/path/to/image-{width}-{height}-{dpr}x.{format};
200x300, 400x600; 1, 1.33, 2; webp, jpg/
The point I still feel srcoptions get right is shortness; almost all
examples of picture/srcset/src-n/srcalt feature images in only one format.
Just adding support for an extra format in the markup examples leads to a
lot of duplication where in srcoptions you just add , webp - done! :)
On Sat, Jan 25, 2014 at 5:31 PM, pghj pghjvanblokl...@gmail.com wrote:
We could minimize it dramatically if only a url-pattern and the available
options are exposed instead of a long list of explicit urls:
img src=/path/to/foo-320w-240h-1x.jpg width=320 height=240
srcoptions=/path/to/foo-{width}-{height}-{dpr}.{format},320w 480w
640w, 1x 1.33x 2x, webp jpg/
Wouldn't this sort of thing be much easier to learn/read/write? Both
humans and machines.
I won't bother you with all the details here - I've tried to flesh out
the idea in this gist: https://gist.github.com/rasmusfl0e/6727092
I think srcset refers to maximum device size, and your srcoptions to image
sizes, so I'm not sure about the equivalence mentioned in the linked
document.
Wouldn't srcoptions produce many URL aliases? I'd say these are the same
image:
/path/to/foo-320w-240h-2x.jpg
/path/to/foo-640w-480h-1x.jpg
This would cause cache misses (in proxy servers), or introduce complexity
in the server for making redirects.
If srcoptions also intends for each image to be visually identical, I
don't see the point in including pixel densities anyway.
Furthermore, the naming convention will be incompatible with many existing
practices.
If compacting/DRYing of markup is an issue, I would propose the following
extension to srcalt:
img srcbase=/path/to/ srcalt=image200.jpg 200x300 5kB, image400.jpg
400x600 12kB /
img srcbase=/path/to/ srcalt=thumbnails/image.jpg 200x300 5kB, normal
/image.jpg 400x600 12kB /
img srcbase=/path/to/image.jpg srcalt=?w=200 200x300 5kB, ?w=400
400x600 12kB /
img srcbase=/path/to/image.jpg srcalt=?s=small 200x300 5kB, ?s=large
400x600 12kB /
where the URI reference in srcbase is resolved against the document base
URI, and the references in srcalt are in turn resolved against that. A
number of alternative naming schemes are shown. The last two offer the
greatest opportunity for compacting markup.
Josh.
Re: [whatwg] responsive images srcalt proposal
Date: Sat, 25 Jan 2014 18:21:59 +0100 From: rasmusf...@gmail.com ... Device-pixel-ratio can be quite relevant to include in urls; with an 2x image compression artifacts in lossy formats (jpg, webp) are less visible which in turn means you can crank up compression without losing visible quality while getting an image that'll weigh roughly the same as the equivalent 1x image. It's a very nice trick :) The images might be identical and your proposal does not allow this to be expressed. It might be better to be able to enumerate all available images and to describe each so that the UA can make a choice. cheers Fred
Re: [whatwg] responsive images srcalt proposal
If you don't actually _do_ anything based on device-pixel-ratio besides
ramping up the dimensions you could just leave dpr out and let the
useragent figure out if it wants pick a higher res image:
img src=/path/to/image-200-300.jpg width=200 height=300
srcoptions=/path/to/image-{width}-{height}.{format};200x300,
400x600, 800x1200; webp, jpg/
For sure srcoptions caters for automation/systematic naming. I don't think
that is a bad thing :)
On Sun, Jan 26, 2014 at 4:48 AM, Fred Andrews freda...@live.com wrote:
Date: Sat, 25 Jan 2014 18:21:59 +0100
From: rasmusf...@gmail.com
...
Device-pixel-ratio can be quite relevant to include in urls; with an 2x
image compression artifacts in lossy formats (jpg, webp) are less visible
which in turn means you can crank up compression without losing visible
quality while getting an image that'll weigh roughly the same as the
equivalent 1x image. It's a very nice trick :)
The images might be identical and your proposal does not allow this to be
expressed. It might be better to be able to enumerate all available images
and to describe each so that the UA can make a choice.
cheers
Fred
Re: [whatwg] responsive images srcalt proposal
There are still some pre-loader issues. Google is promoting that the CDN dynamically optimize the content, that the user agent share enough info to allow the CDN to do so - effectively moving a UA function to the cloud and making a service out of it! From a user privacy perspective this is not good. To counter this, any proposal needs to be competitive, and needs to support the pre-loader being able to make the same decisions that the CDN with some UA info could - it does not need to be any better. The picture element proposal addresses all the use cases. It might be even better if it's srcset also allowed the image height and file size to be specified as in your srcalt proposal, or if at least the parsing of the srcset tolerated other attributes rather than giving up so that is could be extended with other attribute hints in future. Could this be considered for the picture element proposal? cheers Fred Date: Sat, 25 Jan 2014 16:25:13 +0100 From: pghjvanblokl...@gmail.com To: dhtmlkitc...@gmail.com CC: wha...@whatwg.org; freda...@live.com; li...@ericportis.com; rasmusf...@gmail.com Subject: Re: [whatwg] responsive images srcalt proposal Thank all of you for your feedback. For clarification, the srcalt proposal is NOT intended to specify an (image) pre-loading mechanism. The pre-loading strategy I described earlier is just a suggestion for an implementation that I came up with to show that page loading performance does not need to suffer from srcalt, and might in fact be improved. The srcalt proposal is basically just img src=image0.jpg srcalt=image0.jpg 200x150 10kB, image1.jpg 100x75 4kB, image2.jpg 400x300 16kB/ and the fact that the browser has great freedom in deciding when to load which image when srcalt is present (even until after the page load event has been fired). The source alternatives (imageN.jpg in the example) are supposed to be visually identical, and differ only in resolution/quality/file size. I completely agree with Fred that too much emphasis is on pre-loader optimization, but that is exactly what srcalt intends to avoid. Most of the other proposals that I read seem to be about spoon-feeding the pre-loader. Srcalt just tells what image sources are available to pick from. An advantage of srcalt for authors is that they only need to worry about display resolutions, physical screen size and design breakpoints when they are writing their stylesheets, and can leave the choice of img source to the browser. An advantage of srcalt for users is that they can instruct their browser to safe bandwidth/increase speed through always loading the smaller sources, because all sources are supposed to be visually identical (unlike in other proposals). Srcalt leaves switching between visually different images to stylesheets, treating images and other content equally: div class='smallscreen' img src='closeup.jpg' srcalt='...' / little bit of text /div div class='largescreen' img src='overview.jpg' srcalt='...' / lots of text /div I was wondering how people feel about this separation of concerns. In my opinion having one img element representing one conceptually unique piece of information is superior to the 'it depends on external conditions what it represents' approach of other proposals (the art-direction/media features use cases). Anyone like to comment on this? Thank you for reading. Josh.
Re: [whatwg] responsive images srcalt proposal
On 12/11/13, Fred Andrews freda...@live.com wrote:
The problem with a prescriptive standard for pre-loading images is that it
might be abused by content authors for other purposes. I would like to see
UAs able to implement a wide range of image loading strategies using the
available information, including ignoring any pre-loading hints, and this
might be necessary for reloading from a cache.
I am open to other ways to specify the available images, and there have been
many proposals.
A src property in css:
@media only screen and (max-width: 500px) {
#main-pic {
src: url(/img/main-100.png);
}
}
img src=main.jpg alt=San Diego Zoo
Unsupported browsers use the HTML src attribute.
Newer browsers download the src only for the most specific matching
CSS for that replaced element and img.src is the img.usedSrc are the
images source that are applied, img.getAttribute(src) is the HTML
attribute.
--
Garrett
@xkit
ChordCycles.com
garretts.github.io
Re: [whatwg] responsive images srcalt proposal
On 12/15/13, Garrett Smith dhtmlkitc...@gmail.com wrote: On 12/11/13, Fred Andrews freda...@live.com wrote: Correction: img src=main.jpg alt=San Diego Zoo img id=main-pic src=main.jpg alt=San Diego Zoo -- Garrett @xkit ChordCycles.com garretts.github.io
Re: [whatwg] responsive images srcalt proposal
Adding 'srcalt' does not seem warranted. The steps seem too prescriptive for a standard, but might represent one possible implementation. I think too much weight is being put on the pre-loader optimization and do not believe this should block a declarative solution that informs the UA of the available image options. Some argue that it is only for the benefit of the pre-loader, that otherwise it could all be done in JS, but surely we are here to settling on declarative HTML that can be used without JS! The src-N proposal appears to be a genuine attempt to meet all the use cases. cheers Fred Date: Wed, 4 Dec 2013 18:16:39 +0100 From: pghjvanblokl...@gmail.com To: wha...@whatwg.org CC: li...@ericportis.com Subject: Re: [whatwg] responsive images srcalt proposal Thanks to some feedback I got, I worked out the preloading algorithm in some more detail. It will enable efficient preloading of images in my srcalt proposal, as well as images with the proposed postpone attribute, and improve overall performance. The algorithm is meant to supersede the simple preload scanners that are currently implemented. In short, this algorithm will, when downloading is stalled by JS, calculate layout on a separate DOM as if javascript were disabled, in order to decide which srcalt, postponed and CSS background images should be downloaded and with what priority. 1.) Start downloading all CSS, JS, and img without srcalt and postpone attributes (*1). Always reserve one socket for downloading each of the three file types (*2). Prioritize on CSS and JS. 2.) As soon as all CSS and the document source are downloaded, do one of the following: a.) If all JS has finished running, do layout and continue with step 3. b.) If JS is still running, build an independent DOM as if javascript were disabled, do layout on that and continue with step 3. 3.) Clear the download queue for images. With the given DOM and layout, start downloading the required images from CSS backgrounds, img src/srcalt and visible postponed images. Prioritize on images that will be immediately visible to the user. 4.) As soon as JS finishes, and step 2b was used, re-invoke step 3 for the real DOM (possibly altered by JS). Evaluate whether (too many) unnecessary images (srcalt/postpone/css backgrounds) were downloaded. If so, mark this for each category (srcalt/postpone/css) in a cache. Next time the same url is visited, delay downloading this category until JS finishes (*3). *1.) Images without postpone attribute are required for the load event. *2.) A server might have specific performance problems serving one type of file. By reserving sockets downloading can continue on the other file type(s). *3.) JS altering the DOM to such an extend that the wrong images got downloaded is probably quite rare, but this step will counter the bandwidth penalty after the first visit. Developer modes of browsers should issue a warning when this occurs. Compared to the current preload scanners, this implementation will: * support srcalt responsive images, * support postpone attributes on images, * allow for earlier download of postponed images and CSS backgrounds, * can prioritize on all images that are immediately visible to the user. In this scenario srcalt images can never start downloading until document source and all CSS has been obtained. This might result in a slight performance loss when responsive images are used. However, since most HTML and CSS downloads fast (once the server starts sending) and CSS is mostly cached anyway, in practice this will effect only a very few page visits. Depending on available bandwidth and user preference, UAs could also compensate for this delay by preloading a srcalt candidate by making an educated guess. Thank you for reading, Josh
Re: [whatwg] responsive images srcalt proposal
I agree with Josh regarding preloading of images though.
I also think that the current proposals are bordering on being too
cumbersome and verbose.
We could minimize it dramatically if only a url-pattern and the available
options are exposed instead of a long list of explicit urls:
img src=/path/to/foo-320w-240h-1x.jpg width=320 height=240
srcoptions=/path/to/foo-{width}-{height}-{dpr}.{format},320w
480w 640w, 1x 1.33x 2x, webp jpg/
Wouldn't this sort of thing be much easier to learn/read/write? Both humans
and machines.
I won't bother you with all the details here - I've tried to flesh out the
idea in this gist: https://gist.github.com/rasmusfl0e/6727092
On Thu, Dec 12, 2013 at 1:53 AM, Fred Andrews freda...@live.com wrote:
Adding 'srcalt' does not seem warranted.
The steps seem too prescriptive for a standard, but might represent one
possible implementation.
I think too much weight is being put on the pre-loader optimization and do
not believe this should block a declarative solution that informs the UA of
the available image options. Some argue that it is only for the benefit
of the pre-loader, that otherwise it could all be done in JS, but surely we
are here to settling on declarative HTML that can be used without JS!
The src-N proposal appears to be a genuine attempt to meet all the use
cases.
cheers
Fred
Date: Wed, 4 Dec 2013 18:16:39 +0100
From: pghjvanblokl...@gmail.com
To: wha...@whatwg.org
CC: li...@ericportis.com
Subject: Re: [whatwg] responsive images srcalt proposal
Thanks to some feedback I got, I worked out the preloading algorithm in
some more detail.
It will enable efficient preloading of images in my srcalt proposal, as
well as images with the proposed postpone attribute, and improve overall
performance. The algorithm is meant to supersede the simple preload
scanners that are currently implemented.
In short, this algorithm will, when downloading is stalled by JS,
calculate
layout on a separate DOM as if javascript were disabled, in order to
decide
which srcalt, postponed and CSS background images should be downloaded
and
with what priority.
1.) Start downloading all CSS, JS, and img without srcalt and postpone
attributes (*1). Always reserve one socket for downloading each of the
three file types (*2). Prioritize on CSS and JS.
2.) As soon as all CSS and the document source are downloaded, do one of
the following:
a.) If all JS has finished running, do layout and continue with step 3.
b.) If JS is still running, build an independent DOM as if javascript
were
disabled, do layout on that and continue with step 3.
3.) Clear the download queue for images. With the given DOM and layout,
start downloading the required images from CSS backgrounds, img
src/srcalt and visible postponed images. Prioritize on images that will
be
immediately visible to the user.
4.) As soon as JS finishes, and step 2b was used, re-invoke step 3 for
the
real DOM (possibly altered by JS). Evaluate whether (too many)
unnecessary
images (srcalt/postpone/css backgrounds) were downloaded. If so, mark
this
for each category (srcalt/postpone/css) in a cache. Next time the same
url
is visited, delay downloading this category until JS finishes (*3).
*1.) Images without postpone attribute are required for the load event.
*2.) A server might have specific performance problems serving one type
of
file. By reserving sockets downloading can continue on the other file
type(s).
*3.) JS altering the DOM to such an extend that the wrong images got
downloaded is probably quite rare, but this step will counter the
bandwidth
penalty after the first visit. Developer modes of browsers should issue a
warning when this occurs.
Compared to the current preload scanners, this implementation will:
* support srcalt responsive images,
* support postpone attributes on images,
* allow for earlier download of postponed images and CSS backgrounds,
* can prioritize on all images that are immediately visible to the user.
In this scenario srcalt images can never start downloading until
document
source and all CSS has been obtained. This might result in a slight
performance loss when responsive images are used. However, since most
HTML
and CSS downloads fast (once the server starts sending) and CSS is mostly
cached anyway, in practice this will effect only a very few page visits.
Depending on available bandwidth and user preference, UAs could also
compensate for this delay by preloading a srcalt candidate by making an
educated guess.
Thank you for reading,
Josh
Re: [whatwg] responsive images srcalt proposal
The problem with a prescriptive standard for pre-loading images is that it
might be abused by content authors for other purposes. I would like to see UAs
able to implement a wide range of image loading strategies using the available
information, including ignoring any pre-loading hints, and this might be
necessary for reloading from a cache.
I am open to other ways to specify the available images, and there have been
many proposals.
cheers
Fred
Date: Thu, 12 Dec 2013 02:13:58 +0100
From: rasmusf...@gmail.com
To: freda...@live.com
CC: pghjvanblokl...@gmail.com; li...@ericportis.com; wha...@whatwg.org
Subject: Re: [whatwg] responsive images srcalt proposal
I agree with Josh regarding preloading of images though.
I also think that the current proposals are bordering on being too
cumbersome and verbose.
We could minimize it dramatically if only a url-pattern and the available
options are exposed instead of a long list of explicit urls:
img src=/path/to/foo-320w-240h-1x.jpg width=320 height=240
srcoptions=/path/to/foo-{width}-{height}-{dpr}.{format},320w
480w 640w, 1x 1.33x 2x, webp jpg/
Wouldn't this sort of thing be much easier to learn/read/write? Both humans
and machines.
I won't bother you with all the details here - I've tried to flesh out the
idea in this gist: https://gist.github.com/rasmusfl0e/6727092
On Thu, Dec 12, 2013 at 1:53 AM, Fred Andrews freda...@live.com wrote:
Adding 'srcalt' does not seem warranted.
The steps seem too prescriptive for a standard, but might represent one
possible implementation.
I think too much weight is being put on the pre-loader optimization and do
not believe this should block a declarative solution that informs the UA of
the available image options. Some argue that it is only for the benefit
of the pre-loader, that otherwise it could all be done in JS, but surely we
are here to settling on declarative HTML that can be used without JS!
The src-N proposal appears to be a genuine attempt to meet all the use
cases.
cheers
Fred
Date: Wed, 4 Dec 2013 18:16:39 +0100
From: pghjvanblokl...@gmail.com
To: wha...@whatwg.org
CC: li...@ericportis.com
Subject: Re: [whatwg] responsive images srcalt proposal
Thanks to some feedback I got, I worked out the preloading algorithm in
some more detail.
It will enable efficient preloading of images in my srcalt proposal, as
well as images with the proposed postpone attribute, and improve overall
performance. The algorithm is meant to supersede the simple preload
scanners that are currently implemented.
In short, this algorithm will, when downloading is stalled by JS,
calculate
layout on a separate DOM as if javascript were disabled, in order to
decide
which srcalt, postponed and CSS background images should be downloaded
and
with what priority.
1.) Start downloading all CSS, JS, and img without srcalt and postpone
attributes (*1). Always reserve one socket for downloading each of the
three file types (*2). Prioritize on CSS and JS.
2.) As soon as all CSS and the document source are downloaded, do one of
the following:
a.) If all JS has finished running, do layout and continue with step 3.
b.) If JS is still running, build an independent DOM as if javascript
were
disabled, do layout on that and continue with step 3.
3.) Clear the download queue for images. With the given DOM and layout,
start downloading the required images from CSS backgrounds, img
src/srcalt and visible postponed images. Prioritize on images that will
be
immediately visible to the user.
4.) As soon as JS finishes, and step 2b was used, re-invoke step 3 for
the
real DOM (possibly altered by JS). Evaluate whether (too many)
unnecessary
images (srcalt/postpone/css backgrounds) were downloaded. If so, mark
this
for each category (srcalt/postpone/css) in a cache. Next time the same
url
is visited, delay downloading this category until JS finishes (*3).
*1.) Images without postpone attribute are required for the load event.
*2.) A server might have specific performance problems serving one type
of
file. By reserving sockets downloading can continue on the other file
type(s).
*3.) JS altering the DOM to such an extend that the wrong images got
downloaded is probably quite rare, but this step will counter the
bandwidth
penalty after the first visit. Developer modes of browsers should issue a
warning when this occurs.
Compared to the current preload scanners, this implementation will:
* support srcalt responsive images,
* support postpone attributes on images,
* allow for earlier download of postponed images and CSS backgrounds,
* can prioritize on all images that are immediately visible to the user.
In this scenario srcalt images can never start downloading
Re: [whatwg] responsive images srcalt proposal
Thanks to some feedback I got, I worked out the preloading algorithm in some more detail. It will enable efficient preloading of images in my srcalt proposal, as well as images with the proposed postpone attribute, and improve overall performance. The algorithm is meant to supersede the simple preload scanners that are currently implemented. In short, this algorithm will, when downloading is stalled by JS, calculate layout on a separate DOM as if javascript were disabled, in order to decide which srcalt, postponed and CSS background images should be downloaded and with what priority. 1.) Start downloading all CSS, JS, and img without srcalt and postpone attributes (*1). Always reserve one socket for downloading each of the three file types (*2). Prioritize on CSS and JS. 2.) As soon as all CSS and the document source are downloaded, do one of the following: a.) If all JS has finished running, do layout and continue with step 3. b.) If JS is still running, build an independent DOM as if javascript were disabled, do layout on that and continue with step 3. 3.) Clear the download queue for images. With the given DOM and layout, start downloading the required images from CSS backgrounds, img src/srcalt and visible postponed images. Prioritize on images that will be immediately visible to the user. 4.) As soon as JS finishes, and step 2b was used, re-invoke step 3 for the real DOM (possibly altered by JS). Evaluate whether (too many) unnecessary images (srcalt/postpone/css backgrounds) were downloaded. If so, mark this for each category (srcalt/postpone/css) in a cache. Next time the same url is visited, delay downloading this category until JS finishes (*3). *1.) Images without postpone attribute are required for the load event. *2.) A server might have specific performance problems serving one type of file. By reserving sockets downloading can continue on the other file type(s). *3.) JS altering the DOM to such an extend that the wrong images got downloaded is probably quite rare, but this step will counter the bandwidth penalty after the first visit. Developer modes of browsers should issue a warning when this occurs. Compared to the current preload scanners, this implementation will: * support srcalt responsive images, * support postpone attributes on images, * allow for earlier download of postponed images and CSS backgrounds, * can prioritize on all images that are immediately visible to the user. In this scenario srcalt images can never start downloading until document source and all CSS has been obtained. This might result in a slight performance loss when responsive images are used. However, since most HTML and CSS downloads fast (once the server starts sending) and CSS is mostly cached anyway, in practice this will effect only a very few page visits. Depending on available bandwidth and user preference, UAs could also compensate for this delay by preloading a srcalt candidate by making an educated guess. Thank you for reading, Josh
[whatwg] responsive images srcalt proposal
I'm resending this (slightly updated) message because the first didn't appear to get delivered. Concerning responsive images, I will make the case that: * Art-direction matching media features/types should not be part of a responsive image solution. * The benefits of a preload-scanner are overrated when it comes to images from img elements. * There is a more elegant solution than srcset, src-N and picture ART-DIRECTION MATCHING MEDIA FEATURES/TYPES I don't think the Art-direction issue should be solved at the img level, because it's just a special case of another problem and replicates a solution already provided by CSS. For example, providing a less detailed image might very well require a change in accompanying text as well: div class='desktop' img src='moredetail.jpg' the red arrows indicate your troop movements /div div class='mobile' img src='lessdetail.jpg' click on the image to view details /div ...where a stylesheet hides one of either representations. I'd rather leave Art-direction in the CSS domain as a one-size-fits-all solution, even if it concerns just images. The same argument goes for matching media features and media types. The images in the pie-chart example given at http://usecases.responsiveimages.org happen to contain the text about the colour keys. Were this not the case, a solution like the one I gave above would still be needed. RESOLUTION-SIZE-DISCRIMINATION Moving on to resolution/size discrimination: I don't like any of the proposed solutions so far, because of their complexity, and because they replicate functionality in CSS, requiring the web-designer to mark-up style in two places and keep them in sync. As I see it, the complexity of these solutions derives from the attempt to feed preload-scanners with partial style information that would otherwise only become available at a later stage. As Maciej Stachowiak put it, the fundamental thing that's missing is ability to have one of several images correctly selected by the browser at preload time But how important is this, really? Measurements show a ~20% speed increase when a preload-scanner is enabled, but how much of that can be attributed to preloading images from img elements? More importantly, does preloading these images help with perceived speed? I'd say not much: often most of them are outside the visible area, make up only a small surface relative to the whole page, and the page renders fine before they are loaded, especially when the dimensions are known through attributes or CSS. Preloading them can actually delay the loading of more important images from CSS, which does degrade the perceived speed very much. In fact, many efforts are made to bypass the preload scanner to avoid loading images before they are scrolled into view, to increase speed, conserve bandwidth, or both. For those convinced of the necessity of a preload-scanner for img elements, I am willing to provide a detailed overview of why the available test-results are misleading, how image preloading harms browser performance, and what would be a better way to preload images. Also, as a matter of principle, I don't think it is desirable that optimizations in today's browsers justify extending the html specification with constructs as complicated as the solutions proposed so far. Therefore, under the assumption that the importance of a preload scanner is overrated with respect to img images, I would like to propose the following alternative approach: PROPOSAL For responsive images, we forsake any (real or imagined) benefits from the preload-scanner, and just give the browser all the information we have on image candidates to let it figure things out for itself. Example: img src=default.jpg srcalt=default.jpg 200x150 10kB, small.jpg 100x75 4kB, large.jpg 400x300 16kB/ With this information, the browser can decide (after initial layout), based on display properties and user preferences about quality, loading-time, and bandwidth conservation, which image best suits its needs. The exact syntax is of course open to discussion: I just wanted to put forward the general idea. Pros: * very easy to write and understand * very compact * avoids complexity * very good opportunity for quality/speed/bandwidth trade-offs * doesn't turn HTML ugly (at least far less than other proposals) * no preload scanner Cons (maybe): * no preload scanner There are some interesting variations possible on this approach. In the following example, only the alternative sources are enumerated, but not their properties: img src=default.jpg srcalt=small.jpg large.jpg/ In this case, the browser could make a series of pipelined HEAD requests on these sources, and the server would report the size (through Content-Length) and image dimensions (through a specialised response header) for each image. This would eliminate the dependency of HTML-source on properties of these images, or knowledge of them during page generation, which some might find preferable. Thank you
Re: [whatwg] Responsive images using http headers
Thanks for your answer, Boris. I understand the problem. Sending only the window dimmensions, screen resolution and other useful information available in media-queries can be enought. For example: Viewport: width=1024px; height=768px; scale=1; Or even connection information: Connection: type=2G; On Mon, Jun 25, 2012 at 8:10 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/25/12 1:34 PM, Oscar Otero wrote: For example, for an image 100% width in a div of 400px, the browser would send a header indicating it need a 400px width image. The problem is that the browser typically does not know the following pieces of information when it sends the image request: 1) The styles of the image. 2) The parent of the image (or even whether the parent is unique; image loads are coalesced if the same URL appears in the page multiple times). It could have that information available if it waited a lot longer to request images [1], but right now browsers try to kick off requests as soon as they can. For example in this example: !doctype html link rel=stylesheet href=something.css img src=whatever browsers will currently start loading the image before the stylesheet is done loading. With your proposal they would have to stop doing that, right? -Boris [1] Though in cases like this: table width=200px tr td img src=img1 style=width: 100% /td td img src=img2 style=width: 100% /td /tr /table the actual layout width of either image can't be determined until the intrinsic size of both images is known. There are lots of other cases like this involving flexbox, floats, etc, etc. -Boris
Re: [whatwg] Responsive images using http headers
On 6/26/12 4:41 AM, Oscar Otero wrote: I understand the problem. Sending only the window dimmensions, screen resolution and other useful information available in media-queries can be enought. For example: Viewport: width=1024px; height=768px; scale=1; Or even connection information: Connection: type=2G; I think those have been proposed before. Worth looking into why those proposals didn't get traction. Note, by the way, that in the case of subframes the viewport dimensions are _also_ not available when image loads kick off. -Boris
Re: [whatwg] Responsive images using http headers
Le 25 juin 2012 à 13:34, Oscar Otero a écrit :
For example, for an image 100% width in a div of 400px, the browser would
send a header indicating it need a 400px width image. This solution is also
valid for css images (backgrounds, for example) and even for video. The
values to send could be the same of css values (width, min-width, max-width,
height, min-height, max-height), for example:
Content-Size: width:400px, min-height: 300px;
There has been a similar proposal for a long time but which has never really
been implemented. It was called Transparent Content Negotiation [1] because
it was explicitly listing the alternate available resources for a specific URI.
I was wondering about the possibility of negotiating that way too. [2].
Alternates: {bigpussycat {size 1Mo} {dpi 300}},
{pussycat {size 100ko} {dpi 72}},
{tinypussycat {size 10ko} {dpi 72}
or could be something else for keywords and relevant information. This solution
doesn't really work with the following constraints.
* The client (and owner of the client) knows best about its capabilities and
its context.
* The server knows about the available resources.
* Avoid HTTP Round Trips to discover what are the available resources (HTTP
HEAD, then GET)
You could imagine a system where the parent resource is the one containing
the information about all alternate children. But that would make quite a lot
of HTTP headers. No perfect solution.
[1]: http://tools.ietf.org/html/rfc2295
[2]:
http://my.opera.com/karlcow/blog/2011/12/08/responsive-images-and-transparent-content-negotiation-in-http
--
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software
Re: [whatwg] Responsive images using http headers
Am 26.06.2012 um 15:52 schrieb Boris Zbarsky: On 6/26/12 4:41 AM, Oscar Otero wrote: I understand the problem. Sending only the window dimmensions, screen resolution and other useful information available in media-queries can be enought. For example: Viewport: width=1024px; height=768px; scale=1; Or even connection information: Connection: type=2G; I think those have been proposed before. Worth looking into why those proposals didn't get traction. Note, by the way, that in the case of subframes the viewport dimensions are _also_ not available when image loads kick off. -Boris A responsive image cannot be determined by connection type. Not everyone on a slow connection will get a lowres-image. This is what a developer has to decide which way to go or otherwise (approach of WHATWG - srcset / resolution based) the browser has to decide. Also, what happens if there's a new type of connection available in future – you cannot rely on browser updates then. -Anselm
[whatwg] Responsive images using http headers
Hello I'm Oscar Otero and I have been following very closely the progress of responsive layouts image solutions (picture, srcset, etc). These solutions are html-based, so they can be easily managed by any designer/frontend developer, but the main problem is the html code is not reusable and hard to manage by content people or CMS systems. I think the responsiveness, when we are talking about images, is not a problem of content but a problem of the bandwidth and performance, so this problem might be solved when the image is requested by using http headers. We can manage the way the page is cached using http headers such Cache-Control, Last-Modified, etc. We do this to prevent too many requests, save bandwidth and improve navigation speed. The image size is the same issue. Then, if we the browser could send a header indicating the size which the image will be displayed in the current page layout (also the connection speed and other useful data) the server can send the most appropiate image (maybe preprocessing it). This is a clean solution, ease to manage and the content staff will not have to worry about image sizes. This solution does not have to replace other solutions (srcset, picture, etc) but improve them. For example, for an image 100% width in a div of 400px, the browser would send a header indicating it need a 400px width image. This solution is also valid for css images (backgrounds, for example) and even for video. The values to send could be the same of css values (width, min-width, max-width, height, min-height, max-height), for example: Content-Size: width:400px, min-height: 300px; The image could have a property to indicate the position of the anchor point to crop the image maintaining the most interesting areas visible (centered by default). The syntax for this property could be the same than the background-position css property. Thanks for reading this message. Best regards. Oscar Otero.
Re: [whatwg] Responsive images using http headers
On 6/25/12 1:34 PM, Oscar Otero wrote: For example, for an image 100% width in a div of 400px, the browser would send a header indicating it need a 400px width image. The problem is that the browser typically does not know the following pieces of information when it sends the image request: 1) The styles of the image. 2) The parent of the image (or even whether the parent is unique; image loads are coalesced if the same URL appears in the page multiple times). It could have that information available if it waited a lot longer to request images [1], but right now browsers try to kick off requests as soon as they can. For example in this example: !doctype html link rel=stylesheet href=something.css img src=whatever browsers will currently start loading the image before the stylesheet is done loading. With your proposal they would have to stop doing that, right? -Boris [1] Though in cases like this: table width=200px tr td img src=img1 style=width: 100% /td td img src=img2 style=width: 100% /td /tr /table the actual layout width of either image can't be determined until the intrinsic size of both images is known. There are lots of other cases like this involving flexbox, floats, etc, etc. -Boris
Re: [whatwg] responsive images
2012-05-22 13:53 Europe/Helsinki: Paul Court: img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Not to mention, what happens when a 3x device is released? Do I have to change all my code again? As I see it, there's no way around it. And the important point to notice is that this fact does not depend on the syntax. Also notice that it will be much less work to add the extra 3x declaration to the source than the work required to prepare and upload the (not yet created) 3x image variants. If your source format is some vector format, I'd suggest using an SVG image as 2x variant and be done with it. In the future, a 17x display will default to highest resolution variant you're providing and if that's an actual vector data, you'll be fine. -- Mikko
Re: [whatwg] responsive images
I've been trying to follow this thread for a week now, but I'm a bit lost, so
apologies if this is the wrong place.
As a HTML author and programmer, I just cannot see myself implementing the
current srcset proposal on sites. As a programmer, it has very much got what we
would call a bad code smell.
img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x,
face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h
Not to mention, what happens when a 3x device is released?
Do I have to change all my code again?
I'm also confused about what exactly 1x and 2x are. Is it 2x 72 or 2x 96?
and isn't 600-200@2 just the same as 1200-400@1?
Wouldn't it be more future proof, instead of making the author supply a never
ending string of image names, implement variable logic (I think first suggested
by Matthew Wilcox). However, instead of the suggestion of putting as a head
meta tag, perhaps the logic could be confined to the img tag (or a
picture tag to allow slightly smoother transition).
Perhaps something like this:-
picture
src=some.img?{width}-{height}@{dpi}
img src=some-fallback.img
/picture
You could then define a list of parameters that the browser supports as
replacements. Eg. viewport-width/height, dpi, density. This could also be
carried over to other tags.
It also allows the author to decide what to implement as a fallback / low
bandwidth option. Personally, I could make: img
src=some_{width}-{height}@{dpi}.png return a perfectly valid image on my
webserver if an older browser failed to substitute the params.
Like I said at the start, I'm a bit lost as a newcomer to the debate, but there
seems to be suggestions floating around for better / more future proof / more
elegant solutions than the srcset above, but they don't seem to be getting any
traction.
Paul
Re: [whatwg] responsive images
On 22 maj 2012, at 05:53, Paul Court p...@pmcnetworks.co.uk wrote:
As a HTML author and programmer, I just cannot see myself implementing the
current srcset proposal on sites. As a programmer, it has very much got what
we would call a bad code smell.
img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h
1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h
Not to mention, what happens when a 3x device is released?
2x image will be used, upscaled.
I think that 3x device is very very unlikely to ever happen, since 2x screens
are may be dense enough to have pixels smaller than human eye can see.
1x and 2x are. Is it 2x 72 or 2x 96?
and isn't 600-200@2 just the same as 1200-400@1?
'x' is not a media query, but property of the image.
600@2 is a higher quality version of 300@1.
Perhaps something like this:-
picture
src=some.img?{width}-{height}@{dpi}
img src=some-fallback.img
/picture
You could then define a list of parameters that the browser supports as
replacements. Eg. viewport-width/height, dpi, density. This could also be
carried over to other tags.
If width/height is a virwport size then it will generate lots of unique URLs
(requires server to generate many images and proxies to cache them separately),
and may generate lots of requests when window is resized.
It doesn't work with static file servers, and may be costly/problematic for
CDNs.
Another risk is that authors will create files only for size/DPI of iPhone and
iPad and never supply images for 3000 other resolutions of various Android
devices.
--
regards, Kornel
Re: [whatwg] responsive images
(I wish people would stop starting new threads about the same topic.) On Tue, May 22, 2012 at 5:53 AM, Paul Court p...@pmcnetworks.co.uk wrote: As a HTML author and programmer, I just cannot see myself implementing the current srcset proposal on sites. As a programmer, it has very much got what we would call a bad code smell. img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Actually, it's pretty clean; you've just made it ugly by sticking it all on one line. img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h It's no uglier than CSS syntaxes like background. Not to mention, what happens when a 3x device is released? Do I have to change all my code again? It'll use the best match, which is most likely the 2x version. I'm also confused about what exactly 1x and 2x are. Is it 2x 72 or 2x 96? It means two hardware pixels per CSS pixel, which is what you get on iPhones, and also what you'll get if the user has zoomed in by 2x (eg. ctrl-+ in most desktop browsers). It's not related to DPI. and isn't 600-200@2 just the same as 1200-400@1? First, 600w 200h does not mean a 600x200 image; it means an image targetting 600x200 screens. Some syntax changes have been discussed to make this more clear. Second, the 2x means the the width and height of the image are 1/2 the intrinsic dimensions of the image. For example, if you have a logo which is 400x150 on regular 1x displays, then a 2x option would be an 800x300 image which is displayed as if you wrote img src=url width=400 height=150. That means it takes the same amount of space in CSS pixels--400x150--but you get the higher detail from the 2x density screen (like iPhones), without changing the layout of the page. -- Glenn Maynard
Re: [whatwg] responsive images
On 2012-05-22 17:02, Glenn Maynard wrote: (I wish people would stop starting new threads about the same topic.) On Tue, May 22, 2012 at 5:53 AM, Paul Courtp...@pmcnetworks.co.uk wrote: As a HTML author and programmer, I just cannot see myself implementing the current srcset proposal on sites. As a programmer, it has very much got what we would call a bad code smell. img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Actually, it's pretty clean; you've just made it ugly by sticking it all on one line. img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h It's no uglier than CSS syntaxes like background. It may not be uglier but it's much more fragile as the examples and the prose in the spec give the impression that you can use the , to tokenize, which would be incorrect. ... Best regards, Julian
Re: [whatwg] responsive images
On Tue, May 22, 2012 at 3:53 AM, Paul Court p...@pmcnetworks.co.uk wrote: As a HTML author and programmer, I just cannot see myself implementing the current srcset proposal on sites. As a programmer, it has very much got what we would call a bad code smell. img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Not to mention, what happens when a 3x device is released? Do I have to change all my code again? In the short term, the 3x browser can choose to either download the 1x or 2x, whichever it feels would be better. If you want to address it directly, yes, you'd need to change your @srcsets to have a new 3x url as well. Unfortunately you can't get away from that unless you abstract the functionality into CSS or similar, which forces the images to start downloading later. I'm also confused about what exactly 1x and 2x are. Is it 2x 72 or 2x 96? Standard resolution for the web is 96dpi. and isn't 600-200@2 just the same as 1200-400@1? Yes and no. They have the same number of pixels, yes, and may even be the same image. However, the former has a better intrinsic size, which is used when you don't specify an explicit @width or @height. As well, the main reason for specifying a 2x image is that the browser *knows* that it's 2x, and so is probably about 4 times the size of 1x image in similar circumstances, plus is specifically designed for retina displays and the like. All of this is very useful information to allow the browser to decide which one to download. Wouldn't it be more future proof, instead of making the author supply a never ending string of image names, implement variable logic (I think first suggested by Matthew Wilcox). However, instead of the suggestion of putting as a head meta tag, perhaps the logic could be confined to the img tag (or a picture tag to allow slightly smoother transition). [snip details] That's a possibility, yes. However, it's substantially more complex, as it invokes an entirely new mechanism of url rewriting in addition to the existing complexity. It also means that every responsive image on your page needs to serve images for the full cross-product of things that you support - you can't, say, only do multiple resolutions for your large images. On Tue, May 22, 2012 at 7:26 AM, Kornel Lesiński kor...@geekhood.net wrote: I think that 3x device is very very unlikely to ever happen, since 2x screens are may be dense enough to have pixels smaller than human eye can see. Tell that to printers, which can easily hit 400+dpi. You need more than 2x before you make anti-aliasing fully unnecessary. ~TJ
Re: [whatwg] responsive images
On 22 maj 2012, at 15:57, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 22, 2012 at 7:26 AM, Kornel Lesi��ski kor...@geekhood.net wrote: I think that 3x device is very very unlikely to ever happen, since 2x screens are may be dense enough to have pixels smaller than human eye can see. Tell that to printers, which can easily hit 400+dpi. You need more than 2x before you make anti-aliasing fully unnecessary. Is making AA unnecessary a goal though? It seems to me that antialiasing isn't a complex or computationally expensive problem any more. -- regards, Kornel
Re: [whatwg] responsive images
On 5/22/2012 3:08 PM, Kornel Lesi��ski wrote: On 22 maj 2012, at 15:57, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 22, 2012 at 7:26 AM, Kornel Lesi��ski kor...@geekhood.net wrote: I think that 3x device is very very unlikely to ever happen, since 2x screens are may be dense enough to have pixels smaller than human eye can see. Tell that to printers, which can easily hit 400+dpi. You need more than 2x before you make anti-aliasing fully unnecessary. Is making AA unnecessary a goal though? It seems to me that antialiasing isn't a complex or computationally expensive problem any more. 3x may happen with browser zoom on desktop and on mobile -- Chrome goes to 500%. -Charles
Re: [whatwg] responsive images
On Tue, May 22, 2012 at 3:08 PM, Kornel Lesiński kor...@geekhood.net wrote: On 22 maj 2012, at 15:57, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 22, 2012 at 7:26 AM, Kornel Lesiński kor...@geekhood.net wrote: I think that 3x device is very very unlikely to ever happen, since 2x screens are may be dense enough to have pixels smaller than human eye can see. Tell that to printers, which can easily hit 400+dpi. You need more than 2x before you make anti-aliasing fully unnecessary. Is making AA unnecessary a goal though? It seems to me that antialiasing isn't a complex or computationally expensive problem any more. My friends on the rendering side assure me that AA is still an immensely annoying part of the platform, and *many* things in the code will end up *much* simpler when we can stop dealing with it. ~TJ
[whatwg] responsive images
Hi all! I've read this article http://www.alistapart.com/articles/responsive-images-and-web-standards-at-the-turning-point And I've got a suggestion to this problem. why don't we keep the current markup and use progressive images. this way the browser could decide what resolution he needs, and when to stop downloading. this would solve the problem -having different dpi-s, -having different size of images. -on the server the overall disk space needed would be smaller. -information downloaded by browser could be used to display bigger images later. -browser could automatically switch to 'low-res' mode when having poor / expensive internet connection. http://www.libpng.org/pub/png/book/chapter01.html#png.ch01.div.2.3 http://www.libpng.org/pub/png/book/chapter08.html#png.ch08.div.6 this problem should not be solved by html markup, i believe. best regards, Gabor
Re: [whatwg] responsive images
On Tue, May 22, 2012 at 12:39 AM, Gábor Szabó szabo.b.ga...@gmail.comwrote: why don't we keep the current markup and use progressive images. this way the browser could decide what resolution he needs, and when to stop downloading. this would solve the problem This doesn't work. You can't stop a TCP download on a dime, due to TCP windowing, and aborting a download kills pipelined transfers, which ruins performance. You'd need to know in advance how many bytes to download to receive a given number of JPEG passes, which complicates things a lot; you'd need to inline a pass count/byte range index, which creates a harsh data dependency. JPEG quality is also a different axis of quality than changing resolution; if you want to drop the resolution by 1/2x or 1/4x, you often really do want to use an image authored at a lower resolution rather than using a lower-quality image, especially for non-photographic art like icons. It doesn't really work for PNG, either, since partial interlaced PNGs are too low-quality to be of much practical use (at least JPEG gives a reasonable quality--but no alpha). -- Glenn Maynard
[whatwg] Responsive images and printing/zooming
Hello I try to follow the actual discussion with much interest and, I admit, not full understanding. If my inputs are inappropriate, please feel free to ignore this message. I read the current spec and huge parts of today's discussions to find out how images with multiple sources are intended to behave when printed, or when the page is zoomed, but I found no hints. I think some words on this might be useful in the spec, regardless of what the final syntax will be. 1. Print When a page is printed (or also converted to PDF or whatever), both viewport width and pixel ratio change. Are UAs expected to load the appropriate sources then? This could result in increased bandwidth, delayed printing, and IMHO a disturbed user experience, as the image may differ from the one seen on screen. Thus, I suggest to always use the resource actually shown on screen for printing. 2. Zoom On mobile devices, web pages are often zoomed out to fit the viewport width by default, the user is supposed to manually zoom in and scroll in order to read parts of pages. I understand that the whole thing about responsive design is to make this kind of zooming unnecessary, but in practice there will be all kinds of partly responsive designs using responsive images. Specially in cases where separate sources are given to match device pixel densities, zooming might matter, as for a zoomed-out page the low res image might be more than sufficient, but after zooming in the higher resolution might be appropriate. Which OTOH can disturb the user experience, when the images differ.
Re: [whatwg] Responsive images and printing/zooming
Markus Ernst derer...@gmx.ch wrote: I read the current spec and huge parts of today's discussions to find out how images with multiple sources are intended to behave when printed, or when the page is zoomed, but I found no hints. I think some words on this might be useful in the spec, regardless of what the final syntax will be. Both issues you are highlighting is in the domain of competing browsers to implement in the best way for their users/device/intended use case. They should not, IMHO, be part of the spec. I'll tell you how I see it: 1. Print When a page is printed (or also converted to PDF or whatever), both viewport width and pixel ratio change. Are UAs expected to load the appropriate sources then? This could result in increased bandwidth, delayed printing, and IMHO a disturbed user experience, as the image may differ from the one seen on screen. Thus, I suggest to always use the resource actually shown on screen for printing. They are not _required_ to do anything when those change. The spec draft does have an algorithm for updating img elements though: The user agent may at any time run the following algorithm to update an img element's image in order to react to changes in the environment. (User agents are not required to ever run this algorithm. http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates (Scoll way past the first algorithm, and you'll get to that algorithm) So it's up to the user agent to decide what to do in that case. I think it would be very nice to substitute the picture, if you can get one with a higher resolution. But it might even use the one it has in the preview, and download the big image while the user is using his time pressing options etc. Then, when the user agent has gotten the new image, it can dissolve the preview to use the new higher-res one - and also decide to use that one for the print. If it can't make the deadline (user hitting print), it can just use the one it has. Or another user agent that likes to nag its users might decide to nag the user. This is a place for quality of implementation (QoI), where browsers can compete on providing the best experience. I like it. 2. Zoom On mobile devices, web pages are often zoomed out to fit the viewport width by default, the user is supposed to manually zoom in and scroll in order to read parts of pages. I understand that the whole thing about responsive design is to make this kind of zooming unnecessary, but in practice there will be all kinds of partly responsive designs using responsive images. Specially in cases where separate sources are given to match device pixel densities, zooming might matter, as for a zoomed-out page the low res image might be more than sufficient, but after zooming in the higher resolution might be appropriate. Which OTOH can disturb the user experience, when the images differ. Yes, but you might get a quicker page load if you do the smallest one first. You can load that one and then when you're done with all the network activity, you can start a new job to download a bigger version in the background. You can substitute that one when you have it (or when the user zooms). Or the browser may choose to just load the one it wants for zoom straight away. It's decideable! If a browser does something that's ugly, the users of that browser will just have to bear with it, or switch to another one (hehe ;-) ). These are not things at a user experience level, that need to be interopable. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
