(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.)
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.
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 has a great web browser resource called the WebKit Open Resource Project which is:
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.
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.
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.