Aral Balkan

The moment you first lay eyes on the iPhone 4's new Retina display, you are ruined. No other display will ever make you happy. Not unless it, too, is a Retina display. You start seeing pixels everywhere. My beloved MacBook Pro's screen? Pixels. The iPad I bought a few months ago and couldn't leave aside? Pixels.

Retina changes everything

The iPhone 4 really does change everything again and not just for phones. By introducing the Retina display, Apple has just changed the rules of the game. Make no mistake, this is as fundamental a shift as the move from black and white to color TV. I now want Retina displays on my next iPad and my next MacBook Pro (and will happily pay a premium for it). Whether or not Apple has the technology to meet the expectations it has now created with the Retina display on its other products is another issue (i.e., does the technology exist to manufacture a 326ppi 15" retina display for a MacBook Pro?)

With the introduction of the Retina display, Apple has guaranteed the following three things:

1. Vectors will play a central role in any graphic production pipeline.
2. You basically have to design liquid interfaces (and interface elements) for your apps.
3. You won't be able to get away with the levels of image compression you've been using so far.

Basically, if you want your applications and web sites to look beautiful on the iPhone 4's new retina screen, you're going to have to create high-resolution versions of your bitmaps and/or use vectors. Resolution independence is here today and it is here to stay.

What about images in web pages?

While version 4 of the iPhone SDK handles much of the hassle of working with two versions of every bitmap for you by automatically loading the right image if you adhere to the simple naming convention of adding @2x to the ends of your image names, no such automagic handling of images exists for images in web pages. I'd been meaning to look into this since I got my iPhone 4 last week and was happy to see that Walt Dickinson beat me to it with his article on Targeting the iPhone 4 Retina Display with CSS3 Media Queries in which he draws on Dave Hyatt's post on high DPI web sites, John Gruber's Why 960x640 post, and the Safari Web Content Guide to suggest the use of device-pixel-ratio CSS3 media query to serve high-resolution images to devices with high-DPI screens:

Then, in the Retina-specific CSS, he loads in 32x32 icons as background images and specifies their dimensions in CSS pixels as 16x16 using the background-size CSS property.

Demo

I put together a quick demo using the same technique that you can test out. It uses the lovely Smashing Royal Icon Set by Artua.com to embed 64x64 and 128x128 actual pixel size icons for display at 64x64 CSS pixel size.

Download the source (.zip; 74KB).

CSS media queries and background images are all well and good, but what about other visual assets such as images embedded on a web site via the img tag? Or videos?

A call for native browser support for high-DPI image and video substitution

I'd like to suggest that browsers adopt the same naming convention that Cocoa Touch uses to find and load high-DPI versions of image and video assets. That is, if I embed an image using the following code…

… it should load in flower.jpg when the device-pixel-ratio is 1 but it should attempt to find an image called flower@2x.jpg at the same relative path if device-pixel-ratio is 2 (and so on, for higher pixel-ratios), falling back to the original graphic if it can't find a high-resolution version.

(And the same convention could be used to load video assets.)

Update: Magne Andersson pointed out in the comments (and I agree) that sending two requests for every image asset would not be ideal. However, it would be easy to work around this by introducing a new HTML meta tag that tells the browser whether or not high-resolution images are available. The browser then only tries to load high-resolution images if the meta tag is present and if it detects that it is running on a high-DPI screen.

How to optimize for high-DPI screens today

Since browsers do not currently have this sort of automatic support for loading high-resolution versions of image and video assets, how can we detect that the site is being displayed on a high-DPI screen and load in high-resolution assets? The obvious way is to use a combination of CSS media queries and JavaScript:

1. Use the device-pixel-ratio CSS query to load in a high-DPI CSS file,
2. Set some CSS property to a unique value (to use as a flag),
3. Check that value in JavaScript and substitute high-resolution image/video assets accordingly.

Don't forget about SVG

SVG has been the unloved step-child of the web ever since I can remember. However, it has really begun interest me now that we're moving to creating resolution-independent designs. (That's why I'm so happy that I have the chance to catch Doug Schepers's talk on SVG at tonight's SkillSwap after missing it during WebDirections @media.) If you, too, have been ignoring it, now might be a good time to take another look.

Why native iPhone app developers should care

Most native iPhone applications are – to some degree – hybrid apps and use the UIWebView WebKit control to embed HTML, CSS, and JavaScript content. Some native apps – such as those wrapped by PhoneGap, are almost entirely created with web technologies. Regardless of where on this spectrum your app falls, you will probably find yourself having to support high-DPI images in web content. Not only that, but UIWebView renders SVG so you could consider using it to keep parts of your interface as vectors without having to write custom drawing code.

The iPhone 4's Retina display really does change everything. The sooner you start thinking about (and practicing) resolution-independent design, the sooner you can start to take advantage of this beautiful new screen and the other high-DPI screens that will, no doubt, be following its lead.

Comments

• This is an insightful article, thanks for the detail... and the iPhone 4 has only been out for a week! Props for getting this together in such a short time.

  by Robin Parduez on 2010-06-30 16:22:31

• Native browser support I think is a bit of an overreach. This is a problem that will resolve itself in 2-3 years in the high-end market, and wont take a lot more for mass products either. And yes, until it happens, we can do hacks (saving a bit of bandwidth here and there is a commendable exercise), but I don't reckon that's something that need to go into browser codebases. Look at the lowsrc attribute of the <img> tag, which tried to solve a similar problem years ago. Not even IE8 supports it anymore!

  by Janos P Toth on 2010-06-30 13:34:18

• [...] iPhone 4’s new Retina display June 30, 2010, 4:30 pm Filed under: Uncategorized Cool link: Aral Balkan · How to make your web content look stunning on the iPhone 4’s new Retina display Leave a Comment Leave a Comment so far Leave a comment RSS feed for comments on this post. [...]

  by Aral Balkan · How to make your web content look stunning on the iPhone 4’s new Retina display « Blog Weblog on 2010-06-30 16:30:19

• A very similar approach to images being scalable came to me recently, as fonts and generally all CSS mark up are scalable why can't we have images produced from say a pixel size of 100px x 100px and optimise that very same image to scale up to 400px x 400 px to accomodate various zoom levels. More testing involved but a far better experience for the user.

  by Paul Rogers on 2010-06-30 16:35:16

• Thanks for this – I'm sure I'll be able to use it in some future projects. Very helpful.

  by Jon on 2010-06-30 15:07:07

• Brilliant post! I totally agree with the sentiment about the macbook pro screen idea however the problem for designers will be that when designing we are not using the same technology as the end users are using to view our creations and thus as we are not seeing a true representation of what the user will see they may suffer in the long run. Cheers, @Prydie

  by Andrew Pryde on 2010-06-30 14:36:56

• Couldn't you make this more of a backend issue? Currently, to deliver device appropriate content to mobile users there generally has to be some kind of sniffer figuring what browser is making the request e.g IE 7, Opera, or Safari on an iPhone. The browser is recognized by it's user agent code - wouldn't it be simpler to just recognize what browser is making the request and send them to the appropriate version of the site? I guess this assumes that there would be new versions of the browsers created for devices with a retina display but this seems like a given to me. just a thought Chris P.S. Great article BTW

  by Chris on 2010-07-01 13:36:30

• [...] Aral Balkan: How to make your web content look stunning on the iPhone 4’s new Retina Display [...]

  by How To Use CSS3 Media Queries To Create a Mobile Version of Your Website « Talel Dridi on 2010-07-20 17:01:22

• How totally true. Thanks - we need more people doing stuff on this topic .. and for another reason besides dpi... and that is ZOOM. When you zoom you suffer from the smoothing code in the device, and the resolution of the art. Unfortunately, setting 300 dpi into a png and expecting it will zoom any better than the 72dpi png .. is not going to work. However.. there is a way that does work make your image 2x bigger ( exactly 2x ) and then set the display scale to 50% - so an image 1000 pixels wide is width=500. works the same in flash also, and you can tinker with compression around 80-90% and get rather good outcomes. this helps with fullscreen where 1024 to 2560 may be the users pixelspace also. see this http://w.ctndigital.com?page=27 and resize your browser. really helps with ipad and iphone also. but there you swap css files and set the 50% differently. I am tinkering now with my droid incredible on this. Your site rocks and i hope we make a riot of this pixel problem so that all browser coders tend to it, and in the way you identified.... is perfect.

  by Jeff Johnson on 2010-08-07 14:29:34

• I'm not entirely bright when it comes to display technology, however, my Android phone has a screen with 240dpi. This should mean that newer Android consumers can benefit from this technique also (correct?). Unfortunatly, the Android browser isn't meeting the CSS3 device-pixel-ratio media query. I've removed that query from the page and tested myself and can notice a difference, however I wonder if it is just because the browser has more information available, and can do a better job of dithering, or if this is indeed the same technology in effect.

  by Mike Weiss on 2010-06-30 18:46:52

• The only problem with this line of thinking is that Google for sure, and possibly other major search engines, are now taking page / load speed into account for search rankings. Updating graphics to come in line with the Retina display will cause a significant increase in the size of what is being loaded on pages. Granted SVG has the potential to solve this problem with vectors being able to scale, but overall this could be a problem in other ways than just the ones that your eyes can see.

  by TC on 2010-06-30 15:49:09

• Thanks for posting this well written article - this will come in handy!

  by Ray Wenderlich on 2010-06-30 15:46:26

• Indeed it does. If it actually gets implemented, I hope it gets an "unofficial" specification along with the first implementation, so that we won't have to define multiple new meta tags. By the way, I got to compliment you on your design. I haven't seen a blog with the comments on it's side before, but it looks really good (although I didn't realized that they were there for a while after clicking the submit button).

  by Magne Andersson on 2010-06-30 14:46:18

