Even the cleanest, best designed sites can fall victim to the
awkward middle-ground of responsive website design and development that
tablets create. Then consider plugin content and a host of other issues
and you’re sometimes not sure where to start. So how do you ensure that
people experiencing your site on one of the world’s fastest growing
hardware technologies receive the best possible experience on your site?
The good news is…simply put: Your site doesn’t have to look terrible on
iPad.
Preparing Your Web Content for iPad
iOS 7 is here, the iPad Air is here, Apple keeps updating. This year
tablets will outship PCs and laptops combined. So why is it when we
visit sites they look like crap on our iPads?
Here is how to get your web content in Safari on iPhone OS devices,
with specific information for iPad – LOOKING AWESOME. Of course you can
always just call us.
Safari on iPad is capable of delivering a “desktop” web experience.
iPad has a large, 9.7″ screen and fast network connectivity, and Safari
on iPad uses the same WebKit layout engine as Safari on Mac OS X and
Windows. You can ensure that your website looks and works great on iPad,
and even create new touch-enabled web experiences for your customers,
by considering a few specific differences between iPad and other
platforms.
If you have access to an iPad, test your website using the iPad. If
not, you can test your website in Safari on iPad using the iPhone
Simulator (Hardware -> Device -> iPad). iPad is available in the
iPhone Simulator in iPhone OS 3.2 SDK beta 2 and later, which is
available to iPhone Developer Program members. In cases where it is
possible to simulate iPad-like behavior in Safari on a desktop computer,
instructions are given below.
Test your website on iPad, and update user agent detection code if necessary
Many websites perform server-side checks on the browser’s user agent
string to determine whether or not they should serve the mobile version
of their website. Safari on iPad is capable of delivering a “desktop”
web experience, and users will expect this experience since iPad has a
large screen and fast network connectivity. If you have a version of
your website that is optimized for mobile devices with small screens, do
NOT serve this mobile version to iPad users.
Listing 1-1 shows the Safari on iPad user agent string. It identifies
the version of Safari that is running on iPad, and iPad is identified
as a mobile device.
Listing 1-1 Safari on iPad user agent string in iPhone OS 3.2 SDK beta 3
Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us)
AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b
Safari/531.21.10
Note that the Safari on iPad user agent string contains the word
“Mobile”, but does not contain the word “iPhone”. If you are currently
serving mobile content to any browser that self-identifies as “Mobile”,
you should modify your user agent string checks to look for iPad and
avoid sending it the wrong version of your site. The version numbers in
this string are subject to change over time as new versions of Safari on
iPad become available, so any code that checks the user agent string
should not rely on version numbers.
Simulating Safari on iPad HTTP requests in Safari on the desktop
If you’re unable to test with an iPad or iPhone Simulator, you can
simulate an HTTP request from Safari on iPad in Safari on a desktop
computer. First, load your website in Safari on Mac OS X or Windows.
Then, enable the checkbox next to “Show Develop menu in menu bar” in
Safari’s Advanced Preference pane, as shown in Figure 1-1.
Figure 1-1 Enabling the Safari Develop menu.
Next, select Develop -> User Agent -> Other from the Safari
menu. You will be prompted to enter a user agent string. Copy the
Safari on iPad user agent string above, then paste in it into the dialog
box that appears, as shown in Figure 1-2.
Figure 1-2 Customizing the user agent string.
When you click “OK”, the User-Agent field in any HTTP request headers
will be set to the string that you just entered, and the page will
automatically reload. When the page reloads, you should verify that
you’re NOT serving the mobile version of your website to iPad. You can
verify that the Safari on iPad user agent string was sent to your server
by inspecting request headers in the Resources pane of Safari’s Web
Inspector, as shown in Figure 1-3. This user agent string setting
persists on a per-window basis.
Figure 1-3 Inspecting request headers.
Use W3C standard web technologies instead of plug-ins
Plug-ins are not supported in Safari on iPad, nor are they supported in Safari on iPhone.
If you’re using a plug-in to display user interface elements such as
menus or other navigation elements on your website, these elements will
not be accessible to Safari on iPad or Safari on iPhone users. Be sure
to include a code path for platforms that do not support plug-ins, and
for users on desktop platforms such as Mac OS X or Windows that may have
plug-ins disabled.
If you’re using a plug-in to embed audio or video in a webpage, you
can use the HTML5 <audio> and <video> tags to deliver audio
and video content in Safari on iPad and iPhone. These tags work
seamlessly with HTTP Live Streaming, and it is easy to structure your
HTML to fall back to plug-in content in browsers that don’t support
these elements. For more information on using HTML5 <audio> and
<video> tags, see the Safari Guide to HTML5 Audio and Video, and
the HTMLMediaElement, HTMLVideoElement, and HTMLAudioElement class
references in the Safari DOM Extensions Reference.
If you’re currently using a plug-in to draw animations in your
webpages, you can use a combination of JavaScript and CSS3 transforms,
transitions, and animations to create animations in Safari on iPhone OS.
Testing without plug-ins in Safari on the desktop
If you’re unable to test with Safari on an iPad or using the iPhone
Simulator, you can verify that your website works well without plug-ins
in Safari on the desktop. Begin by disabling the checkbox next to
“Enable plug-ins” in Safari’s Security Preference pane, as shown in
Figure 4.
Figure 1-4 Disabling plug-ins in Safari on the desktop.
Next, visit your website. Elements on webpages which use plug-ins may be
replaced with messages advising you to download or upgrade the required
plug-in. In Safari on iPad, these areas may be blank.
Check your viewport tag settings
If you’ve specified viewport settings for your webpage in Safari on
iPhone, verify that these same settings are suitable for Safari on iPad.
Specifically, if you want the width of the viewport to match the width
of the device, you should use the device-width constant instead of a
hard-coded pixel value. For example, many websites use the setting shown
in Listing 1-2 to set the viewport to a width that they consider
suitable for iPhone.
Listing 1-2Incorrect: Using a pixel value for viewport width.
meta name="viewport" content="width=320" /> <!--- WRONG //--->
Using the device-width constant as shown in Listing 1-3 is a much
better approach, as it will set the viewport to the width of the current
device.
Listing 1-3Correct: Using a constant for viewport width.
meta name="viewport" content="width=device-width" Modify code that relies on CSS fixed positioning
CSS fixed positioning works in Safari on iPhone and iPad, but not as
you might expect. While elements that use fixed positioning in Safari on
Mac OS X and Windows always stay on screen, elements that use fixed
positioning in Safari on iPhone and iPad can end up offscreen as users
zoom and pan the webpage. Why does this happen?
By definition, the containing block of a webpage element that uses
CSS fixed positioning is the viewport. This means that when you set
position: fixed with a bottom and right value of 20px as shown in
Listing 1-4, you have “fixed” the position of an element 20 pixels above
the bottom edge of the viewport, and 20 pixels from the right edge of
the viewport.
Listing 1-4CSS fixed positioning.
#fixed {
position: fixed;
right: 20px;
bottom: 20px;
height: 100px;
width: 100px;
background-color: purple;
}
In Safari on the desktop, the viewport is analogous to the window —
as you resize a window, you are resizing the viewport. As you scroll,
you are scrolling the viewport. Hence, in Safari on Mac OS X and
Windows, the element always stays on screen.
Safari on iPad and Safari on iPhone do not have resizable windows. In
Safari on iPhone and iPad, the window size is set to the size of the
screen (minus Safari user interface controls), and cannot be changed by
the user. To move around a webpage, the user changes the zoom level and
position of the viewport as they double tap or pinch to zoom in or out,
or by touching and dragging to pan the page. As a user changes the zoom
level and position of the viewport they are doing so within a viewable
content area of fixed size (that is, the window). This means that
webpage elements that have their position “fixed” to the viewport can
end up outside the viewable content area, offscreen.
Prepare for a touch interface
Although an external hardware keyboard is an option for use with
iPad, the primary means of interacting with web content in Safari on
iPad is through touch. The software keyboard appears in Safari on iPad
and iPhone when a form control that requires text input — such as
<input type=”text”> or <textarea> — gains focus. Users
should not be forced to rely on a keyboard to navigate your webpage.
Additionally, Safari on iPhone OS users interact with your web
content directly with their fingers, rather than using a mouse. This
creates new opportunities for touch-enabled interfaces, but does not
work well with hover states. For example, a mouse pointer can hover over
a webpage element and trigger an event; a finger on a Multi-Touch
screen cannot. For this reason, mouse events are emulated in Safari on
iPhone OS. As a result, elements that rely only on mousemove, mouseover,
mouseout or the CSS pseudo-class :hover may not always behave as
expected on a touch-screen device such as iPad or iPhone.
You can handle touches directly or even detect advanced gestures in
Safari on iPhone OS, using the DOM Touch events touchstart, touchmove,
touchend, and touchcancel. Unlike mouse events which are emulated, DOM
Touch events are specifically designed to work with touch interfaces, so
their behavior is reliable and expected. For more information on using
touch events in web content for Safari on iPhone OS, see the “Handling
Events” section of the Safari Web Content Guide, the Touch, TouchEvent,
and TouchList classes in the Safari DOM Extensions Reference, and the
SlideMe sample code at the Safari Dev Center.
Since touching and holding in Safari on iPhone OS will invoke the
Cut/Copy/Paste dialog, you may also choose to disable selection on user
interface elements such as menus and buttons using -webkit-user-select:
none. It is important to only disable selection as needed on a
per-element basis. Selection in webpages should never be globally disabled.
Use textareas instead of contenteditable elements
contenteditable is not supported in Safari on iPhone OS. If you’re
using contenteditable to enable text input within a styled element (for
instance, <p contenteditable> or <div contentediable>), you
can replace this styled element with a styled <textarea>. In
Safari on iPad, iPhone, Mac OS X, and Windows, you can customize the
appearance of <textarea> elements using CSS. If necessary, you can
even disable any platform-specific, built-in styling on a
<textarea> by specifying -webkit-appearance: none.