Designing for A Retina Web(coding.smashingmagazine.com)
coding.smashingmagazine.com
Designing for A Retina Web
http://coding.smashingmagazine.com/2012/08/20/towards-retina-web/
13 comments
That's not just short-sighted, it's wrong now: the number of high density mobile platforms means designers should be very worried how their site looks.
And, for the most part, sites look terrible.
It’s not that simple, though. While mobile (a.k.a. small) devices have been leading the way in higher pixel densities, they also tend to have Internet access at speeds rivalling a carrier pigeon, and the amount of data included in their plans before insane pricing kicks in is frequently still measured in megabytes. All those double-resolution assets might look great, if (and only if) you have a screen that can render them, but they are also slowing things down and eating up people’s data allowance. Not everyone is going to thank you for that.
And, for the most part, sites look terrible.
It’s not that simple, though. While mobile (a.k.a. small) devices have been leading the way in higher pixel densities, they also tend to have Internet access at speeds rivalling a carrier pigeon, and the amount of data included in their plans before insane pricing kicks in is frequently still measured in megabytes. All those double-resolution assets might look great, if (and only if) you have a screen that can render them, but they are also slowing things down and eating up people’s data allowance. Not everyone is going to thank you for that.
Mobile bandwidth is somewhat of a red herring. While ubiquitous 4G isn't reality, most smartphones and networks are already capable of fairly high bandwidth.
Latency is the bottleneck you should tackle first when addressing mobile performance, not asset size - the world has already spent a lot of time optimizing asset size for web delivery. But phones are bad at handling lots of requests. Serving a single high-resolution graphic will have significantly less impact on page rendering speed (and even more important, perceived rendering speed) than a handful of smaller assets which add up to the same size.
For a real world example, a mobile phone can download and render a single large photo faster than the gaggle of javascript, css, and social network share icons typically presented next to it.
Many have examined and written about this. Here's a blog article that Google ranks on the subject: http://www.webperformancetoday.com/2012/04/02/mobile-versus-...
Latency is the bottleneck you should tackle first when addressing mobile performance, not asset size - the world has already spent a lot of time optimizing asset size for web delivery. But phones are bad at handling lots of requests. Serving a single high-resolution graphic will have significantly less impact on page rendering speed (and even more important, perceived rendering speed) than a handful of smaller assets which add up to the same size.
For a real world example, a mobile phone can download and render a single large photo faster than the gaggle of javascript, css, and social network share icons typically presented next to it.
Many have examined and written about this. Here's a blog article that Google ranks on the subject: http://www.webperformancetoday.com/2012/04/02/mobile-versus-...
It's neither bandwidth nor latency that I would be most concerned about (though I agree they are a problem) but the other point he raises:
> ... the amount of data included in their plans before insane pricing kicks in is frequently still measured in megabytes.
Mobile data plans are a joke in my country[1].
1. http://blog.binarybalance.com.au/2012/05/12/internet-anemia-...
> ... the amount of data included in their plans before insane pricing kicks in is frequently still measured in megabytes.
Mobile data plans are a joke in my country[1].
1. http://blog.binarybalance.com.au/2012/05/12/internet-anemia-...
Agreed it's an issue - considered including it but didn't.
It's fair to question how much developers should concern themselves with external costs for using their service.
Do we have a responsibility to design for data caps to prevent unnecessary charges? Do we have a responsibility to do the opposite, as an industry exerting pressure on carriers to increase cap levels? Somewhere in between?
Honestly, I don't know. I'm inclined to design for a user's reality rather than a principle, but that "in the real world" thinking allowed the web to be dominated by "best viewed in IE6" sites.
It's fair to question how much developers should concern themselves with external costs for using their service.
Do we have a responsibility to design for data caps to prevent unnecessary charges? Do we have a responsibility to do the opposite, as an industry exerting pressure on carriers to increase cap levels? Somewhere in between?
Honestly, I don't know. I'm inclined to design for a user's reality rather than a principle, but that "in the real world" thinking allowed the web to be dominated by "best viewed in IE6" sites.
> It's fair to question how much developers should concern themselves with external costs for using their service.
I wouldn't go so far as to say we have a solemn duty to always take such issues into account. But as a designer/developer, it is certainly something I myself would spare a thought for because - putting on my consumer hat - I am directly affected by the problem of shitty data plans at present and I'd like to think it's something that designers/developers would be aware of, regardless of whether they then make an informed choice one way or the other.
> Do we have a responsibility to do the opposite, as an industry exerting pressure on carriers to increase cap levels?
I'd like to think this would work. But I really just can't see it.
I too would be leaning towards designing for ther reality. But it seems we're in the time of 'case by case basis' on this issue. I don't think there's a single correct answer.
I wouldn't go so far as to say we have a solemn duty to always take such issues into account. But as a designer/developer, it is certainly something I myself would spare a thought for because - putting on my consumer hat - I am directly affected by the problem of shitty data plans at present and I'd like to think it's something that designers/developers would be aware of, regardless of whether they then make an informed choice one way or the other.
> Do we have a responsibility to do the opposite, as an industry exerting pressure on carriers to increase cap levels?
I'd like to think this would work. But I really just can't see it.
I too would be leaning towards designing for ther reality. But it seems we're in the time of 'case by case basis' on this issue. I don't think there's a single correct answer.
I've only been using 2x images for UI elements and logos. Photos still look fine at standard res (especially if 'Saved for Web' with a .25 blur). A recent project included a 25K 8-bit 2x sprite sheet, and a 13K 1x sprite sheet for LTE IE8. So not much of a difference if limited to elements that really need to be crisp.
Another good approach to small elements like these is using icon fonts. For example, GitHub recently changed all of their nav icons from sprites to a custom icon font called Octicons:
Say Hello to Octicons: https://github.com/blog/1106-say-hello-to-octicons
The Making of Octicons: https://github.com/blog/1135-the-making-of-octicons
Edit: I realize icon fonts are mentioned in the Smashing Mag article, but GitHub's articles are considerably more thorough.
Say Hello to Octicons: https://github.com/blog/1106-say-hello-to-octicons
The Making of Octicons: https://github.com/blog/1135-the-making-of-octicons
Edit: I realize icon fonts are mentioned in the Smashing Mag article, but GitHub's articles are considerably more thorough.
Icon fonts just seem to like such a hack to me in a world where SVG exists. Is the entire idea behind using them just that IE 7/8 doesn't have SVG support? How did lack of SVG support even happen? SVG seems like something any modern browser should have had for years.
Android also lacked SVG support until 3.2. The justification I read was that they deliberately disabled it from their webkit build to save 1MB in the compiled binary. Sad, especially since pre-ICS phones are by far the most prevalent.
Although a low Res image fallback is OK there.
I would love to use SVG, but support just isn't robust enough. Hard to deal with hover/active states too. Icon fonts are one request and easy to style with CSS color and text-shadow (even simulating glows). I just wish there was an easy way to generate a small font set from a the handful of vector elements I need for a given website (custom elements, that is, not using a service like Pictos).
You can hint a font. You can't hint an SVG.
Huh, that is unfortunate. Is hinting still important on devices with such high DPI though?
It’s not usually the high-dpi devices that you’d be adding hints for. The point is that anything that is going to replace today’s pixel-perfect bitmap graphics still has to look pixel-perfect when rendered on lower-dpi devices, which is going to remain by far the majority of visitors to most sites for a while yet.
I believe IE was trying to push the roughly equivalent VML format.
Nice, I love that they created a large and small version so that the details weren't interpolated away when down sampled. The 'making of' is great, I'm going to forward this to our designers.
I've actually taken it even further and bumped up to 4x+ to account for zooming as well. Especially for charts.
Just use SVG for logo's and icons. I use it all the time. They even render better than reduced PNG logo's.
They even render better than reduced PNG logo's.
Unfortunately, SVG hasn’t been well supported on Android until quite recently, and likewise for IE.
Also, you still have the problem that SVG doesn’t support hinting, so for small icons its value is limited.
Unfortunately, SVG hasn’t been well supported on Android until quite recently, and likewise for IE.
Also, you still have the problem that SVG doesn’t support hinting, so for small icons its value is limited.
I had noticed that images in my news feed on the Facebook app on my iPad 2 were displaying weirdly, but it hadn't occurred to me that it was likely a HiDPI problem.
("weirdly" = some images are blown up 2x bigger than you'd expect them to be with the full vertical dimension showing, but the right half of the image being cut off by the instant messenger window)
Now it makes sense, assuming that in the iPad app the News Feed is just HTML and that they probably didn't test the new HiDPI News Feed on older, non-retina iPads. I make that assumption with a healthy dose of doubt because I have no way of knowing how the Facebook app is designed or tested.
The takeaway for me is that there is now an even larger pool of devices/browsers/resolutions for which we need to test our designs. Choosing to go the HiDPI route, a noble decision in my opinion, comes with an even greater testing burden.
("weirdly" = some images are blown up 2x bigger than you'd expect them to be with the full vertical dimension showing, but the right half of the image being cut off by the instant messenger window)
Now it makes sense, assuming that in the iPad app the News Feed is just HTML and that they probably didn't test the new HiDPI News Feed on older, non-retina iPads. I make that assumption with a healthy dose of doubt because I have no way of knowing how the Facebook app is designed or tested.
The takeaway for me is that there is now an even larger pool of devices/browsers/resolutions for which we need to test our designs. Choosing to go the HiDPI route, a noble decision in my opinion, comes with an even greater testing burden.
I find vector images to be a godsend when creating responsive web sites. They are easy to implement and 'future proof' your website so when the next iDevice comes out with twice the resolution as the current gen retina devices your icons will look just as crisp. Of course Bitmap images remain a pain in the bum.
Vector images are fine for larger or very simple elements, but we're not at a point where we can rely on them for icons.
http://www.pushing-pixels.org/2011/11/04/about-those-vector-...
http://www.pushing-pixels.org/2011/11/04/about-those-vector-...
Especially since SVG is not hintable, so this won't be fixable until either SVG is fixed or SVG is replaced.
Good point. What you can do though, is to use media queries to load up different SVGs based on the screen resolution of the device. With a progressive enhancement approach you would load up the icons minimized for small displays by default, then work your way up.
Out of curiosity, how do you handle bitmap images? My course of action up until this point has been to open up the original in Photoshop and double the size (mileage varies a bit but seems to work well). Do you have any recommendations for another approach?
I would suggest increasing the compression levels as well. With 4x the DPI bandwidth is an issue, but you don't notice compression artifacts as much.
This is a good, comprehensive overview of the options for high-density web pages. However, I'm curious about their CSS media queries.
device-pixel-ratio,
-o-device-pixel-ratio,
-moz-device-pixel-ratio,
-Webkit-device-pixel-ratio { … }
-o-device-pixel-ratio,
-moz-device-pixel-ratio,
-webkit-device-pixel-ratio,
device-pixel-ratio { … }Yes, unprefixed properties should go last. This is because CSS rules lower in a stylesheet have priority. In theory, it's possible for a browser's experimental (prefixed) implementation of a property to behave differently to its stable (unprefixed) implementation, so you'd want the stable property to supersede the experimental one, hence putting it last.
As for capitalisation, it doesn't matter in a CSS stylesheet but it does matter if you work with styles in JavaScript, so it's better to keep them lowercase.
As for capitalisation, it doesn't matter in a CSS stylesheet but it does matter if you work with styles in JavaScript, so it's better to keep them lowercase.
I personally put normal version first, but I'm not sure it matters.
I was hoping that with the advent of the Retina display, high density displays would lead to a transition back from pixels to ratios but apparently that call was to early; instead we get CSS pixels.
Amen.
The fact that we have to worry about an implementation detail like pixels at this point means something's broken. Give us some points or viewing angle or something.
Also, I was hoping that they'd discourage people from using Photoshop to create assets; raster layers have never been a really good match for either illustrations or web layout design, and the mismatch between that model and SVG is going to mean either a slower uptake or some rube-goldberg accretion to the tooling (my money's on the later).
The fact that we have to worry about an implementation detail like pixels at this point means something's broken. Give us some points or viewing angle or something.
Also, I was hoping that they'd discourage people from using Photoshop to create assets; raster layers have never been a really good match for either illustrations or web layout design, and the mismatch between that model and SVG is going to mean either a slower uptake or some rube-goldberg accretion to the tooling (my money's on the later).
The fact that we have to worry about an implementation detail like pixels at this point means something's broken.
Not really. Apple might market their 300+ dpi Retina displays on the basis that people can’t see the pixels any more, but in our experience working on a mobile-friendly site, that’s only true for some people and under some conditions.
Meanwhile, the majority of web browsing is still done using devices with much lower pixel densities anyway, and on these devices extensive hinting and fine tuning can be necessary to get good results.
We have a very long way to go before we can just describe an icon or font design in vector terms and have it appear correctly on every device. As supporting evidence, I observe that many web fonts look terrible on a typical desktop or laptop display, with quite a few being literally illegible on Windows XP. It’s trendy to blame that on Windows’ font rendering, and that is certainly a factor, but so is the reality that some of these fonts simply aren’t hinted and kerned very well at all.
Just serving high-dpi assets isn’t a great fix, either. Aside from increasing the size of the download unnecessarily for users with relatively low-dpi screens, the scaling process often leaves awkward artifacts that wouldn’t have been there in, say, an icon that was designed from scratch to target that sort of pixel density. That’s partly because of hinting, and it’s partly because you can completely change the design (simplifying it, for example) if the larger/higher-dpi version is too complicated to work well.
So for quite a while yet, we’re still going to have to produce and manually fine-tune assets at multiple sizes to get best results.
Not really. Apple might market their 300+ dpi Retina displays on the basis that people can’t see the pixels any more, but in our experience working on a mobile-friendly site, that’s only true for some people and under some conditions.
Meanwhile, the majority of web browsing is still done using devices with much lower pixel densities anyway, and on these devices extensive hinting and fine tuning can be necessary to get good results.
We have a very long way to go before we can just describe an icon or font design in vector terms and have it appear correctly on every device. As supporting evidence, I observe that many web fonts look terrible on a typical desktop or laptop display, with quite a few being literally illegible on Windows XP. It’s trendy to blame that on Windows’ font rendering, and that is certainly a factor, but so is the reality that some of these fonts simply aren’t hinted and kerned very well at all.
Just serving high-dpi assets isn’t a great fix, either. Aside from increasing the size of the download unnecessarily for users with relatively low-dpi screens, the scaling process often leaves awkward artifacts that wouldn’t have been there in, say, an icon that was designed from scratch to target that sort of pixel density. That’s partly because of hinting, and it’s partly because you can completely change the design (simplifying it, for example) if the larger/higher-dpi version is too complicated to work well.
So for quite a while yet, we’re still going to have to produce and manually fine-tune assets at multiple sizes to get best results.
The CSS pixel is defined as an angular measurement.
http://www.w3.org/TR/CSS21/syndata.html#length-units
http://inamidst.com/stuff/notes/csspx
http://www.w3.org/TR/CSS21/syndata.html#length-units
http://inamidst.com/stuff/notes/csspx
Photoshop can just as easily create vector layers.
The site design I'm currently working on is entirely vector shapes with the exception of real world photographs. I can design great pixel-snapped icons and UI, and resize the document to 200% and instantly have crisp retina elements as well.
Photoshop can be fantastic for web layout design. It comes down to a matter of preference.
The site design I'm currently working on is entirely vector shapes with the exception of real world photographs. I can design great pixel-snapped icons and UI, and resize the document to 200% and instantly have crisp retina elements as well.
Photoshop can be fantastic for web layout design. It comes down to a matter of preference.
Use Slicy:
http://macrabbit.com/slicy/
And you don't even have to resize.
And you don't even have to resize.
I do. I was illustrating a point by mentioning a 200% resize.
You'll always have to deal with hairlines, so we won't stop caring about device pixels just yet.
"Pay us to fix X. It'll cost a bunch, and you end up with the what you had before." Where X in [y2k, ajax, retina, ...]. I love this field!
I don't agree. If you've ever had a taste of one of apple's retina screens, you'd probably also see that it's a significant improvement. Text is so much clearer and easier to read that I feel it's less straining on the eyes.
This is called "maintenance".
Something to add into the mix: I've had a few friends have decent success with Cedexis' tools for content targeting. One of the complaints that I hear about retina-enabling websites is the performance impact on mobile users. I had a demo whipped up for me once that will serve up different site versions depending on a number of factors, including platform and connection type/quality. So someone on a 3G iPad connection can get the non-retina version, while someone on a wifi link will get the full-res version.
The long and the short is that I have a feeling that we are going to see more and more interesting tools popping up in the near future as more and more web designers purchase hidpi computers and decide to write up some library to make their life easier when they decide to retina-enable their websites because it looks horrible on their machine.
The long and the short is that I have a feeling that we are going to see more and more interesting tools popping up in the near future as more and more web designers purchase hidpi computers and decide to write up some library to make their life easier when they decide to retina-enable their websites because it looks horrible on their machine.
It would certainly be helpful if we had a simple, standardised way for browsers requesting content from a web server to specify some kind of preferred quality level, based on both hardware capabilities and some mechanism for determining expected download speeds and the user’s preference for higher quality vs. saving bandwidth.
I can't speak toward the other icon font resources the article mentioned, but IcoMoon did a great job taking SVG files and turning them into a font. The app supports custom character mapping and comes with a sample icon library.
App: http://keyamoon.com/icomoon/#toHome
Sample library: https://github.com/Keyamoon/IcoMoon--limited-
App: http://keyamoon.com/icomoon/#toHome
Sample library: https://github.com/Keyamoon/IcoMoon--limited-
There are still outstanding accessibility issues with icon fonts. Until there is standards coverage for icon fonts, widespread browser support, and accessibility tool (like screen reader) awareness of those standards, I consider it a backward step for the web.
Very true, handling accessibility issues is a challenge when using icon fonts. In certain browsers, the ARIA specifications suggest you could do something like
<button aria-label="Close">X</button>
{speak: none;}
<aria-hidden="true">
I really wish people would stop saying "Retina" when they mean HiDPI.
It's more human. I think it's a better word.
Also, likely annoying as hell for Apple lawyers. I don't think they want retina to become a generic word for high DPI displays, so I'm happy whenever I see it become one.
Don't cry. Here's a kleenex.
"Retina" takes into account viewing distance. HiDPI (whatever that may be) does not.
Retina does not take viewing distance into account. There is no definition of the term retina as far as I know. Apple just uses it for all their displays with higher pixel densities.
The definition is pretty clear: The pixel grid is not visible.
For that three variables have to be taken into account: screen size, screen resulution and viewing distance. Actually, four: visual acuity, too (though it makes sense to just set that at 20/20).
That's the definition Apple repeadtedly gave in so many words. They were actually pretty explicit about that. Sure, it's their trademark. They are in no way obligated to respect that definition. They can turn around tomorrow and call every one of their screen a retina screen - but when people use the term retina they usually mean Apple's original definition.
It's a squishy term, sure, but I like it. It makes a ton of sense since it puts human perception on the center stage and that's what matters. Human perception is squishy, so it makes sense that the retina term would also be squishy.
For that three variables have to be taken into account: screen size, screen resulution and viewing distance. Actually, four: visual acuity, too (though it makes sense to just set that at 20/20).
That's the definition Apple repeadtedly gave in so many words. They were actually pretty explicit about that. Sure, it's their trademark. They are in no way obligated to respect that definition. They can turn around tomorrow and call every one of their screen a retina screen - but when people use the term retina they usually mean Apple's original definition.
It's a squishy term, sure, but I like it. It makes a ton of sense since it puts human perception on the center stage and that's what matters. Human perception is squishy, so it makes sense that the retina term would also be squishy.
"The pixel grid is not visible."
human perception is different for individual humans. Is a 10 inch 1024x768 display already retina, because many humans cannot see the pixel grid? Or is the 3.5 inch iphone 4 not retina, because a very healthy human eye can still see the pixels?
The distance is also very squishy attribute. From my experience, people look at a 10 inch tablet from about the same distance than they look at a smartphone. Still, Apple gave the ipad a lower minimum requirement for the Retina label than the iphone 4.
And does this mean I can "retina" and "unretina" a screen by moving closer/away from the screen?
The distance is also very squishy attribute. From my experience, people look at a 10 inch tablet from about the same distance than they look at a smartphone. Still, Apple gave the ipad a lower minimum requirement for the Retina label than the iphone 4.
And does this mean I can "retina" and "unretina" a screen by moving closer/away from the screen?
Ah! The STEM person and their inability to deal with squishiness! Lovely, just lovely!
You have to ask yourself one thing: What actually matters when it comes to resolution? Human perception does, of course! Everything else is pointless. Human perception is inherently squishy, that's just how it is. There really is no way around that.
If you start talking resolutions without a more complete understanding of human perception giving you context your talk is just meaningless.
The retina term here provides an easy summary, nothing more. There are always edge cases, sure, but the retina term is both explicit and unspecific enough to work very well. That's why I like it so much.
Yes, distances are different - but not so different. Yes, visual acuity is different and that sucks - but the simple solution here is to just pick 20/20. Maybe a bit better.
There are no simple yes/no answers here - but I don't think there have to be.
You have to ask yourself one thing: What actually matters when it comes to resolution? Human perception does, of course! Everything else is pointless. Human perception is inherently squishy, that's just how it is. There really is no way around that.
If you start talking resolutions without a more complete understanding of human perception giving you context your talk is just meaningless.
The retina term here provides an easy summary, nothing more. There are always edge cases, sure, but the retina term is both explicit and unspecific enough to work very well. That's why I like it so much.
Yes, distances are different - but not so different. Yes, visual acuity is different and that sucks - but the simple solution here is to just pick 20/20. Maybe a bit better.
There are no simple yes/no answers here - but I don't think there have to be.
You should probably start realizing that there are more devices than ever before.
They are all different and iOS/retina is taking smaller and smaller shares of it. Designing for that is designing for last generation platform-specific web and has little future.
They are all different and iOS/retina is taking smaller and smaller shares of it. Designing for that is designing for last generation platform-specific web and has little future.
You should probably start realizing that displays have higher pixel densities than ever before.
More and more devices will be providing high resolution displays. Designing for low-resolution displays is designing for last generation devices and has little future.
Of course, designers should aim for a solution that is as device-agnostic as possible. The linked article provides designers with a number of alternative ways to support high resolution displays. Perhaps their use of Apple marketing speak ("Retina") is self-limiting, but to dismiss the article out-of-hand for using that term is no better.
More and more devices will be providing high resolution displays. Designing for low-resolution displays is designing for last generation devices and has little future.
Of course, designers should aim for a solution that is as device-agnostic as possible. The linked article provides designers with a number of alternative ways to support high resolution displays. Perhaps their use of Apple marketing speak ("Retina") is self-limiting, but to dismiss the article out-of-hand for using that term is no better.
If you are using Firefox on a Retina MacBook Pro, you can get crisp HiDPI text if you download Firefox Aurora 16* and change about:config pref layers.acceleration.disabled to true. (This workaround is temporarily broken in Nightly 17 builds.)
Disabling Firefox's accelerated layer renderer is clearly a temporary workaround, but the improvement in text quality is awesome. To track Mozilla's progress on full support for HiDPI text, you can follow https://bugzil.la/674373
* https://www.mozilla.org/en-US/firefox/aurora/
Disabling Firefox's accelerated layer renderer is clearly a temporary workaround, but the improvement in text quality is awesome. To track Mozilla's progress on full support for HiDPI text, you can follow https://bugzil.la/674373
* https://www.mozilla.org/en-US/firefox/aurora/
IMO, what none of these techniques address is being able to on-the-fly detect if Retina and show higher-res images in a slideshow format.
There is plenty of talk out there about how to display bg images but not much (none?) that I have found to address the use case I talked about above.
There is plenty of talk out there about how to display bg images but not much (none?) that I have found to address the use case I talked about above.
If you put a retina display next to a normal display, will a site not optimized for retina look the same on both? (Just trying to understand retina.)
It will be close, but in comparison to the surrounding retina (eg. @2x) elements, the lower resolution will look blurry, as it is being mathematically upscaled.
I've never understood this. Since on the hardware level it's exactly 2x, so one pixel becomes 4 pixels.
Why on earth would it look blurry? There is no interpolated upscaling needed.
Why on earth would it look blurry? There is no interpolated upscaling needed.
He's saying compared to retina elements visible in the browser chrome or (on a laptop screen) in other applications open at the same time. If everything on both the retina and traditional screens was not retina optimized than I can't imagine there would be any noticeable difference.
Yes, this is a very real problem.
I’m working on a project that involves CGI animations, and we’ve had considerable debate about what resolution(s) to offer for the video files. On a desktop or laptop, a size similar to YouTube works fine. On an iPad with a Retina display, the videos can sometimes appear to be of a lower quality than they really are, because we’ve got sharper icons and text nearby.
Having said that, it’s not so much the video itself that can look awkward (since people are used to somewhat lossy video compression on the web anyway, and in motion you’re not really seeing the individual pixels) but rather the static poster image that displays until you start to play that video.
I’m working on a project that involves CGI animations, and we’ve had considerable debate about what resolution(s) to offer for the video files. On a desktop or laptop, a size similar to YouTube works fine. On an iPad with a Retina display, the videos can sometimes appear to be of a lower quality than they really are, because we’ve got sharper icons and text nearby.
Having said that, it’s not so much the video itself that can look awkward (since people are used to somewhat lossy video compression on the web anyway, and in motion you’re not really seeing the individual pixels) but rather the static poster image that displays until you start to play that video.
In the world of mobile displays and retina displays, people need to start using percentages more and fixed widths less.
For example, photos in the News Feed on Facebook are HiDPI, as are some images on Google. My guess is these were already being used for places to be served for iOS and Android. However, it's hit and miss: the Google logo is never HiDPI.
Last time this came up was when Marco wrote a post saying "design for Retina" and a bunch of comments complained asking why people should design for just the Retina Macbook Pro. That's not just short-sighted, it's wrong now: the number of high density mobile platforms means designers should be very worried how their site looks.
And, for the most part, sites look terrible.