• Hey Magne, Thank you for your comment. You're right, two requests for one image would not be good. You could introduce a new meta tag, however, that tells the browser whether or not high-resolution images/videos are available. That should solve the issue you have with it. If the meta tag doesn't exist, the browser loads pages as normal. If it does exist, it loads high-resolution images when it detects a high DPI screen. Does that solve the issue you had with the automagical approach?

  by Aral on 2010-06-30 13:47:47

• Good article. It makes me want an iPhone 4, even more. Still, I don't think you've thought through your "call for native browser support for high-DPI image and video substitution". As I understand it, that would mean sending two requests for every image on every site? Wouldn't that lead to problems with bandwidth for little gain (reminding me of the IE favicon mess)? I think it is better to, in that case, define a new specification which adds a new attribute and CSS property to the element and elements with background-images respectively. I still don't think that's a good idea in the end either, though. There are two solutions that I can think of, currently: 1. Supply the high-quality images under the original name. 2. Use SVG-images. Now, the second option just won't work with all images, and the first option also introduces a problem with extra bandwidth usage, if no higher resolution of the image is needed. Still, I think that is the best thing you could do today, and is better than your proposal.

  by Magne Andersson on 2010-06-30 12:10:17

• SVG definitely is the way to go. Too sad that all the cool stuff still isn't implemented in webkit-svg-support: http://webkit.org/projects/svg/status.xml

  by dirk on 2010-06-30 13:01:10

