For including high-res graphics, but only for screens that can make use of them. “Retina” being “2x”:
@media
(-webkit-min-device-pixel-ratio: 2),
(min-resolution: 192dpi) {
/* Retina-specific stuff here */
}Or other highish-res:
/* 1.25 dpr */
@media
(-webkit-min-device-pixel-ratio: 1.25),
(min-resolution: 120dpi){
/* Retina-specific stuff here */
}
/* 1.3 dpr */
@media
(-webkit-min-device-pixel-ratio: 1.3),
(min-resolution: 124.8dpi){
/* Retina-specific stuff here */
}
/* 1.5 dpr */
@media
(-webkit-min-device-pixel-ratio: 1.5),
(min-resolution: 144dpi){
/* Retina-specific stuff here */
}Old Stuff (don’t use, keeping for posterity)
@media
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and ( min--moz-device-pixel-ratio: 2),
only screen and ( -o-min-device-pixel-ratio: 2/1) {
/* Retina-specific stuff here */
}This is more future proof…
@media
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and ( min--moz-device-pixel-ratio: 2),
only screen and ( -o-min-device-pixel-ratio: 2/1),
only screen and ( min-device-pixel-ratio: 2),
only screen and ( min-resolution: 192dpi),
only screen and ( min-resolution: 2dppx) {
/* Retina-specific stuff here */
}Notes:
- The super weird
min--moz-device-pixel-ratiois probably a bug, might wanna put in-moz-min-device-pixel-ratioalso in case they fix it but leave it prefixed. - Here’s the spec on resolution units.
Example:
Let’s say you had three major breakpoints in a design. This design also had a large background graphic and you wanted it looking it’s best on any screen (retina or not) and not waste any bandwidth. You’d set up 6 media queries, one for each breakpoint and one for each one of those breakpoints on retina. Then you’d override the background image all the way down.
@media only screen and (min-width: 320px) {
/* Small screen, non-retina */
}
@media
only screen and (-webkit-min-device-pixel-ratio: 2) and (min-width: 320px),
only screen and ( min--moz-device-pixel-ratio: 2) and (min-width: 320px),
only screen and ( -o-min-device-pixel-ratio: 2/1) and (min-width: 320px),
only screen and ( min-device-pixel-ratio: 2) and (min-width: 320px),
only screen and ( min-resolution: 192dpi) and (min-width: 320px),
only screen and ( min-resolution: 2dppx) and (min-width: 320px) {
/* Small screen, retina, stuff to override above media query */
}
@media only screen and (min-width: 700px) {
/* Medium screen, non-retina */
}
@media
only screen and (-webkit-min-device-pixel-ratio: 2) and (min-width: 700px),
only screen and ( min--moz-device-pixel-ratio: 2) and (min-width: 700px),
only screen and ( -o-min-device-pixel-ratio: 2/1) and (min-width: 700px),
only screen and ( min-device-pixel-ratio: 2) and (min-width: 700px),
only screen and ( min-resolution: 192dpi) and (min-width: 700px),
only screen and ( min-resolution: 2dppx) and (min-width: 700px) {
/* Medium screen, retina, stuff to override above media query */
}
@media only screen and (min-width: 1300px) {
/* Large screen, non-retina */
}
@media
only screen and (-webkit-min-device-pixel-ratio: 2) and (min-width: 1300px),
only screen and ( min--moz-device-pixel-ratio: 2) and (min-width: 1300px),
only screen and ( -o-min-device-pixel-ratio: 2/1) and (min-width: 1300px),
only screen and ( min-device-pixel-ratio: 2) and (min-width: 1300px),
only screen and ( min-resolution: 192dpi) and (min-width: 1300px),
only screen and ( min-resolution: 2dppx) and (min-width: 1300px) {
/* Large screen, retina, stuff to override above media query */
}
Is the Mozilla team aware of the typo in the declaration ?
Lol
the dev team is aware of it and as of firefox 16 they recommend exactly what is in the future proof version above.
Will we need to use media queries for non retina displays so the retina displays don’t download background images twice?
Yes, that would be a good idea.
But then devices without pixel-ratio (or any media query) support won’t see your “normal” resolution styles?
If you care about how much the user has to download, don’t implement the retina tax.
More pixels isn’t an excuse to force-feed huge images across slow mobile networks, costing users money – or for “unlimited” data plans, making them hit their data limit earlier in the month at which point their network slows down.
With a high pixel ratio, when the user zooms out, the device has more pixels to make the page readable. Be content with that, and don’t waste time and money on Retina-specific images. When there’s a way to detect a fast network and a high pixel ratio, maybe then it will be reasonable.
Using an inline style to load images dynamically as backgrounds in a WordPress theme, currently using the data-src and data-2x method. It seems like it might not degrade to IE8 well though. Something about IE8 only excepts the data-src attribute if its less than 32kb?
Anyone aware of how I could get this method to work on IE8?
These are great snippets, and making good use of them.
But thinking about this a bit more, iIsn’t this a bit of a Wild Goose Chase? Where does this end? There are consumer LCDs entering the marktet capable of 4k and 8K resolution. Is there a better solution to support this wide range of DPIs quickly approaching?
Is SVG the only viable future-friendly solution?
I second your argument Rob this is just maddening, em should be the standard for font management and svg the same for images, the web is just a collection of assembled hacks and there seems to be no going back. It was fun at times but its becoming annoying to say the least.
I believe the web has always been an assembly of hacks! Remember when tables were used build layouts? Images to display good typography?
In many ways, we’re now less hack-ey than ever!
(And yeah, SVG and icon fonts have an exciting future for graphics but not photos.)
I feel you on this Rob! I love Joel’s observation. Todays hacks are tomorrows accepted conventions.
Would you want to serve the same images to 1.5x screen ratios? There’s some android devices out here with weird ratios, I’d usually spec 2x images to everything from a 1.5 ratio up and contain them with background-size.
As someone pointed out this method also requires some thought as to how you’re going to support older browsers without media queries…. Mobile first default, IE stylesheets, or feature detected classes perhaps? (I favor the latter)
I thought long and hard about that until I found some JS out on the web that will basically add media query support to our grandpa holding up the fast lane… IE.
I start out by developing general base styles and make sure everything is decent between 1024-1280px wide, as this low-res is likely to be found on those who still use old IE. I set the body to max-width of 1280 so it stops scaling if old IE is running on a larger screen. Then, I set max-width back to 100% in a media query to let it use all the real-estate available. I add the JavaScript I mentioned above, then close IE immediately and discontinue any tweaking for it and begin building for real browsers. In the day that web clients want basically four interfaces in one, it’s just not feasible to assume you can build code for phones, tablets, SD, HD, “retina” iPads (seriously… people who buy iPads have no use for 3000px displays – this is ridiculous – they use them for Facebook) AND on top of all of it, support Internet Explorer 7? I get it, it’s all supposed to be backwards-compatible but it’s not.
If a client asks for IE8 support on top of all of the above, we have to charge more because of the significant amount of time it adds to the project. If they also throw IE7 in there, we take 1.5x the additional IE8 support cost, and that’s their legacy browser support cost. Usually, when we do user analysis and look at trends, they realize that a.) legacy IE is “dead enough”, b.) the cost to tweak and hack everything to display as designed/well on old IE is nowhere near worth the time, investment or code clutter because, c.) someone on IE7 clearly doesn’t care/notice the web looks/works like crap to them (or else they would have upgraded by now) and/or don’t know how to use a computer well enough to find web information and aren’t going to effectively receive the purpose of the site, if not are lost or aimlessly browsing. The only other people who are on old IE are possibly corporate workers at companies with poor IT leadership who lock users down to old IE7 to “ensure security” (WHAT?!) or have an old web app coded by careless fools that only works in IE7 (and haven’t found out how to work compatibility mode in IE9.) Keeping in mind that this corporate user is very, very rare, doing anything beyond the bases to support IE is beating a dead horse. Businesses so cheap they can’t ditch a web app they bought in 2001 (that’s probably never worked and held back workflow the entire 10 years they’ve had it) are probably not after a modern HTML5 responsive web app or anything that would require marketing with such a website. And if they are, they’ll get the information they need – just not how your designer wanted it. You just can’t blast out the timeline to support every ancient technology in the world. If you build it right to start with, it will support old IE “well-enough” to provide information – which is what the web is for. If we’re going to support IE7, what’s stopping a client from asking for AOL support. Most are simply unaware of the required work until they see the longer timeline & legacy costs. Makes no sense when all that work is done and they still have a crappy experience because they haven’t upgraded. If anything, put a message in the footer saying it won’t display properly because they haven’t bothered to upgrade yet.
IE sucking behind, you know what also sucks? This BS:
-webkit-min-device-pixel-ratio: 2
min–moz-device-pixel-ratio: 2
-o-min-device-pixel-ratio: 2/1
min-device-pixel-ratio: 2
and now that Windows 8 is out and IE10 is available, we get another:
-ms-min-device-pixel-ratio: 2
And I want to slap Mozilla for making some random declarations different than the rest. Also love how Opera uses the webkit conditionals because “web developers are being lazy and not including all of them.” First off, it is ridiculous to blame web devs for omitting code when the code is there… five effing times, and you’re just choosing not to read the base declaration because it’s not “standardized” yet, and W3C’s CSS people need to get a clue and start doing rolling standards with CSS as they had to with HTML, and second of all, no one uses freaking Opera. I omit Opera on purpose, bitches. Don’t act like I’m lazy when really your usage share on my analytics sheets are 0.2%. The lone Opera user that probably didn’t even speak the same language and accidentally wound up on that page had to see the fallback experience. Ohh no! Big deal. Don’t care.
Most of the time when I only include webkit conditionals it’s because the declaration is targeting mobile devices. With that statement, you can hit the Droids, iOS and Blackberrys with one punch. So good job Opera, you’re applying styling that’s meant for an iPhone. Fail. Yes, I know Mozilla makes a Firefox for Android that barely functions, Opera has like 15 browsers in the Android market that no one uses and has made browsers for various ancient handheld technology that’s not CSS3 capable, nor used anymore, nor displayed large enough on the hardwares two-pixel screen to show anything but your web’s logo. I’ll only hack my code to pieces if the usage numbers are there to back it, and IE on mobile hasn’t even acquired enough users for me to care to add 500 lines of “-ms-stupid-conditional-code-killer” with the other mobile declarations. Don’t talk to me about lazy web developers when CSS has taken on 5 times as much code to be authored because of this and causes nonstop issues such as Mozilla’s inability to stay with the format of the rest. No, we aren’t enjoying having to Google what every browser’s little hack is called for every little attribute. No, I’m not including all of that code for browsers that are used so little that I don’t even bother testing in them. Go ahead and read the -webkit- declaration Opera, just remember it doesn’t matter because when it comes to my users, no one will see it. I don’t want to hear the “oh Opera just said a lot of developers don’t know they’re forge…” because that’s BS too. No one forgets it. Many remove it from code snippets they paste in from tutorials. This is why we build fallbacks. Didn’t forget. Not lazy. Don’t care.
I cannot believe we are still having to do this, and I’m sure in the future we’ll be fighting about when it’s appropriate NOT to keep doing this, but one thing’s for sure – I want to punch some people in the face for not addressing developers issues on the basis of standardizing the same way we did in the 2000s… back when the web was broken and hacked to pieces with sht code. The browsers are ready because we’ve been using it already. Our clients are ready, they’ve been demanding it for years already. Users are ready, they’ve got it on 4-inch screens already. Many, many new CSS specs are ready & waiting for standardization. To me, these are already standardized because they display the same across all browsers and are used in mass across the web. If I hear “backwards compatible” as I hack out 500 lines of code into 2500 to support the technology that’s actually being used today, I’ll kill someone. Get a clue. Electronics manufacturers don’t make the technology to last longer than 5 years (two if we’re talking about phones or Macbooks) and marketing directors to information archivists alike don’t give a flying crap that some ’90s technology that’s in a landfill by now doesn’t recognize their CSS. If it doesn’t recognize it, it will ignore that declaration, life moves on and in the end, no one even knew the difference, and if they did – they didn’t give a sht, if they did give a sh*t, they wouldn’t be trying to browse the web on a god damned Wii. Information is in the markup, if that’s there, then the web has done its job. I understand their logic, but I just think they have broken the web once again by forcing major version standardization, not understanding the real-world and how the web they’re working on is actually managed and are moving several-dozen times slower than the technology itself. Their little experimental hack schema has become a permanent part of the next decade of CSS and has already started to break things.
Lazy developers… screw Opera.
@Andrew
I have been saying this to myself for ages and thinking I’m just some lazy website developer who likes to do things the simple way and thinks things like screw odd or old browsers, screw IE etc. To me the one bit of code I can use that covers “the most browser” I use and tell myself that; if one browser needs a tweak (hack) then it’s the one at fault, not me, it can suffer with the odd alignment etc. If those users realise one day by actually trying other browsers once in a while that on their chosen browser the web looks like crap then they can vote with their feet and switch or just live with it.
So glad to have read your post and enjoyed it so much!
Cheers,.
^ What he said.
Hey Chris, I just wrote up some thoughts on how you simplify your future-friendly example. I always thought all the vendor prefixed media queries were a headache. When I looked at this some more, I realized you only need 2 checks in your retina/high resolution media query. Hopefully this helps other devs as well.
Get this as a Resolution mixin for SASS: http://blog.14islands.com/post/37259603246/sass-resolution-mixin
// only include 1x size image for 'non-retina' screens @include if-max-resolution(1.49) { background-image: url('img/[email protected]'); } // only include 2x size image for 'retina' screens @include if-min-resolution(1.5) { background-image: url('img/[email protected]'); }Thanks David for the mixin;
Looks like IE9 had a problem with this definition mentioned above.
In my test IE9 loads the declaration inside the media query if this line is inside:
Can anyone else reproduce this?
I am facing the same problem. Did you manage to solve this issue?
Did you manage to solve this, we are experiencing the same problem on some PCs (not all, strange?) that is running IE9.
On my development local site ie9 behaved fine, then I pushed out to a publicly available server as a staging site, there on the first page-load ie9 thought itself retina, and on page-refresh it corrected itself, since then works correctly.
No idea why only on initial load, or how to fix; new to the topic.
This was my code:
Using the two different sets to define standard vs. hi-resolution bg-images (to prevent redundant asset downloading).
Until every browser decides to get together and come up with a single solution we will always be venting our anger in terms of device compatability. Apple you may have the gorgeous way of displaying your info on your marvelous devices but spare a thought for designers having to work with this tech. Now we are producing 2 images when one should be enough……..
OK, Andrew.
But why not tell us how you really feel?
;)
@Andrew: well you couldn’t have been more straight to the point… ;) Just serve ’em a plain text file.
These solutions are great for images you can identify in your styles but what are the best solutions for images placed within content areas such as blog posts via WordPress?
I am having issues with images that may be syndicated through RSS on partner sites.
@Jess You could look into Hammy: http://wordpress.org/extend/plugins/hammy/
So all this retina and I don’t have one. Can I care less… Ah whatever. So how would us developers know its working if we can’t see it? Is there a trick to this?
Any help on seeing the image change on a non retina display to know its working and aligned correctly would be nice. No problem coding for it just need to be able to see the changes are ok and fixed.
Hi Anthony. This is a little late, but in case you are still wondering about this… If you don’t have a device handy just use Chrome’s inspector and emulate a device that has a high pixel ratio. Inspect the image and see if it is pulling in the correct one. I think other browsers can do this as well.
There’s an article in the W3C’s Blog that says:
And thanks to the new implementation of the
dppx(dots per px) and some problems with the ratios lowers than 2 we can write:@Andrew – I totally agree – brilliant rant! lol
I think this is only going to get more and more complicated. This should be headache for device manufacturers or browser engines.
Because:
1. Not all developers can afford the devices and test.
2. Everything is going to get more complicated when there are huge manufacturers.
We can make rules for the manufacturers or browsers, but not developers.
I am fully agree with Bijay
I need download retina ready icons.. Is it like text format or vector? Where is retina ready icons?
Use font awesome for icon
I think that Apple, Samsung, and whoever else creates Retina (and other hi-dpi brand name) devices should take care of the proper dpi of images (NOT text).
* The manufacturers can detect and do this image resolution upscaling easily in hardware.
* It’s a pain in the neck to have to create 2 sets of images with ImageMagick from an image with regular resolution. Djeez, it’s just width x2 and height x2. It doesn’t even blur. And ImageMagick pre-creates the upscaled images without breaking a sweat on a server without hardware accelerated graphic manipulation.
* Media queries are a never ending maintenance burden.
* Older/pre-Retina web pages are also visited by devices with Retina displays. (Thanks guys.)
* When companies introduce new hardware, they can’t place the whole burden with developers : “Here’s a new type of screen. We don’t care that it’s giving you more (guess) work. Just deal with it.”
* Manufacturers create devices/gadgets for a life-span of at most 18-24 months. Especially Apple is guilty of this (but not alone), when you realize that your device is not getting iOS updates anymore. So why bother with getting things perfect ? Good enough will do.
* Optimizing web pages for speed and size because they are going to be processed by a bandwidth limited device, and then filling it with x2 images (which are in fact 4 times the regular size) is counterproductive. If not totally stupid. A big F-up of the manufacturers. And they block automatic playing of videos to safeguard client’s bandwidth, and allow megabytes of Retina images to be auto downloaded. While they could have upscaled, in hardware, our regular dpi images to the high physical dpi of the device.
That’s why I’ll most likely stop making second sets of images for hi-dpi devices. If Apple, Samsung, and others don’t give a “certain substance” about how old or new content looks on these devices, then why should I ? It’s not my product.
How difficult can it be to come up with, and give us, a new vendor property to upscale an image with regular dpi to the physical dpi of the Retina display ?
As developers we would only have to specify this vendor property on regular dpi images.
Under the hood, the manufacturers can even optimize this dpi upscaling for the specific device it’s running on.
Why can they be so clever to think up and produce Retina displays, and so retarded to not think about and implement hardware upscaling of dpi.
P.S.
Substitute Retina for whatever Samsung and others call their hi-dpi screen tech.
This is not a rant against Apple, it’s just that Retina has become the name for a product technology. (Similar to Hoover.)
I think the problem lies in that the hardware vendors actually do adjust for their resolution, but they are assuming the lowest common denominator as far as how the web site was designed. They want to make the device work with as many pages as possible. Hence, it’s not until you set your web page at 1x until your media queries start working, thereby overriding whatever aspect ration the manufacturer set. So now your flex design works, however the burden is on you now (the designer) to make things work across devices!
The solution is simple, but no one seems to see it. Let’s get back to what we did in the days of paper: actual measurements (cm, inches). It takes pixel density out of the picture altogether. Sure, images are then still sized as pixels in Photoshop, but they are marked in actual size in the CSS. The software layer of rending the author’s intentions can then be handled between the browser and the OS. This way the media queries work the way they were intended: To judge the size of screen the user will be viewing the page in.
One more thing… for those of you concerned about doing multiple images for different devices. Is that really necessary? Adobe Illustrator and Photoshop have a “Save to Web” feature where you can save your picture as a PNG. I’ve been using it and have produced some very high quality graphics (and sometimes pictures as well) at small file sizes. Graphics at look awesome at 128 colors, sometimes even better than 256 colors. For high quality pictures, perhaps you could use something like cloud zoom? Just some suggestions.
png files are the best way to go for vector graphics but not photos. Although there is a push to use svg which is more like an eps files, svg is still not supported on all browsers. PNG has been around for a long time and the newer version contain a transparency layer so in effect it’s like using eps files which ofcourse can only be used in print and not web.
The retina display issues are really confusing at this stage and no-one systems to have a clear answer, if only there was more uniformity in browsers!
Chris, I just wanted to tell you thank you for your efforts on this site. You provide some invaluable information and I really appreciate it. c
Heavily seconded; specifically, I really appreciate that you go back and keep your old posts updated with the latest developments. That is so important in a world where old blog posts can top search results and continue to supply people with outdated information.
Help if you get the time.
Ok, I am using a pretty standard media query for Retina devices.
@media
(-webkit-min-device-pixel-ratio: 2),
(min-resolution: 192dpi) {
/* Retina-specific stuff here */
}
In some Android devices/browsers (specifically S3, running Chrome), it looks as though the Retina image is loading, but it is not loading the background-size property. So the image takes up more than the space it should.
Any one run across anything like this or have a resource that could point me towards a solution.
Thanks Guys.
Do you have a background-size tag in your css? I think that’s necessary to keep some browsers from scaling the background up to compensate for the resolution. So, if your retina-specific background image is 200px x 200px, you’d declare “background-size: 100px 100px”.
would that mean you would need a range of images to be
2560px wide
1920px wide
1540px wide
960px wide
480px wide
for a background cover image
If serve a resolution 2x bkgd image in resolution 1.5x mobile device display or in 1x display what should happen? In other words image resol is bigger than display resol… Image to appear in display resol exactly or…? 2x images for retina what resolution ppi… must have usually, this to create in Fireworks or Photoshop or Gimpshop?
I have one problem about project in responsive website.in computer I will display 10 image in one line but in phone I will display only 5 image in one line
Hello Mr. Chris Coyier, Thanks for your suggestions, and i don’t understand one thing , u mentioned lot of css for retina display,which css is to use for retina display..
Thanks in Advance..
Is there a reason you use
min-resolution: dpiInstead of
max-width: pxIf retina iPad’s have 2048 x 1536 resolution I would think the code for this would be something like
@media (-webkit-min-device-pixel-ratio: 2),(max-width: 2048px;) {
.mobile: css;
}
I also have a question, if you set conditional code for ratio 1.5 will that carry on and be applied to ratios at 2.0 ? Or will it default back to 1.0 ratio?
@Alan,
The reason is that it is possible to have a, say, 30″ monitor that has 2048 horizontal pixels, as well as a 10″ tablet that has the same amount of pixels, horizontally.
However, the DPI of the 30″ monitor will be one third the DPI of the tablet:
2048/30vs2048/10.I personally don’t like the fact that W3C has chosen to use the
{min, max}-resolutionterm for this purpose, as the proper term is pixel density, not pixel resolution.Hi,
How did you come up with
min-resolution: 192dpi? If we consider that images are usually72dpi, shouldn’t it bemin-resolution: 144dpi? And if we consider that iPhone 4’s pixel density is326dpi, shouldn’t it bemin-resolution: 326dpi?@Quoterature
Yeah but that is suppose to be the whole point of the
@media (-webkit-min-device-pixel-ratio: 2),Because both an iphone and full sized ipad have the same dpi/pixel-ratio but an iphone is only 640px wide when the ipad is 1536px wide. How do you create different designs for each of these if you aren’t distinguishing between max-resolutions?
Hi,
I am having the same problem. I need to distinguishing between pixel size for different layouts.
and the ipad completely breaks while anything that is 320px is fixed.
When I inspect element the iPad query is ignored and is picking up the 320px one with (-webkit-min-device-pixel-ratio: 2).
CSS works like if statements and it is like min-device-width and max-device-width and webkit….2.0 is is registering false and iPad is like well 320px is true.
Did you find a solution? I am debugging for Android and want to keep iPad query as is cause it works if I don’t have the 320px one which is for Galaxy phones.
for who would I use this => http://atmedia.info/ to check media info of device…
@media
(-webkit-min-device-pixel-ratio: 2) and (width: 720px),
(min-resolution: 192dpi) and (width: 720px) this media query not supported in android device and google emulator.
Very helpful stuff but I have a question. Perhaps I’m missing something here.
In this:
@media only screen and (min-width: 1300px) {
/* Large screen, non-retina */
}
Prior to that you had the checking for retina which makes sense. You wrote /* Large screen, non-retina */, but I do not see the retina excluded here.
I would be expecting something like this:
@media
only screen and (-webkit-max-device-pixel-ratio: 1.9) and (min-width: 1300px),
only screen and ( max–moz-device-pixel-ratio: 1.9) and (min-width: 1300px),
only screen and ( -o-min-device-pixel-ratio: 1.9/1) and (min-width: 1300px),
only screen and ( max-device-pixel-ratio: 1.9) and (min-width: 1300px),
only screen and ( max-resolution: 191dpi) and (min-width: 1300px),
only screen and ( max-resolution: 1.9dppx) and (min-width: 1300px) {
/* Medium screen, retina, stuff to override above media query */
}
Any thoughts?
Oops,
I should have replaced this:
/* Medium screen, retina, stuff to override above media query */
With this:
/* Large screen, non-retina */
NVM. I get it with the quirky override stuff. (I’m new at CSS and the lack of ‘else’ took me a bit to figure) Would it be safe to assume that CSS wasn’t exactly designed by programmers?
@media queries, and CSS in general, behave in much the same way as a
switchblock would if none of thecases were terminated by a break statement. That’s oversimplifying it a bit, mostly because it doesn’t account for specificity, but basically, the fallthrough allows for any rules that were previously declared to be overwritten by a latercase(to continue the analogy).Hi! I tried the above snippet and for some reason the iPad with Retina takes on the css styles from 320px because of the -webkit-min-device-pixel-ratio: 2. I am trying to have independent styles that only affect the right query. I tried so many different ways and as long as I have -webkit-min-device-pixel-ratio: 2 the iPad will pick it up and the iPad Layout will break.
I tried this for starters:
@media
only screen and (-webkit-min-device-pixel-ratio: 2) and (min-width: 320px),
only screen and ( min–moz-device-pixel-ratio: 2) and (min-width: 320px),
only screen and ( -o-min-device-pixel-ratio: 2/1) and (min-width: 320px),
only screen and ( min-device-pixel-ratio: 2) and (min-width: 320px),
only screen and ( min-resolution: 192dpi) and (min-width: 320px),
only screen and ( min-resolution: 2dppx) and (min-width: 320px) {
/styles/
}
my iPad query is this:
@media screen
and (min-device-width : 768px)
and (max-device-width : 1024px)
and (orientation : landscape) {}
Which get completely override by the 320px one.
Any suggestions?
Hi Kris, Can we get a 2014 update to this post?
That would be wonderful!
+1 for an updated version…
Why doesn’t CSS simply support a “dot” unit, so I can express a media query in terms of available device pixels, rather than playing contortions with both px and dppx units? Trivial for browsers to implement, no?
Stop the Pain
Says the following above
“If you care about how much the user has to download, don’t implement the retina tax.”
I say “how”?
I have very specific background and overlaid images I want to open on screens <480px, and different sets for larger sizes.
What code do I need so that retina is ignored.
Eg iPhone 3 and 4 (and many android) open a 320px background image full width, not download a 640px image that I have for larger screens.
Thanks
Github?
Borrow it from a FE framework?
Pay someone?
Code it yourself?
Hah! Hah!
The following still works brilliantly.
But as he mentions in the repo’s readme, under “Project status”, there are other newer options in HTML now. But this repo’s solution also works with older browser engines. I still use it. : https://github.com/MattWilcox/Adaptive-Images
I initially customised adaptive-images.php for my framework.
But later on swapped out adaptive-images.php for code from this repo : https://github.com/lencioni/SLIR
You have to add reading of the cookie that is set by adaptive-images though, and then also add methods to do the resizing with the values from the cookie that you just read.
You can speed up SLIR significantly by pre-caching. Write a (PHP) script to call SLIR’s methods for popular screen sizes. For example iPhone 5 is quite popular, look up all it’s possible portrait and landscape sizes, taking into account retina also, and call SLIR’s methods to generate a resized image for each size of all the site’s images.
When someone visit’s for the very first time with an iPhone 5, SLIR will fetch a cached image instead of having to resize it as part of the first request.
Or before going live with SLIR, activate maintenance mode.
Turn off your analytics.
Deploy the new version of the site with adaptive images and SLIR.
Visit the new version of the site with as many different devices that you have. This will pre-cache.
Turn on your analytics.
Remove maintenance mode.
What about image-set?
https://www.html5rocks.com/en/mobile/high-dpi/
Thanks Mattia, It’s a nice solution.
Avoids retina displays downloading twice images and It’s supported by chrome and safari.
http://caniuse.com/#feat=css-image-set
This is awesome! I also need to use this in jQuery though…I know this is a CSS site, but can anyone point me in the right direction?
How to target s7 and S7 egde. one has 5.1 inch screen and the other has 5.5 inch. Media queries needs to change to fit in the later one.
Is this still up to date?
You might want to refer to our more recent guide on media queries: