Post Page-Loading iPad/iPhone/iPod CSS Styles, But Only When Needed

March 29, 2012

(For the purposes of this article I will only refer to the iPad, however, I am speaking in terms of any i-Product: the iPad, the iPhone, or touch iPod.)

Recently, I designed a large website that needed to work on all the basic desktop browsers (IE 7/8/9, Safari, Firefox, Chrome). Everything went great until I was done with the site. As soon as I was done, I was told that it now needed to support the iPad. This was not a big deal but was a little problematic since I had not initially designed the site for viewing on those devices. However, the site was all standard CSS, HTML, and JavaScript so I knew it would not be a major task to add in support.

The Problem with iPad
Right away, I ran into a few problems. The first problem was the fact that the iPad relies on the onclick() method being attached to an element in order to determine if it should pass synthesized mouse events to it or not. I solved this with a pretty simple method, and I have written an article that explains my solution in-depth, here. For now, the subject of this article deals only with the iPad’s default CSS settings. Mainly, the fact that scrollbars are turned OFF by default on these devices and how to easily turn them back on, but only when the user is viewing your site with an iPad. “Aha!”, you say… why can’t we just add these CSS changes to our main site’s CSS definitions? Because Safari on the desktop and iPad use the same Webkit CSS package. Which means that if you want to customize your CSS look for each of these versions of Safari, you will need to determine on-the-fly which device is looking at your site and make any CSS additions needed (or not). Also, because of future updates to other browsers, we want to make sure that we do not inadvertently affect these other browsers by assigning styles we do not need.

You see, when the iPad user interface was designed, it was decided that scroll bars were a thing of the past and should be turned OFF by default. Touch commands are the new darling of the user interface community, but since not every device is touch-event driven, this can cause problems for web designers. Ideally, you want to have as few versions of a website as possible. Ideally, you strive for a single, perfect website. One that looks great on all devices. But realistically, this never happens since a website that looks awesome on one device rarely looks good enough on all the others… so, for now, you usually end up creating two websites – one for desktops/tablets, and one for mobile phones.

Bye-Bye Scrollbars
Now, a lack of scrollbars is normally not a problem on the iPad, especially for sites designed specifically for viewing on these devices. But there have been many times I have designed sites which contain smaller, scrollable regions on their pages which do not visually look scrollable when viewed on an iProduct. Since our overall goal as great designers is to always strive for creating intuitive content, this lack of scrollbars can actually work against us by bringing down our site’s overall initial intuitiveness and usability.

Maybe scrollbars are a thing of the past, but for now, users will still need them in order to help them make the move across the gap from traditional to touch-based user interfaces. Sure, most iPad users are aware that you can drag elements and they will scroll if they are able to scroll. But, what gets overlooked is that sometimes elements which DO contain scrollable content don’t look like they are scrollable, so users will not even try. They have no scrollbars acting as a visual cue to let users know they can scroll this item’s content, so a lot of visitors (who may be paralyzed by the fear of clicking the wrong thing) won’t explore your page and so miss important content. So, what to do? Well, add scroll-bars! But how do we do that for just the iPad?

What I needed was a solution that was not a plug-in, or some browser-based hack. It had to be robust. It couldn’t be brittle and break after the first update to any of the site’s supported browsers. You see, in these days of constant software updates, many browsers now update themselves without requiring the user to actively seek updates, download them, then install them manually.

This is great for keeping your browser current, but it also means that every time a browser is updated, any non-standard, remotely-fragile solutions that you have hacked together to make your site function, have now become time bombs. You never know which update to which browser will cause them to halt your site’s functioning. So, any web design solutions you implement need to be simple, based on standard web technologies, and robust without depending on a specific browser version to work properly.

Apple’s Webkit
Apple has a great web browser resource called the WebKit Open Resource Project which is:

WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that’s used by Safari, Dashboard, Mail, and many other OS X applications. WebKit’s HTML and JavaScript code began as a branch of the KHTML and KJS libraries from KDE…

It does a great job by default on most items. However, if your page really needs to have those small, indicating scrollbars, then you need to turn them on yourself using webkit without affecting the rendering of your page in other, desktop browsers, like Safari. If you are not careful, you will end up with tiny scrollbars in the desktop version of Safari as well as the iPad version. Why? Because they both rely on Webkit! So, if you don’t filter the userAgent to look for just the iPad info, then you inadvertently end up assigning the styles to both.

The Solution
So, how do you adapt your site to the iPad without requiring you to add a lot of extra code and style sheets to your website? Part of the answer is to use some JavaScript to do some post-load page manipulation in order to augment any elements that require special attention for them to function properly on the iPad (see my Article “Make Your jQuery Website Buttons/Links Work with iPad/iPhone”). The other half of the solution is to load some additional CSS styles, but only if the site is loaded onto an iPad.

You may be thinking right now,”Why not just use jQuery?”… well, the problem with that solution is that the additional CSS stylesheet really needs to be loaded in the HEAD tag of your HTML page, which means that this must be done BEFORE your jQuery even gets loaded. Also, if you try to simply re-write the page’s HEAD tag after load and after jQuery runs, you get unpredictable results in some browsers. So, the best solution is one that does not rely on any other API than the standard library of default JavaScript functions.

Below is the portion of the code where the magic happens. It is standard JavaScript and does not use jQuery since it has to happen in the head tag, before any jQuery is loaded and just after our site’s base CSS external definitions are loaded. To download the complete source and example files click here.

// we use a regular expression to see if the user agent string contains iProduct identifiers...
if( String(navigator.userAgent).search(/(ipad)|(iphone)|(ipod)/i) > 0 )
// we then dynamically add in an additional stylesheet definition.
// this must load AFTER your site's normal CSS definitions, or they might be overwritten
document.write('<link rel="stylesheet" type="text/css" href="scripts/website_styles_iproducts.css">');

To view the above code in action, load this page onto your iProduct then click here. You will not see any effect on any other non-iProduct browsers.

Last Note
You can use the above method to look for any particular browser or mobile device if you know it’s user agent identifier. Here is a good article to get you started on identifying other devices.

Just be sure that the over code appears INSIDE the head tag of your HTML page and AFTER the other link tags that you have loading your site’s main CSS definitions.