• The irony here is that Flash - being a vector animation format - would be well suited to delivering high DPI content that scales down well.

  by SP on 2010-07-01 09:35:37

• Actually you can reduce the number of HTTP requests by putting the media-specific CSS declarations in your main stylesheet. You would use the @media rule in your CSS: /* All media types */ .someclass {...} /* Specific media type */ @media ... { .someclass {...} } It makes your main CSS a bit cluttered, but you avoid mistakes such as modifying the main styles drastically and not updating the media-type specific styles. This is what i use for print styles, and simple mobile styles.

  by Florent V. on 2010-07-01 11:41:40

• Great article, and lots of food for thought. However, META tags are never the solution to a problem. There are already content negotiation solutions where the same URL returns a different resource depending on what the client is willing to accept. Currently these use the Accept-Language, -Charset and -Encoding headers but since these are text-specific there's no reason there shouldn't be an image-specific Accept-Pixel-Ratio (or similar) header for this purpose. The biggest problem is that people have tended to ignore content-negotiation because it generally has to be set up away from the content of the site, which isn't ideal in a lot of cases. However, with device independence as a goal, it's certainly one of the cleanest ways to approach solving the problem

  by Gareth Adams on 2010-07-02 09:48:24

• Excellent article Aral! Hi-DPI is definitely a huge new consideration when developing sites and apps.

  by James on 2010-07-02 11:18:25

