What about a proper image format with support for multiple resolutions? Similar to the way it's done in SVC (http://en.wikipedia.org/wiki/Scalable_Video_Coding)
Native Responsive Images
11–20 of 27 posts
Re: Native Responsive Images
#12Honestly, we're (collectively) never going to adopt this on a large scale. Everything I read in this article is just horribly complicated. I don't have a solution, but none of these are the right one. There's so much complexity going on that no developer will get it right without devoting a massive amount of time and effort just to load the "right" image at the "right" time. Honestly, I need to support retina screens…
> For non-retina screens getting a larger image doesn't really matter. Non retina mobile devices are rapidly disappearing. So therefore I'm comfortable delivering higher resolution images to all devices.
Must be nice to only have big-city first-worlders as users :)
Re: Native Responsive Images
#13For things like retina-aware images, e.g.: src="cat_500px.jpg" srcset="cat_750px.jpg 1.5x, cat_1000px.jpg 2x" Does anyone know if the browser will download a higher-res image once the user zooms in? E.g., in Chrome on OSX, if I zoom from 100% to 130% on a non-Retina display, will it download the 1.5x version and downsample it? Likewise, in iOS, if the initial zoom setting is "zoomed out", and "retina" is almost meani…
has existed for years, though.
Re: Native Responsive Images
#14What about a proper image format with support for multiple resolutions? Similar to the way it's done in SVC ( http://en.wikipedia.org/wiki/Scalable_Video_Coding )
That would add unnecessary data overhead as clients would get image data they may not need, e.g. a low-resolution device would not want a high-DPI version of all images on the site.
Re: Native Responsive Images
#15I used to rely on this, until some browsers suddenly stopped supporting it. It's a nice idea, but I recommend using retina.js (https://imulus.github.io/retinajs/) for consistency.
Re: Native Responsive Images
#16Earlier quoted context omitted.
I don't think this is a solution either. In most cases we don't need multiple images of vastly different sizes. Sizing images can be handled entirely through media queries. We aren't using multiple versions of each image, so there's no need for a js shim.
> Sizing images can be handled entirely through media queries. Unless something's changed since the last time I looked, media queries are only screenwise so they don't gracefully handle having a block in a small sidebar versus a "central" content section. The sidebar images could actually grow from a big to a small screen (because content is linearised and the "sidebar image" now takes the whole width of a small disp…
There's a simple rule I follow to solve that problem: If it goes in the sidebar (or a toolbar) it should be an SVG. It's the only way to ensure it will fit and scale no matter the screen size or device. With media queries you can even ensure that they get spaced properly (need more space between icons on smaller screens).
Pictures are they only problem that needs to be solved at this point.
Re: Native Responsive Images
#17Did I read that not carefully enough, or did the article really not explain what that "vw" unit is/stands for?
And what does the "calc(33vw - 100px)" do, apparently in void context?
Somehow I feel more confused after reading the article.
Re: Native Responsive Images
#18Did I read that not carefully enough, or did the article really not explain what that "vw" unit is/stands for? And what does the "calc(33vw - 100px)" do, apparently in void context? Somehow I feel more confused after reading the article.
I believe it stands for "viewport width" which is specified in percents over the width of the browser viewport.
Google has a first-class definition, too: https://www.google.com/search?q=css+vw+unit
Re: Native Responsive Images
#19> Unfortunately some browser vendors were reluctant to add new content negotiation-based solutions, because of past bad experience with this kind of solutions.
Can anyone provide more details of what they're talking about? I'm actually not too interested in naming names of browser vendors (which they were trying to avoid clearly) -- I'm more interested in details of the 'bad experiences', what was it (some people) thought went wrong with what particular aspects or areas of con-neg-based solutions in the past?
Re: Native Responsive Images
#20What about a proper image format with support for multiple resolutions? Similar to the way it's done in SVC ( http://en.wikipedia.org/wiki/Scalable_Video_Coding )
That would add unnecessary data overhead as clients would get image data they may not need, e.g. a low-resolution device would not want a high-DPI version of all images on the site.
Please read the wiki op linked.
> A subset video bitstream is derived by dropping packets from the larger video to reduce the bandwidth required for the subset bitstream. The subset bitstream can represent a lower spatial resolution (smaller screen), lower temporal resolution (lower frame rate), or lower quality video signal.