When designing a website, it’s always a good idea to test on as many different platforms, devices, and browsers as possible. These days, pimping your websites for the iPhone and iPad is an important step in the design process. Especially on the iPad, sites tend to look about 20% cooler than on desktop browsers, so you definitely want to take the time to fine-tune the details. And when dealing with iDevices, it’s often necessary to deliver some custom CSS to make everything just right.
Want to apply CSS styles to the iPad and iPhone? Here is the plug-n-play, copy-&-paste code that actually works.
As you may have heard, I’ve been super-busy behind the scenes building an Angry-Birds fan site, of all things. The site is looking great so far, but needed some tweaking to appear slick on the iPad and iPhone. After testing a number of different solutions, here is what I found that actually works..
I mean, basically anything except for Internet Explorer, which is a debate in and of itself. Here I’m referring to old versions of good browsers, like Firefox 2, Safari 2, Opera 8, and so on. It seems that older versions of these browsers are not as common as older versions of IE, so should we bother supporting them when designing our websites?
Most agree that we shouldn’t support old versions of crappy browsers like IE, but what about older versions of good browsers like Firefox, Opera, and Safari?
Backwards Compatibility
One of the cool things about adhering to Web Standards during web development is that, theoretically at least, your designs should look similar on all standards-compliant browsers. This is one of the reasons why we exclude IE from the conversation — it doesn’t speak the language, and requires a whole realm of special support in and of itself. But even for modern browsers like Firefox and Safari, a standards-based design does not always translate to presentational fidelity in older versions. So how far back should we go? Obviously there’s no reason to go out of our way to support, say, Firefox 1, but what about more recent versions such as 2 or even 3.0?
Rendering Differences
For many modern browsers, the older the version, the more inconsistencies you’ll find. Older versions of Opera are notorious for borking an otherwise perfect design, and the further back you go, the more borked your design is going to get. And for anyone who does support older Opera, you know how frustrating it can be to target and filter specific versions with CSS. The same is generally true for other modern browsers: supporting older versions can get messy, costing endless amounts of time and energy. There’s no reason to have your designs look identical across browsers, but they should at least be usable. Right?
For my Serious redesign, I push the envelope in terms of CSS’ advanced selector functionality. Stuff like:
p:first-child
p:first-child:first-letter
p:first-child:after
p:first-child:first-line
Plus lots of other stylistic tricks that require CSS3 support in order to display as intended. Fortunately, most of the browsers to which I am catering with this new design have no problems with most of the advanced stuff. Of course, Internet Explorer chokes on just about everything, but fortunately IE’s proprietary conditionalcomments make it easy to fix things up with some “special” styles:
More people are surfing the Web via mobile device than ever before. It’s just so convenient to have that mobile access to anything you need. Sadly, most websites have not yet considered their mobile visitors, who probably move on to the next site before trying to make sense of a jumbled mess. Those of you who surf the Mobile Web know exactly what I’m talking about here: sites that “get it” are a joy to visit, but those that don’t are a total pain. What’s to get? Well, for one, if you do nothing else for your mobile visitors, take five minutes and implement a basic stylesheet to make your site readable via mobile device. This tutorial will show you how to retain visitors and reduce bounce rate with a super-easy 5-minute mobile makeover.
Thanks to a complete (and I mean complete) collection of screenshots graciously sent in by Brent Terrazas, I have been enlightened as to my need for Linux. Looking over the screenshots, I see a great deal of variation — more so than any of the Mac or PC browsers at my disposal — in terms of how designs are rendered on various Linux-driven browsers. The obsessive-compulsive designer in me suddenly sees an incredible need for my own Linux setup — not only for design-testing and cross-browser compatibility purposes, but also because I have always wanted to learn the ways of the Jedi..
One of my goals for the new Perishable Pressredesign was to achieve cross-browser, pixel-perfect precision [ 1 ]. Of course, due to many variables (platform, operating system, browser, extensions, fonts, etc.), it is virtually impossible to achieve complete 100% perfection, but I am certainly interested in examining the design on as many different configurations as possible. Thus, last week after launching the new design, I made an open call for screenshots. Graciously, many of you responded with some great screenshots. Thanks to you, I was able to see Perishable Press “in the wild” on many operating systems and browsers to which I simply don’t have access. Sure, I could have just went to browsershots.com or some similar service, but as Rick Beckman correctly pointed out, it is much more fun to get everyone involved in the process. So without further ado, here is the Perishable Press Quintessential Screenshot Gallery:
Quick announcement that I will be posting an article featuring a diverse screenshot gallery of the new design. To accomplish this, I need screenshots from as many different operating systems and browsers as possible. Currently, I have access to the following browsers:
As announced at IE Death march, I recently dropped support for Internet Explorer 6. As newer versions of Firefox, Opera, and Safari (and others) continue to improve consistency and provide better support for standards-based techniques, having to carry IE 6 along for the ride — for any reason — is painful. Thanks to the techniques described in this article, I am free to completely ignore (figuratively and literally) IE 6 when developing and designing websites. Now that I have dropped support for IE 6, I feel liberated, free of the constraints that once enslaved my time, energy, and resources. Working on my new design, I have already saved countless hours that would have been wasted on IE 6. If you are still chained to an old copy IE 6, I highly recommend kicking it to the curb and experiencing the freedom for yourself. All it takes is a few lines of code and the decision to go there.
This was just too juicy to pass up. Blogstorm recently blogged about an easy JavaScript technique for making any website editable. After checking it out for myself, I just had to share it here at Perishable Press. Here it is:
Paste that single line of code into the address bar of any modern browser and have fun editing the page. Obviously, any changes will only apply to the page as seen in your browser, not the original document. Even so, it’s a fun trick to play around with, snap screenshots, be creative, etc.
I recently twittered my intention to switch from the Firefox browser to the sleek, new Opera 9.5. I have always used Opera as a secondary browser, especially handy for speedy jumps into cyberspace, browser testing, and taking up space on my hard drive. I have always wanted to switch completely to Opera, but for many reasons, Firefox just keeps pulling me back into its comfortable grasp..
After a quick Opera-9.5 download, I decided to install Opera in its own directory instead of upgrading my current 9-point-whatever version. Unlike some browsers, multiple installations of Opera require nothing more than separate directories (as specified during the setup process). Within moments Opera 9.5 was loaded up and running tuf. The new darker default interface is sleek and sexy, inspiring me all the more to continue my quest to switch from Firefox.
As I began configuring the new Opera with imported bookmarks, speed-dial, home-page settings, and tab groups, I found myself digging up passwords that I haven’t had to remember in years. I know that Opera is equipped with its own “Remember Password” functionality, but you still have to enter each password at least once in order for it to work. Not a big deal, and certainly nothing against Opera, but it would have been great to have been able to import all of my saved Firefox passwords (if that’s even possible). In any case, after loading up and logging in to my core collection of tabbed sites, I spent a majority of the day using Opera instead of Firefox for all of my design, admin, and surfing needs.
Oooops! Didn’t really mean to add that particular word to the Firefox custom dictionary. Better remove it now before it causes problems later on..
As one who takes full advantage of the custom dictionary in Firefox, I occasionally find myself adding nonexistent or misspelled words to the dictionary by accident. Not wanting to deal with a false negative down the road, I always take the time to stop what I’m doing, locate the custom dictionary, and remove the erroneous term. Finally getting sick of trying to remember the esoteric location in which Firefox stores the personal dictionary, I decided to make a few notes and post the information here for easy access when it happens again (and it will happen again;).
Just a note to web designers and code-savvy bloggers: make sure your custom error pages are big enough for the ever-amazing <cough> Internet Explorer browser. If your custom error pages are too small, IE will take the liberty of serving its own proprietary web page, replete with corporate linkage and poor grammar.
How big, baby?
Well, that’s a good question. In order for users of Internet Explorer to enjoy your carefully crafted custom error pages, they need to exceed 512 bytes in size. Using proper doctype markup, your custom pages should include more than around 10 lines (roughly) of additional markup and/or content. A good rule of thumb is to throw down at least a couple of decent-sized chunks of code. If you are going for a minimalist set of custom error pages and need a way to increase overall page size, you can always add a paragraph or two of good ‘ol Lorem Ipsum text as a comment in the markup:
With the recent release of my latest WordPress plugin, Contact Coldform, I am also creating a series of free, “drop-in” CSS skins for easy, “plug-n-play” customization. These skins employ valid, optimized CSS code designed for the following browsers:
Firefox 2 (mac & pc)
Internet Explorer 6
Internet Explorer 7
Opera 9 (mac & pc)
Netscape
Camino
Safari
The goal for these skins involves minimizing the amount of CSS code while simultaneously maximizing its universal effectiveness. Thus, while these skins may not appear identical in every browser tested, I am able to keep CSS code sizes to a minimum by focusing on overall design proximity as opposed to pixel perfect precision, which is possible, but would require additional code. In other words, the balance between presentational fidelity and relative code quantity may require further manipulation, depending on your particular design requirements.
![[ Graphic: Firefox and Opera Icons ]](http://perishablepress.com/press/wp-content/images/2008/misc-chunks/firefox-opera.jpg)
I recently ![[ Icon: Contact Coldform ]](http://perishablepress.com/press/wp-content/images/2008/wp-coldskins/coldform-icon_small.gif){kind=icon}
With the recent release of my latest WordPress plugin,