• Hi, really forward-thinking about liquid interfaces. I have been thinking along this line for years, what with the increasing variety of screen resolutions. And it's part of the reason why I think HTML + CSS + JavaScript + JQuery is the way of the future. I think most web developers do. Flash is antiquated and should stick to animation and video. I guess that's also the reason why we're seeing much less flash sites nowadays.

  by Benjamin Koh on 2010-06-30 15:33:07

• Cool, thanks. Also see this PSD icon template which may be useful: http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes

  by B on 2010-07-02 20:27:31

• Great article. I share your wishes in having an iPad with a retina display, and add a front facing cam to it. I believe the technology is present to make it happen, but the pricing would not be feasible.

  by Carlos on 2010-07-02 22:58:44

• With the new data plans i'm sure carriers will appreciate the data charges making web pages 4x the size will bring.

  by Johnny on 2010-07-02 23:37:12

• Little known fact: HTML img tag already has resolution swap image substitution attributes: src and lowsrc.

  by Terretta on 2010-07-03 01:27:32

• Hi everyone. I've been hearing a lot about tablets lately and you mentioned that you've bought an ipad lately. There are so many to choose from, but they are also very expensive. You sound like you know a lot about tablets, so maybe you can help me out. Why should I spend a lot of money buying a tablet from Apple or HP, when instead I could just reach into my toilet bowl and grab something hand-held that's just as shitty, but at a very small fraction of the cost? Cheers!

  by dave on 2010-07-04 12:11:23

• @Gareth I agree with you completely. Content Negotiation has already solved this problem and should be used as the solution for multiple resolution image resources. Perhaps an Accept-Display header or something along those lines. Using content negotiation, we'd also get caching for free using the Vary header. Just another case where looking at the web in a RESTful way yields cleaner solutions. (2 images of varying resolutions are actually 2 separate Representations of the same Resource and thus should be accessible via the same URI)

  by Jason on 2010-07-10 03:05:19

• The idea of a browser hammering my site with 404 errors seeking high resolution graphics when in most cases they will not be available seems like... not a good idea. Not to mention the client slowdown as they make double the requests and have to wait for 404 errors to return. Ideally I suspect that the browser should send this capability to the server in the headers (maybe as part of the user agent?) and the functionality should be implemented server-side explicitly, when higher quality assets are available.

  by Gregory on 2010-06-30 21:55:24

• Great article. I was searching for this kind of explanations. This article perfectly brought me what I was looking for. Thanks a lot.

  by Auré on 2010-07-01 12:04:52

• Interesting article, I can see the need for this for future computer/iPad high DPI displays but with the iPhone unless you are zooming in far to a webpage people are not going to notice the high resolution images. Also people browsing on 3g or worse are probably not going to appreciate having to download higher resolution images. So I would hope developers do not implement some of the ideas in the article for iPhone users but for larger & high DPI displays I can see the advantages.

  by Martin on 2010-07-02 01:00:09

• Wow, I'm really excited to experience this new wave of HD resolutions and I figured it was just a matter of time that we'd have to develop resolution in dependent layouts.

  by Ryan Bollenbach on 2010-07-02 14:18:13

• I'm working on a PhoneGap app right now, that uses the Google Maps API v3 -- and Its been "zooming" the layout on my iPhone 4. I noticed that the JS map underperforms on the iPhone 4 compared to my coworker's iPhone 3GS. If I were to go ahead and make a resolution independent design, GMaps doesn't have support for the higher res display. The map will have the 4 labels that switch between map, satellite, hybrid, etc. I'm going to see if I can find those labels and do my own little CSS hack on it, we'll see.

  by Alex Newman on 2010-07-02 14:24:31

• Great stuff, Aral! Thanks a bunch!

  by Dennis Phang on 2010-07-02 15:48:53

• [...] 14) How to make your web content look stunning on the iPhone 4’s new Retina display [...]

  by Design notebook #44 – Superyacht, Minihome, Times Square Makeover, Space Suit Designs, Submarines that fly and much more… – The Blogs at HowStuffWorks on 2010-07-03 04:02:13

• "The iPhone 4 really does change everything" Or, with levity: it really does change ONE thing.

  by Rob on 2010-07-03 16:56:43

• There's actually a great way of achieving automatic loading of double-resolution images with existing browsers and backend technologies. Upon session start use JavaScript or a roundtrip to the server using the -webkit-min-device-pixel-ratio directive to issue a Cookie on the client indicating that the client has double- (or n-) pixel ratio. Using Apache or any other web server that has rewrite-capabilities create a rewrite rule for all *.jpg, *.gif, ..., requests that is conditional upon the existance of that specific cookie and the existense of a @2x version of the requested media.

  by Tuomas Artman on 2010-07-07 16:28:13

