Following the launch of the new iPad there's been a lot of discussion about how, and where or even whether, websites should update to support the needs of HiDPI screens like Apple's Retina display. If users are going to be looking at websites on a Retina display iPad, and one day Retina display Macs, HiDPI Android and Windows displays, and other high density screens, having them look as good as possible is a definite concern.

Bjango's Marc Edwards previously wrote about why it might take a while for developers to upgrade their apps for Retina display graphics, and has written several posts and how to include Retina graphics in design workflows.

The web, unfortunately, is nowhere near as controlled environment as the App Store.

Apple, of course, updated their iPad page for Retina display right away. According to Jason Grigsby of Cloud Four Blog, they're doing it with image_replacer.js.

What they’ve chose to do is load the regular images for the site and then if the device requesting the page is a new iPad with the retina display, they use javascript to replace the image with a high-res version of it.

The downside of this approach is that it's expensive, especially if you're serving all images this way, and the images are big. Bandwidth costs money and making every image 4 times larger (or more) means paying higher server bills. Serving a regular image and then switching to Retina is even more expensive, because you're serving both images to Retina devices. (Granted there aren't many yet, but their share will only grow.)

Phil Webb of Mobify.com offers several good pieces of advice, including prioritizing which images really need to be Retina (like product heroes), that text should be served as text and not images (we're in the age of TypeKit, after all!), creating double-sized images that are constrained by CSS width and height attributes, and the use of mobify.js.

Mobify can detect extra-high resolution displays, like the iPad 3 Retina and iPhone 4 and iPhone 4s with Retina, and serve them higher quality images.

And unlike many other techniques, like the approach Apple has taken to delivering Retina-quality images by just double-serving images, it lets you just serve the right image to the right device. So page performance is always as fast and snappy as possible.

On Quora, Read it Later developer Steve Streza promotes the use of CSS background images, the background-size attribute, sprite sheets, and media queries.

The big advantage here is that you can target specific screen scale factors with CSS, using a trick known as CSS media queries. This lets you specify entire CSS files, or parts of CSS files, to load for devices at 1x scale, at 2x scale, and other scales (as well as ranges of scales). This means that 1x scale devices are only loading 1x assets, and 2x scale devices are only loading 2x scale assets.

When it comes to photography on the web, Duncan Davidson, working with Streza, figured out that WebKit (the rendering engine behind Apple's Safari, Google's Chrome, webOS, BlackBerry's Torch, and other browsers) put limitations on image sizes that could conflict with serving Retina-calibur graphics. The workaround is to use progressive JPGs. But currently comes at a price.

Now, before you go reprocessing all your photos—and keep in mind that you can’t export progressive JPEG out of Lightroom or Aperture, so this isn’t an easy undertaking—please understand that this is just sorting out how to push a high DPI image to an iPad Retina display. Doing this well for more than a one-off example is going to take a lot more work, not the least of which is sorting out how to decide when to push a progressive JPEG at what size for the right client and bandwidth combinations.

So while it's early days and there are no clear standards for implementing cross-platform, cross-browser HiDPI graphics, there's a lot of experimentation being done. We consciously made the choice to use as much CSS as possible with our last iMore redesign, and I think that paid off. We've also replaced our previous, PNG background logo image with a 2x icon graphic and TypeKit text. We need to tweak it some more, but it already looks better on the new iPad. Likewise, we've used higher density Team iMore pictures in the sidebar for a while now, and are going to be rolling out more of them into the rest of the fairly static page elements.

If you're working on adding Retina/HiDPI support to your website, jump into our Iterate mobile design forum and let us know how you're doing it and how it's working.

HTML5 and CSS expert Vasily Zubach has put together a quite amazing render of an iPhone 4 created solely using CSS3. Because it was created in this manner, it does not include any images at all, it is all done with code.

This rendering of iPhone 4 and its icons was made in pure CSS3. No images, no base64, no SVG, no canvas, just 3395 lines of CSS code and 335 lines of Javascript code (with jQuery, of course).Viewed best with the latest versions of Safari and Chrome in Mac OS X.

You can see what we mean by amazing, when you visit the full render here. It is not just a render but it also offers a certain amount of functionality too. You can slide to unlock, click the home button and even turn it on and off using the power button. Very clever work!

Source: TNW

Speaking of Daring Fireball links and HTML5, Guillermo Esteves has re-created the opening crawl from the original Star Wars using only web-based technologies. It currently runs exclusively on the bleeding-edge WebKit nightly builds, Safari for OS X Snow Leopard... and on the built-in iPhone Safari (though it doesn't look as polished).

That's right. No Chrome anything, including Android 2.1. No Palm webOS browser. That it works on the iPhone's and iPod touch's MobileSafari... is kind of crazy considering it hasn't been updated since iPhone 3.1.2 back on Oct. 8. Just goes to show how seriously Apple is pushing the web on the iPhone.

So, yeah, words moving away into perspective in your browser, but this is without QuickTime or Flash or anything to strain your bandwidth or burn your battery. Very nice.

YouTube video of the WebKit/Safari version after the break!

Ars Technica has a great article up on the future of web design, involving 2D and 3D graphics and transformations, and what's most interesting is that it's the iPhone's Mobile Safari browser that right now seems to be leading the way in surfacing this next-gen (Flash killing?) goodness for general users:

The WebKit team added CSS Transforms to nightly builds of WebKit back in October 2007, transforms that included scaling, rotation, skewing, and translation in 2D space. As the specification matured, 3D and animation capabilities were added. Eventually, the 3D transforms were broken out into a specification of their own. Though WebKit has had these 3D transform capabilities for some time, only Mobile Safari on the iPhone and iPod touch has them enabled.

Check out some of the other demos, and get the full scoop, over on Ars.

WebKit is Apple's open source evolution of the old Linux Konquerer KHTML browser, and it forms the foundation of Safari on both the desktop and the iPhone (and Google Android, Palm Pre, Nokia tablets, etc.). Their Surfin' Safari blog has just announced CSS animation support, but the better news (via MacRumors), is that iPhone (and iPod touch) Safari already supports both CSS animation and 3D.

Want to check it out? Just hit up this awesome animated falling leaf demo on your iPhone!

Overly provocative headline not withstanding, and while this doesn't address the ubiquity of Flash video, it should go a long way towards enabling more scalable and open interactivity on the web. (Flash sites don't always scale well to small screens, after all).

Okay, I'm a web geek, I admit it, but is anyone else excited? Or do we just fear that it will all-too-quickly be perverted into iPhone optimized punch-the-monkey banner ads?

Hot on the heels of the just released Safari 3.1, some of whose features are reportedly trickling down to baby brother MobileSafari on the iPhone 2.0 firmware, Apple has reportedly begun seeding early builds of Safari 4 (5526.11.2) to developers.

The big news? WebKit's screaming fast SquirelFish Javascript engine is a go, and 53% faster, which will be huge for Web 2.0 apps like Google's... and the newly announced MobileMe service from Apple, of course!

Other new features include the ability to spin off "Site Specific Browsers" (or SSBs), which are basically thin browser clients for your favorite Web 2.0 apps -- imagine a dedicate window on your desktop just for MobileMe. Continued CSS attribute additions like gradients, masks, and reflections are also on spec (Gee, gradients and reflections? From Apple? What a surprise...)

Combined with the CSS and HTML 5.0 features already added in 3.1, such as animation, video, and audio tags, Apple seems to be retaining its focus on open, web standard interactivity, in conjunction with old nemesis Flash and similar -- sometimes buggy -- technologies like Silverlight on the desktop (for now), and in lieu of them on the iPhone. Add in QuickTime X, and Apple is definitely trying to leverage some space away from the current, pseudo-proprietary web video giants.

While OS 10.6 Snow Leopard isn't expected until mid-2009, Safari 4 seems on the fast track for a much sooner release.

Can another MobileSafari bump for the iPhone be far behind?

Read Via