The devil has put a penalty on all things we enjoy in life.
Sixty-two percent of the weight of the web is images, and we’re serving more image bytes every day. That would be peachy if all of those bytes were being put to good use. But on small or low-resolution screens, most of that data is waste.
Why? Even though the web was designed to be accessed by everyone, via anything, it was only recently that the device landscape diversified enough to force an industry-wide movement toward responsive design. When we design responsively our content elegantly and efficiently flows into any device. All of our content, that is, except for bitmaps. Bitmap images are resolution-fixed. And their vessel—the venerable img with its sadly single src—affords no adaptation.
Faced with a Sophie’s choice—whether to make their pages fuzzy for some or slow for all—most designers choose the latter, sending images meant to fill the largest, highest-resolution screens to everybody. Thus, waste.
But! After three years of debate, a few new pieces of markup have emerged to solve the responsive images problem:
srcsetsizespicture- and our old friend
source(borrowed fromaudioandvideo)
These new elements and attributes allow us to mark up multiple, alternate sources, and serve each client the source that suits it best. They’ve made their way into the official specs and their first full implementation—in Chrome 38—shipped in September. With elegant fallbacks and a polyfill to bridge the gap, we can and should implement responsive images now. So, let’s!
Let’s take an existing web page and make its images responsive. We’ll do so in three passes, applying each piece of the new markup in turn:
- We’ll ensure that our images scale efficiently with
srcsetandsizes. - We’ll art direct our images with
pictureandsource media. - We’ll supply an alternate image format using
pictureandsource type.
In the process we’ll see firsthand the dramatic performance gains that the new features enable.
The status quo#section2
I guess I don’t so much mind being old, as I mind being fat and old.
We take as our subject a little web page about crazy quilts. It’s a simple, responsive page. There isn’t much to get in the way of its primary content: giant images (of quilts!). We want to show both the overall design of each quilt and as much intricate detail as possible. So, for each, we present two images:
- the whole quilt, fit to the paragraph width
- a detail that fills 100 percent of the viewport width
How would we size and mark up our images without the new markup?
First up: the whole quilts. To ensure that they’ll always look sharp, we need to figure out their largest-possible layout size. Here’s the relevant CSS:
* {
box-sizing: border-box;
}
body {
font-size: 1.25em;
}
figure {
padding: 0 1em;
max-width: 33em;
}
img {
display: block;
width: 100%;
}We can calculate the img’s largest-possible display width by taking the figure’s max-width, subtracting its padding, and converting ems to pixels:
100% <img> width
x ( 33em <figure> max-width
- 2em <figure> padding )
x 1.25em <body> font-size
x 16px default font-size
= 620pxOr, we can cheat by making the window really big and peeking at the dev tools:
(I prefer the second method.)
Either way we arrive at a maximum, full-quilt img display width of 620px. We’ll render our source images at twice that to accommodate 2x screens: 1,240 pixels wide.
But what to do about our detail images? They expand to fill the whole viewport, whose size has no fixed upper limit. So let’s pick something big-ish with a standard-y feel to it and render them at oh, say, up to 1,920 pixels wide.
When we render our images at those sizes our status-quo page weighs in at a hefty 3.5MB. All but 5.7kB of that is images. We can intuit that many of those image bytes constitute invisible overhead when delivered to small, low-resolution screens—but how many? Let’s get to work.
First pass: scaling with scrset and sizes#section3
Teatherball with a tennis ball for his shoelaces
Naturally adapt to have more than two faces
The first problem we’ll tackle: getting our images to scale efficiently across varying viewport widths and screen resolutions. We’ll offer up multiple resolutions of our image, so that we can selectively send giant sources to giant and/or high-resolution screens and smaller versions to everyone else. How? With srcset.
Here’s one of our full-viewport-width detail images:
<img
src="quilt_2-detail.jpg"
alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork." />quilt_2-detail.jpg measures 1,920 pixels wide. Let’s render two smaller versions to go along with it and mark them up like so:
<img
srcset="quilt_2/detail/large.jpg 1920w,
quilt_2/detail/medium.jpg 960w,
quilt_2/detail/small.jpg 480w"
src="quilt_2/detail/medium.jpg"
alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork.">The first thing to note about this img is that it still has a src, which will load in browsers that don’t support the new syntax.
For more capable clients, we’ve added something new: a srcset attribute, which contains a comma-separated list of resource URLs. After each URL we include a “width descriptor,” which specifies each image’s pixel width. Is your image 1024 x 768? Stick a 1024w after its URL in srcset. srcset-aware browsers use these pixel widths and everything else that they know about the current browsing environment to pick a source to load out of the set.
How do they choose? Here’s my favorite thing about srcset: we don’t know! We can’t know. The picking logic has been left intentionally unspecified.
The first proposed solutions to the responsive image problem attempted to give authors more control. We would be in charge, constructing exhaustive sets of media queries—contingency plans listing every combination of screen size and resolution, with a source custom-tailored for each.
srcset saves us from ourselves. Fine-grained control is still available when we need it (more on that later), but most of the time we’re better off handing over the keys and letting the browser decide. Browsers have a wealth of knowledge about a person’s screen, viewport, connection, and preferences. By ceding control—by describing our images rather than prescribing specific sources for myriad destinations—we allow the browser to bring that knowledge to bear. We get better (future-friendly!) functionality from far less code.
There is, however, a catch: picking a sensible source requires knowing the image’s layout size. But we can’t ask browsers to delay choosing until the page’s HTML, CSS, and JavaScript have all been loaded and parsed. So we need to give browsers an estimate of the image’s display width using another new attribute: sizes.
How have I managed to hide this inconvenient truth from you until now? The detail images on our example page are a special case. They occupy the full width of the viewport—100vw—which just so happens to be the default sizes value. Our full-quilt images, however, are fit to the paragraph width and often occupy significantly less real estate. It behooves us to tell the browser exactly how wide they’ll be with sizes.
sizes takes CSS lengths. So:
sizes="100px"…says to the browser: this image will display at a fixed width of 100px. Easy!
Our example is more complex. While the quilt imgs are styled with a simple width: 100% rule, the figures that house them have a max-width of 33em.
Luckily, sizes lets us do two things:
- It lets us supply multiple lengths in a comma-separated list.
- It lets us attach media conditions to lengths.
Like this:
sizes="(min-width: 33em) 33em, 100vw"That says: is the viewport wider than 33em? This image will be 33em wide. Otherwise, it’ll be 100vw.
That’s close to what we need, but won’t quite cut it. The relative nature of ems makes our example tricky. Our page’s body has a font-size of 1.25em, so “1em” in the context of our figure’s CSS will be 1.25 x the browser’s default font size. But within media conditions (and therefore, within sizes), an em is always equal to the default font size. Some multiplication by 1.25 is in order: 1.25 x 33 = 41.25.
sizes="(min-width: 41.25em) 41.25em,
100vw"That captures the width of our quilts pretty well, and frankly, it’s probably good enough. It’s 100 percent acceptable for sizes to provide the browser with a rough estimate of the img’s layout width; often, trading a tiny amount of precision for big gains in readability and maintainability is the right choice. That said, let’s go ahead and make our example exact by factoring in the em of padding on either side of the figure: 2 sides x 1.25 media-condition-ems each = 2.5ems of padding to account for.
<img
srcset="quilt_3/large.jpg 1240w,
quilt_3/medium.jpg 620w,
quilt_3/small.jpg 310w"
sizes="(min-width: 41.25em) 38.75em,
calc(100vw - 2.5em)"
src="quilt_3/medium.jpg"
alt="A crazy quilt whose irregular fabric scraps are fit into a lattice of diamonds." />Let’s review what we’ve done here. We’ve supplied the browser with large, medium, and small versions of our image using srcset and given their pixel widths using w descriptors. And we’ve told the browser how much layout real estate the images will occupy via sizes.
If this were a simple example, we could have given the browser a single CSS length like sizes="100px" or sizes="50vw". But we haven’t been so lucky. We had to give the browser two CSS lengths and state that the first length only applies when a certain media condition is true.
Thankfully, all of that work wasn’t in vain. Using srcset and sizes, we’ve given the browser everything that it needs to pick a source. Once it knows the pixel widths of the sources and the layout width of the img, the browser calculates the ratio of source-to-layout width for each source. So, say sizes returns 620px. A 620w source would have 1x the img’s px. A 1240w source would have 2x. 310w? 0.5x. The browser figures out those ratios and then picks whichever source it pleases.
It’s worth noting that the spec allows you to supply ratios directly and that sources without a descriptor get assigned a default ratio of 1x, allowing you to write markup like this:
<img src="standard.jpg" srcset="retina.jpg 2x, super-retina.jpg 3x" />That’s a nice, compact way to supply hi-DPI imagery. But! It only works for fixed-width images. All of the images on our crazy-quilts page are fluid, so this is the last we’ll hear about x descriptors.
Measuring up#section4
Now that we’ve rewritten our crazy-quilts page using srcset and sizes, what have we gained, in terms of performance?
Our page’s weight is now (gloriously!) responsive to browsing conditions. It varies, so we can’t represent it with a single number. I reloaded the page a bunch in Chrome and charted its weight across a range of viewport widths:
The flat, gray line up top represents the status-quo weight of 3.5MB. The thick (1x screen) and thin (2x) green lines represent the weight of our upgraded srcset’d and size’d page at every viewport width between 320px and 1280px.
On 2x, 320px-wide screens, we’ve cut our page’s weight by two-thirds—before, the page totaled 3.5MB; now we’re only sending 1.1MB over the wire. On 320px, 1x screens, our page is less than a tenth the weight it once was: 306kB.
From there, the byte sizes stair-step their way up as we load larger sources to fill larger viewports. On 2x devices we take a significant jump at viewport widths of ~350px and are back to the status-quo weight after 480px. On 1x screens, the savings are dramatic; we’re saving 70 to 80 percent of the original page’s weight until we pass 960px. There, we top out with a page that’s still ~40 percent smaller than what we started with.
These sorts of reductions—40 percent, 70 percent, 90 percent—should stop you in your tracks. We’re trimming nearly two and a half megabytes off of every Retina iPhone load. Measure that in milliseconds or multiply it by thousands of pageviews, and you’ll see what all of the fuss is about.
Second pass: picture and art direction#section5
srcsetif you’re lazy,pictureif you’re crazy™
So, for images that simply need to scale, we list our sources and their pixel widths in srcset, let the browser know how wide the img will display with sizes, and let go of our foolish desire for control. But! There will be times when we want to adapt our images in ways that go beyond scaling. When we do, we need to snatch some of that source-picking control right back. Enter picture.
Our detail images have a wide aspect ratio: 16:9. On large screens they look great, but on a phone they’re tiny. The stitching and embroidery that the details should show off are too small to make out.
It would be nice if we could “zoom in” on small screens, presenting a tighter, taller crop.
This kind of thing—tailoring image content to fit specific environments—is called “art direction.” Any time we crop or otherwise alter an image to fit a breakpoint (rather than simply resizing the whole thing), we’re art directing.
If we included zoomed-in crops in a srcset, there’s no telling when they’d get picked and when they wouldn’t. Using picture and source media, we can make our wishes explicit: only load the wide, rectangular crops when the viewport is wider than 36em. On smaller viewports, always load the squares.
<picture>
<!-- 16:9 crop -->
<source
media="(min-width: 36em)"
srcset="quilt_2/detail/large.jpg 1920w,
quilt_2/detail/medium.jpg 960w,
quilt_2/detail/small.jpg 480w" />
<!-- square crop -->
<source
srcset="quilt_2/square/large.jpg 822w,
quilt_2/square/medium.jpg 640w,
quilt_2/square/small.jpg 320w" />
<img
src="quilt_2/detail/medium.jpg"
alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork." />
</picture>A picture element contains any number of source elements and one img. The browser goes over the picture’s sources until it finds one whose media attribute matches the current environment. It sends that matching source’s srcset to the img, which is still the element that we “see” on the page.
Here’s a simpler case:
<picture>
<source media="(orientation: landscape)" srcset="landscape.jpg" />
<img src="portrait.jpg" alt="A rad wolf." />
</picture>On landscape-oriented viewports, landscape.jpg is fed to the img. When we’re in portrait (or if the browser doesn’t support picture) the img is left untouched, and portrait.jpg loads.
This behavior can be a little surprising if you’re used to audio and video. Unlike those elements, picture is an invisible wrapper: a magical span that’s simply feeding its img a srcset.
Another way to frame it: the img isn’t a fallback. We’re progressively enhancing the img by wrapping it in a picture.
In practice, this means that any styles that we want to apply to our rendered image need to be set on the img, not on the picture. picture { width: 100% } does nothing. picture > img { width: 100% } does what you want.
Here’s our crazy-quilts page with that pattern applied throughout. Keeping in mind that our aim in employing picture was to supply small-screened users with more (and more useful) pixels, let’s see how the performance stacks up:
Not bad! We’re sending a few more bytes to small 1x screens. But for somewhat complicated reasons having to do with the sizes of our source images, we’ve actually extended the range of screen sizes that see savings at 2x. The savings on our first-pass page stopped at 480px on 2x screens, but after our second pass, they continue until we hit 700px.
Our page now loads faster and looks better on smaller devices. And we’re not done with it yet.
Third pass: multiple formats with source type#section6
The 25-year history of the web has been dominated by two bitmap formats: JPEG and GIF. It took PNGs a painful decade to join that exclusive club. New formats like WebP and JPEG XR are knocking at the door, promising developers superior compression and offering useful features like alpha channels and lossless modes. But due to img’s sadly single src, adoption has been slow—developers need near-universal support for a format before they can deploy it. No longer. picture makes offering multiple formats easy by following the same source type pattern established by audio and video:
<picture>
<source type="image/svg+xml" srcset="logo.svg" />
<img src="logo.png" alt="RadWolf, Inc." />
</picture>If the browser supports a source’s type, it will send that source’s srcset to the img.
That’s a straightforward example, but when we layer source type-switching on top of our existing crazy-quilts page, say, to add WebP support, things get hairy (and repetitive):
<picture>
<!-- 16:9 crop -->
<source
type="image/webp"
media="(min-width: 36em)"
srcset="quilt_2/detail/large.webp 1920w,
quilt_2/detail/medium.webp 960w,
quilt_2/detail/small.webp 480w" />
<source
media="(min-width: 36em)"
srcset="quilt_2/detail/large.jpg 1920w,
quilt_2/detail/medium.jpg 960w,
quilt_2/detail/small.jpg 480w" />
<!-- square crop -->
<source
type="image/webp"
srcset="quilt_2/square/large.webp 822w,
quilt_2/square/medium.webp 640w,
quilt_2/square/small.webp 320w" />
<source
srcset="quilt_2/square/large.jpg 822w,
quilt_2/square/medium.jpg 640w,
quilt_2/square/small.jpg 320w" />
<img
src="quilt_2/detail/medium.jpg"
alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork." />
</picture>That’s a lot of code for one image. And we’re dealing with a large number of files now too: 12! Three resolutions, two formats, and two crops per image really add up. Everything we’ve gained in performance and functionality has come at a price paid in complexity upfront and maintainability down the road.
Automation is your friend; if your page is going to include massive code blocks referencing numerous alternate versions of an image, you’d do well to avoid authoring everything by hand.
So is knowing when enough is enough. I’ve thrown every tool in the spec at our example. That will almost never be prudent. Huge gains can be had by employing any one of the new features in isolation, and you should take a long, hard look the complexities of layering them before whipping out your claw and committing to the kitchen sink.
That said, let’s take a look at what WebP can do for our quilts.
An additional 25 to 30 percent savings on top of everything we’ve already achieved—not just at the low end, but across the board—certainly isn’t anything to sneeze at! My methodology here is in no way rigorous; your WebP performance may vary. The point is: new formats that provide significant benefits versus the JPEG/GIF/PNG status quo are already here, and will continue to arrive. picture and source type lower the barrier to entry, paving the way for image-format innovation forevermore.
size the day#section7
This is the secret of perfection:
When raw wood is carved, it becomes a tool;
[…]
The perfect carpenter leaves no wood to be carved.
For years, we’ve known what’s been weighing down our responsive pages: images. Huge ones, specially catered to huge screens, which we’ve been sending to everyone. We’ve known how to fix this problem for a while too: let us send different sources to different clients. New markup allows us to do exactly that. srcset lets us offer multiple versions of an image to browsers, which, with a little help from sizes, pick the most appropriate source to load out of the bunch. picture and source let us step in and exert a bit more control, ensuring that certain sources will be picked based on either media queries or file type support.
Together, these features let us mark up adaptable, flexible, responsive images. They let us send each of our users a source tailored to his or her device, enabling huge performance gains. Armed with a superb polyfill and an eye toward the future, developers should start using this markup now!
Great article. However I don’t like at all about this solution.
1 – this is way too complex and heavy markup language. Can you imagine yourselves doing that in 300 images in a web site? This will be a nightmare to manage.
2 – It goes against the separation of content and visual markup. It is a mess.
I see it as an important step to solve the responsive images problem but I think we can do much better than that and I believe that the path is automation. Something that should be explored at browser, server side or even a new image format.
Kaspar Allenbach 11:35 am on November 05, 2014 say:
I’ll probably start using this on my own site and for parts of client sites, but I’m wondering how to allow clients/users to upload their own images and still take advantage of this functionality. Are there any CMSs that support responsive images, even minimally?
—-
Adaptive display of photos and pictures. Bbcode tag photo
This gave me the idea of a cropping method based on a descendant list of important zones (maybe not new)
There are so many things wrong with these new responsive image systems.
Picture is what scares me the most. This notion of art directed images is bad news, even the example here is highlighting that. If I, as a content creator want you to see an image of let’s say this tapestry and it is a wide thing – that’s what I want you to see – not a square of it just because you have a smaller viewing screen and that is exactly what is going to happen. People everywhere serving up completely different images to what was intended and that is saying whatever the intended image was is not important and if that’s true, why did you put it on the page in the first place?
I spoke at UXCambridge about this last year and how selective cropping in the media has resulted in some pretty spectacular and sensationalised misrepresentations of events, this is allowing people to do that with anything and it is going to end horribly. I would rather have a big image that I can ‘pinch zoom’, because my device has been designed to enable that as a result of its small view window, than wanting to, for example, look at the new Kawasaki H2R only you decided to show me only the left hand indicator light because my device is small. This is just so, so bad for imagery and in particular photography on the web.
As so many have noted including @powrsurg I agree that this is not going to be thought through enough because someone somewhere needs to factor this into a system designed for people who actually produce and publish content and they do not have a clue what any of this means, they just want to make an image and add it to a page. Like with your CMS, most have image sizing options and even WordPress has had this for yonks, but again, this only solves one problem which is that of I have a file I have been given to use and it is 6MB and if I was to print it 1:1 it would be the size of a skyscraper billboard.
I’ve been trying to write something about my concerns with Picture in particular for a while but have found it hard to structure the argument. In producing these examples here it has helped me be able to see written down what I’ve been trying to say.
Great summary and I can see how from a perspective of progress to our authoring language this is good in some ways but isn’t picture just Object with a different name? Why have we not extended the existing img tag to allow for better width and height controls?
There’s a long long discussion here and I am sure it will be rolling on more now we have some browser support to experiment with. This can’t be the final solution though.
How about a little help from our friend the all mighty coders developing web servers so on the fly lossy scaling and compression based on the style sheet parameters defined by the Web Designer could be an standard extension.
Wouldn’t it would be a more elegant solution to summit a HQ master an modern format like JPEG XR and then have the server scale and compress it on the fly for maximum for the desired quality representations across any screen size and devices.
It’s a similar concept of what we already do with color profiles for each printer, screen and scanner model. A “simple” system, yet more complex that what has been requested from the Web Server, which enables the designers to abstract themselves from hardware (ceteris paribus) and enables them to accurately render and proof what would be the final output when it get backs from the printing press.
For me that’s where responsive design shoud go.
Please, don’t tell me that the servers will overload because they’ll not, as long as, they’re coded right. The problem is “lazy coding” and not a lack of resources (vast amounts of resources tend to derive in “Lazy Coding” and then “vast amounts” stop to be so vast and become not enough).
“Optimize, when you finish optimizing you code the optimize it a little bit more; ’cause it shall always be room for further optimization.”
“Less is more” by Ludwig Mies van der Rohe
Re: #47 Fredrik Jenson —
Thanks! Your tests are great!
Re: #48 Jonathan Hollin —
Sweet setup! Managing/marking up all of those versions gets tedious quick and all automation is good automation. I’ve got something sort of similar set up on my personal site, except it’s Jekyll and ImageMagick doing all of the dirty work at build time. Hopefully I can follow your lead and publish my workflow to GitHub sooner rather than later?
Re: Mike Lohrman #49 —
I’m sadly unfamiliar with ExpressionEngine, but that sounds like it does exactly what’s needed. As to the “do we need this?” question — you’d be surprised how slow most of the world’s internet connections are, have been, and probably will continue to be: http://responsivedesign.rferl.org/content/empathy-in-connection-speeds/25368750.html
Re: #50 Szymon Szybryt —
Totally automated, 3rd party server-side solutions like that can be great, but make sure that you’re not totally dependent on Javascript to show the user any image at all. Content images should be in markup, and not injected later via JS.
Re: #51 Mark De Souza Costa —
1) Hence all of the focus on automation of markup/image version generation down here in the comments. It is a lot to manage, even if you only have two or three separate sources per image. This is the cost of adaptability, at the moment.
2) I share your concerns. But this is the best that we can do at the moment, given the problem constraints.
Re: #53 Cahnory —
Woah! Cool!
Re: #54 Andy Parker —
I used to be a stickler about cropping, too. “That’s a presentational concern! The whole image is sacred, crop it with CSS if you must.” A couple of things swayed me to the “cropping is cool” camp. 1) seeing the performance gains of doing the cropping up front / not sending data to users that they’ll never see. 2) This post about adapting album art from vinyl LPs to fit cassettes. Cropping and art direction can be used poorly, but used well, they are an excellent tool to be able to show the user the essential thing that you are trying to show them (no pinch zoom required), no matter what their device. I tried with the quilt example to show this — if what you’re trying to show off are the stitches, unless you crop on small devices, they’re totally invisible. Cropping reveals, by zooming, what would have been lost by shrinking. It shouldn’t be used in every situation, but when it’s useful, it’s potentially very useful.
Re: #55 abetancort —
That’s my dream for authors, too. Stick one, high quality image somewhere, and let automated systems do the rest. I see this new markup as a building block / step towards that dream, and not something that displaces it.
Hi, not sure on the img src tag – shouldnt you use srcset else you will be downloading 2 images before polyfill kicks in?
Thanks for the article Eric, it’s a great help for me as I’m catching up on the changes in front-end development.
I am confused by Snippet 10 http://alistapart.com/article/responsive-images-in-practice#snippet10 however: the first
Alternatively, if that’s not true, when would the square be shown?
Hi Eric, have you inspected Crazy Quilt using Chrome’s Canary browser? I’m using the mobile emulator iPhone 4 view and it breaks for me, it seems to either lock up loading the images or simply ignore the layout entirely.
So what is the bottom line here for a production web application with such sparse support from mainstream browsers? Use media queries and load alternate css files appropriately?
Excellent article. Now to consume every bit of intelligence from it.
You guys should check out what we did for the Get Pre-Approved form at the top of the site that we used gravity forms for. Do a search for VA Loans Finance and IOM Partners of Houston, TX.
Very informative post. But I am not in favor of the solution which you provided for responsive image problem because this is a very complex and difficult to manage.
Please clarify what wood nymphs are so people don’t have their comments automatically deleted for a term they don’t understand.
wow, great article. THANKS for breaking down srcset and picture so clearly!
If you ask me, I think we’re barking up the wrong tree.
It seems that it would make most sense to look at image formats. Consider an interlaced/progressive JPG. If it can progressively load quality, why can’t progressively loading the image size work?
I got a question about sizes=”(min-width: 41.25em) 41.25em, 100vw”.
You say, that in media queries it takes the browser’s default em relative size. So shouldn’t the media query min-width: 41.25em still be 33em?
There are two interesting things I’ve noticed. First, the quote at the top from Einstein: “The devil has put a penalty on all things we enjoy in life.”
I believe it wasn’t the devil who did that. It was the people. They were the ones who made this insanely simple task of displaying an image a huge, complicated issue.
And the other thing I’ve noticed is that after all this great writeup, the article image at the top, is not responsive! Now what are the odds of preaching and practicing something completely different.
Here’s another oddity. People are worried so much about saving 40KB download, but at the same time they don’t have an issue paying $120/month for an unlimited data plan. DUH! If you’re so worried about kilobytes and saving the planet, purchase the cheapest data plan. People are just so out of touch with everything lately.
You saved 40KB of download. Great. At what cost? You had to store 3 times as many images on the server. Pfff.
I’m not saying all this responsive image blah blah is not great and doesn’t make sense. It is great. And it does make sense. Just not common sense.
Eventually people will realize in the (hopefully near) future, that they made everything so insanely complicated that they just need to return to basics and get a newspaper to read. A pencil and paper to draw. And walk over to the neighbor to talk.
We did some cool stuff with Visual Composer in WordPress after we were having hugely annoying issues by trying to use the responsive display using Revolution Slider. We inserted a “row” into the visual editor, set the size of the block to “Fill Width” and set the background image of the container’s width to 1920 so that it filled most people’s browser-width, even if they were larger. Rev Slider kept not ever playing nicely and we kept having to try all these hacks to, in the end, make it unsuccessful and just revert to the way we did it. I don’t want to URL spam but don’t hesitate to ask in case you’d like to see it in action.
Has anyone ever played around with a responsive image service like Respondy or ReSRCit ?
I’m a total newbie here so this article was way over my head for now.
How does all of this relate to frameworks such as Bootstrap? Don’t most frameworks these days already make their content, including images, responsive?
information about css and html code that is very helpful for me who is studying deeper .. keep working , thanks to quality article , if you need information about more try visiting..Jual Mukena Tasik