• Thanks for the great article! I'd love to know if there's any way to use inline high-DPI images the same way, rather than relying purely on CSS. I've been optimizing my online art gallery for the standard iPhone and iPhone 4 and not having to rely purely on CSS would drastically cut down my work load. Maybe there's a JavaScript file somewhere that replaces these? If you have any feedback, I'd greatly appreciate it! Thanks again. Jeffrey Bennett

  by Jeffrey Bennett on 2010-08-31 07:27:08

• For the jQuery users: http://troymcilvena.com/post/998277515/jquery-retina For MooTools users: http://mootools.net/forge/p/mooretina

  by Troy Mcilvena on 2010-10-25 21:57:20

• I know this is not the ideal process but a trick that I have been using is to update all my images to twice the resolution of the original images intended for iphone 3 and other platforms, and then specify the width and height of the images as if they were to be displayed on iphone 3. Since Safari default to 320 viewport on iPhone 4 for backward compatibility, I did not have to change anything on my website other than specifying the dimensions for the images, and since these dimensions are defined to be how the pages were originally designed for iPhone 3, all stylesheets still work perfectly. For example. If an image was originally 200 x 200. I now go create another same image but at a dimension 400 x 400. Then, in the HTML, I put in: It is just a bandage quickfix. It buys me sometime to work on the website for a longer term solution, but yet, all my users get to enjoy the high resolution on their iPhone 4 today!

  by vinpark on 2010-09-08 16:49:38

• Dear Aral, thank you very, very, very much for your article. We are currently updating our App for iPhone 4 and your advices have been very, very helpful. I am really glad that I discovered your article.

  by Chris on 2010-10-12 10:15:58

• Once again mac fans have no clue what they are talking about. It's troubling.

  by Anthony Alexander on 2010-10-22 06:09:03

• An important advice: It's better to use the Webkit-specific CSS property "-webkit-background-size" instead of the generel "background-size" because iOS 3.1 can't interpret the latter.

  by Chris on 2010-10-18 10:01:38

• It isn't the start of resolution independence, it's the end! Once displays hit 300dpi, there is no further to go. That's the resolution magazines are produced at. Once 300dpi is commonplace, it will be the standard resolution forever.

  by Max C on 2010-11-29 12:41:44

• Thanks for this article Aral. Exactly what I needed for the mobile website I'm building.

  by andy matthews on 2011-01-11 20:42:23

• Thanks for this little guide. I just stumbled over some problems with a small embedded webserver that fracked up the SVG i used for menu icons and which worked great on the Retina – when not using this embedded server. I can’t re-engineer the problem, but I just did it your ways – and it just works. :)

  by datenkind on 2011-07-14 14:01:40

• [...] How to make your web content look stunning on the iPhone 4’s new Retina display by Aral Balkan outlines the high-level impact of the Retina Display on Web design & development. [...]

  by Designing for the Retina Display (326ppi) « bento blogging on 2011-05-27 02:33:23

• Would make sense for the time being for Safari on an iPhone 4 to do the image swap in exactly the same way it would for the native apps. Until there's a slicker solution that works with all 'future' hi-res displays.

  by Lee Probert on 2011-08-25 14:16:05

• Sorry, late to the game here, but I was just testing some browser behaviour relating to this and stumbled across your post. My question: for web content, why bother with the specific media query stuff to serve higher-dpi images only to high-dpi devices? Why not just specify the high-dpi versions in all cases, and let browsers on lower-dpi devices render the graphic down? Is it purely to have absolute pixel-perfect control over how things look on low-dpi devices? And not just with CSS, also good old image elements...

  by Patrick H. Lauke on 2011-12-18 13:35:33

• thanks! This helped me out greatly

  by matt on 2011-12-09 19:08:02

• Ok, the new iPad is on the way, how about an updated article? Thanks...this is great stuff.

  by Michael Robinson on 2012-03-10 15:52:40

• Hey there! Thanks for the excellent post, helped me out with a load of situations, but there's one thing that isn't working for me. You stated that in the "A call for native browser support for high-DPI image and video substitution" an image would be replaced with the "@2x" version of it, if the image was viewed in a Retina display, but for me it's not working. I currently have a navigation menu, with icons next to the items, I have created two copies of the image, one named "home.png" and the Retina one "home@2x.png", yet when I view this on my iPod Touch 4G, it displays the low resolution version. Thanks!

  by Steven West on 2012-02-24 18:23:24

• Fascinating blog! Is your theme custom made or did you download it from somewhere? A design like yours with a few simple tweeks would really make my blog stand out. Please let me know where you got your design. Cheers

  by My most immense WORKFLOW icon Internetsite on 2012-05-12 02:49:25

• Just one problem: In Safari on the iPad, trying to get a 1500 pixel wide image to render 1:1 with the iPad's hardware pixels, it not easy. The result is that the image quality is reduced as the iPad scales the image up to 1536 pixels in portrait, or more in landscape. Even 36 pixels of change results in a noticeably softer image as a result of the scaling. The benefits of the retina display are therefore lost. For general web browsing this doesn't matter, but for people who are making photo galleries and care about the quality of their hi-res website galleries, this is really a disappointing situation. The only way photos can EVER look pin-sharp on the retina display, is when they are presented without any scaling, which is not easy to achieve for both portrait and horizontal orientation at once.

  by Bill on 2012-03-31 14:25:05

• It shall be great to have an image resolution-scale-factor as part of the HTTP request header, which would (just as with file formats…) provide for both easy and reliable server-side content negotiation, besides (as mentioned above) having any reasonable kind of client-side solution available for all cases when the content provider does not have access to sever settings.

  by Bardo Nelgen on 2012-07-10 10:32:16

• The only concern or rather question that I would have regarding Magne Andersson's comment and recommendation about not "sending two requests for every image asset"....and instead..."introducing a new HTML meta tag that tells the browser whether or not high-resolution images are available"...would be interesting, but what if your site has both hirez and lowrez images?...or what about the decision or need to use different files types (a GIF, a JPEG or a PNG/PNG-24 for transparency, etc.)? All of these choices are used to date to improve page load-time without loosing quality? So, for clarity, if I have a simple logo in 2 colors that can be saved as a GIF, I would now need to save the files as an SVG? What if I have a design and layout that needs a "clickable transparent bckg." and my only solution is using transparent PNG's within my HTML and CSS? Code vs Retina? Your thoughts?

  by Phillip on 2012-09-24 23:06:19

• sounds complicated, but i'm going to try the code out

  by venetian plaster on 2012-08-26 20:44:51

• Good answers in return of this issue with genuine arguments and telling all regarding that.

  by Instant Social Presence Review on 2012-11-03 19:06:47

• Hi Aral, I have a small query regarding to "Media Query" I have used always below line for iphone device @media only screen and (max-width: 320px) and meta tag and img{ max-width: 100%} so It's really required to use for iphone 4's below "Media Query" @media only screen and (device-aspect-ratio: 2):

  by Suyog on 2012-10-08 13:11:34

• Nice article, but the title is "How to make your web content look stunning on the iPhone 4′s new Retina display" and like so many online TUTORIALS or ARTICLES today and going back these past few years, "there's no meat on the bone"? Why not talk about the "HOW" as your title says vs. just writing some prelude or acknowledgement to the actual lesson. This is not a statement on your quality and excellence of work, but rather an overall commentary on how so many sites like Envato's series like PSDTUTS+ (etc), SmashingMagazine, Noupe and so many more that talk more than show. As a 20+ year veteran, I seen so many subscription-based and paid-for source files that are missing "steps" in both the file and article like it's a secret. I believe that anybody can keep their tricks and methods they use to get to the quality of their work whether that me a small icon to a visually stunning photomanipulation, but if you're going to sell it or license its use under the "commons law" than teach people 100% of what they are learning and paying for and not 85%. The net is filled with "design recipes" were the key ingredients are left out! Just read the many comments that say "mine doesn't look like yours", "how did you get that color effect", and so on. I guess it's human nature to hold on to what people believe makes them and their work special. However I'm from the school of thought that if you're that good, you will create 100s of more unique and beautiful pieces of work. Is the work and talent in the "program" or the "person"...food for thought! Keep up the good work! Respectfully, PAS

  by Phillip on 2012-11-04 17:15:27