David Calhoun's Developer Blog » mobile

Does it still make sense to use em rather than px?

David — Tue, 05 Oct 2010 18:13:15 +0000

Alex Kessinger tweeted asking if there was a reason to still use EMs instead of PX measurements in mobile. This is an interesting question, but 140 characters isn’t quite enough to explain my thoughts. So here’s an old-fashioned blog post!

Just a quick review: em and percentage (%) units in CSS are relative measurements, whereas px and other measurements are not. What this means is that the resulting size of relative measurements depends on the size of the parent.

The original reason to use EMs instead of PX measurements

As far as I can tell, the original reason why it became a good practice to use EMs was because of page scaling and accessibility reasons. When developers used PX measurements, they found that when the page was scaled (using Ctrl + Scroll Wheel), the parts of the page with fixed PX measurements didn’t scale.

Oh no! So when a user with poor eyesight tried to scale a page to read the text better, it turns out that the text they were interesting in making bigger actually didn’t change size at all!

So is this still the case today? By and large, no. All modern browsers except IE6 will now scale pages correctly, regardless of the type of CSS units used.

From what I’ve heard, there are still many users with disabilities using IE6, but the reason is because they don’t want to upgrade their copy of the screen reader JAWS, which is quite expensive. However, these users obviously aren’t affected by page scaling issues because they are blind.

Maintainability concerns

Even if the original reason to use EMs (above) is no longer valid, I still believe there are good reasons to use them.

One of the main reasons is maintainability. If a page is designed to have one base font size (applied to the Body) and all other font sizes on the page use relative units (EMs or percentages), changing the font sizes later becomes almost trivial. If someone wants to later increase the size of the fonts on their entire page, all they need to do is increase the one base font size.

This might be a bit of an edge case, but the elegance of the solution is too enticing!

Media queries and mobile

Very closely related to the above point is the subject of media queries. Recently media queries have been somewhat hailed as a panacea for all mobile development. I slightly disagree, but that’s a topic for another post!

The main point here is that people are now using media queries to quickly make mobile-friendly versions of their desktop websites. That’s awesome, there’s no doubt about that.

So what about EMs and PX measurements? Here’s the problem: if a developer coded their webpage in such a way that they used fixed pixel measurements, the amount of CSS required in the mobile media query could be obscenely large. This is because each individual element with pixel measurement was designed with the desktop in mind! This makes the task of adapting to different content very painful.

On the other hand, think about a page designed with relative units such as EMs or percentages. This page was designed so that each element was proportional to its parent element, so that ideally changing the size of the entire page occurs in only a few places, at the Body level of the document. Suddenly the CSS required for the mobile media query is much more manageable, since it’s now (ideally) only changing a few values on the Body element, not on every element on the page.

Thursday links (July 8)

David — Fri, 09 Jul 2010 04:00:09 +0000

Using mobile-specific HTML, CSS, and JavaScript (Mobile web part 5)

David — Wed, 30 Jun 2010 03:27:11 +0000

(updated June 27, 2011)

Mobile-specific HTML

Viewport tag

Use the viewport tag to properly fit the content to the screen:

Tel scheme (to initiate phone calls)

Call us at 1-800-555-5555

Sms scheme (to initiate text messages)

Disable automatic telephone number linking

iOS-specific HTML (some work on Android as well)

You also have access to several Apple-specific tags to use in your iOS applications (iPhone, iPad, and don’t forget the iPod Touch!).

Turn off autocorrect, autocomplete, and autocapitalize

And also some handy attributes to turn off annoying autocorrect features:

Mobile-specific CSS

position:fixed and overflow:scroll

Mobile browsers are now starting to support these basic CSS properties better. Position:fixed will work on Android 2.2+ and iOS 5+. Overflow:scroll works with one finger on iOS 5+.

Also, iOS 5 has additional CSS to give the native scrollbar and momentum/intertia to elements with overflow:scroll: -webkit-overflow-scrolling: touch;

Media queries

Media queries enable you to target specific features (screen width, orientation, resolution) within CSS itself. Media queries themselves are actually quite old and are not mobile specific (they used to be popular for making a print-friendly version of webpages).

You can use them two ways: 1) inline in a CSS stylesheet or 2) as the “media” attribute in the link tag, which loads an external stylesheet. The following is an example of inline CSS that’s applied only when the device is in portrait mode:

@media all and (orientation: portrait) {
	body { }
	div { }
}

Here’s the same media query using the other method, which points to an external stylesheet (not recommended):

This is not recommended because it creates an additional HTTP request (bad for performance). Also, in the case of screen orientation, the separate CSS stylesheet is NOT downloaded when the screen is rotated.

Here’s a few examples of using inline CSS:

// target small screens (mobile devices or small desktop windows)
@media only screen and (max-width: 480px) {
  /* CSS goes here */
}

/* high resolution screens */
@media (-webkit-min-device-pixel-ratio: 2),
             (min--moz-device-pixel-ratio: 2),
             (min-resolution: 300dpi) {
  header { background-image: url(header-highres.png); }
}

/* low resolution screens */
@media (-webkit-max-device-pixel-ratio: 1.5),
             (max--moz-device-pixel-ratio: 1.5),
             (max-resolution: 299dpi) {
  header { background-image: url(header-lowres.png); }
}

Miscellaneous CSS

-webkit-tap-highlight-color (iOS): override the semitransparent color overlay when a user clicks a link or clickable element. To completely disable it, set the value to ‘transparent’ or ‘rgba(0,0,0,0)’

-webkit-user-select: none; – prevent the user from selecting text (also works on desktop WebKit)

-webkit-touch-callout: none; – prevent the callout toolbar from appearing when a user touches and holds an element such as an anchor tag.

Mobile-specific JavaScript

window.scrollTo(0,0);

This hides the address bar and takes advantage of the entire device screen. You’ll have to set this in a timeout and make sure to get the timing right. See Remy Sharp’s post for more details.

window.matchMedia()

(iOS 5+) Again, just as CSS media queries aren’t specific to mobile, they do come in especially useful for mobile, so it’s worth mentioning their JavaScript counterpart. window.matchMedia() is a JavaScript-based version of media queries. You can use respond.js as a polyfill for devices that don’t support this functionality natively.

navigator.connection

(Android 2.2+) Determine if the phone is running on WiFi, 3G, etc. Example:

if (navigator.connection.type==navigator.connection.WIFI) {
  // code for WiFi connections (high-bandwidth)
}

window.devicePixelRatio

Determine screen resolution (analogue to the CSS media query). (iPhone 4 has the value 2, while Nexus One has the value 1.5).

window.navigator.onLine

Not strictly mobile, but helpful for apps to determine if they’re being run offline.

window.navigator.standalone

(iOS 2.1+): determine if it’s running in full-screen mode

Touch and gesture events

touch events (iOS, Android 2.2+): touchstart, touchmove, touchend, touchcancel

gesture events (Apple only, iOS 2+): gesturestart, gesturechange, gesturend give access to predefined gestures (rotation, scale, position)

Screen orientation (every 90 degrees)

orientationchange event: triggered every 90 degrees of rotation (portrait and landscape modes). The current orientation is available through window.orientation

Device orientation (more fine-grained)

The deviceorientation event will fire very frequently, and gives more fine-grained information about the device’s orientation in three dimensions.
MozOrientation (or onmozorientation?) (Fennec/Firefox Mobile, Firefox 3.5+): also not strictly mobile. Gives access to the device’s accelerometer (x-y-z orientation data), updated periodically. Works on Android phones running Mobile Firefox. On the desktop this works with laptops such as Thinkpads and MacBooks.

devicemotion (shake gestures, etc.)

devicemotion fires when the user shakes or moves their device. Devicemotion taps into the accelerometer, which is fires off when the device accelerates. Contrast this with the deviceorientation event, which taps into the device’s gyroscope (if it has one), which only measures the 3D angle orientation, even when the device is at rest.

Media capture API

While iOS is still lacking basic file inputs, Android is forging ahead, giving developers fine-grained control over content users can upload.

BlackBerry specific

If you’re developing for a BlackBerry Widget, you have access to proprietary information through the blackberry object (which gives access to useful information such as blackberry.network [returns values such as CDMA and Wi-Fi] and blackberry.system).

You also have the option to use PhoneGap, which augments JavaScript and gives you access to more phone features that native apps would have access to.

Use a mobile-optimized JavaScript library

I’ve created a separate entry for the available mobile libraries and frameworks.

Because smartphone browsers are standards-based, the aim of a JavaScript library on mobile is less towards API normalization and more towards providing an actual UI framework, usually to emulate the feel of native apps (and to provide easier workarounds to lack of access to position:fixed). We’ve seen a few libraries released that emulate the iPhone UI, and in the future we might see libraries emulating the Android UI, as well as entirely new UIs.

There’s also a bit to be said about simply loading full desktop JavaScript libraries into mobile clients. In my opinion this doesn’t particularly make sense, especially in a world where latency and bandwidth are so much more of a concern. It doesn’t make sense to force the user wait longer and download code that’s ultimately useless to them (hacks for desktop browsers such as IE 6, etc).

Take advantage of new stuff!

While not specific to mobile, there’s a lot of new stuff in general that you can use. If you limit yourself to the top smartphones (iPhone, Android, and maybe webOS), compared to the desktop you immediately have access to an even wider array of new stuff, especially many Webkit proprietary features, since most of these top smartphones have browsers based on Webkit.

-HTML: new tags (HTML5 (I’m sure you’ve heard of it by now…))
-CSS: 2d transforms, 3d transforms, animation, border radius, custom fonts with @font-face, etc.
-JavaScript: strict mode, constants, block scope, Date.now(), etc.

Slides

Mobile HTML, CSS, and JavaScript

View more presentations from franksvalli

More from the Mobile Web series:

Part 1: The viewport metatag
Part 2: The mobile developer’s toolkit
Part 3: Designing buttons that don’t suck
Part 4: On designing a mobile webpage
Part 5: Using mobile-specific HTML, CSS, and JavaScript
Part 6: Dealing with device orientation
Part 7: Mobile JavaScript libraries and frameworks

JavaScript SunSpider: HTC Evo versus HTC Incredible versus Nexus One

David — Fri, 11 Jun 2010 05:07:11 +0000

Result table

Test	Evo (2.1)	Incredible (2.1)	Nexus One (2.2)
Total	16167ms	15237ms	5452ms
3D	2014ms	1835ms	946ms
Access	2126ms	1892ms	463ms
Bitops	1519ms	1591ms	360ms
Controlflow	243ms	206ms	20ms
Crypto	1033ms	1003ms	344ms
Date	1849ms	1896ms	639ms
Math	1684ms	1419ms	602ms
Regexp	1779ms	1673ms	155ms
String	3920ms	3722ms	1923ms

Thoughts

The Incredible is just slightly faster than the Evo, to the point where it’s probably negligible or within a margin of error. Both of these phones run on Android 2.1 with HTC’s Sense UI modifications, and represent the latest and greatest in Android phones available on the market today. Both run on the same 1GHz Snapdragon processor (QSD8650). The Nexus One is a bit older, and runs with an older version of the Snapdragon processor (QSD8250), however it still runs at 1GHz just like the other two phones.

As you can see the Nexus One blows away all the competition because it’s running Android 2.2 Froyo. These results were quite a shock to me and are quite impressive. These results even blow away Apple’s new iOS 4 running on my iPhone 3GS, which clocked in at a total time of 13787ms compared to the Nexus One’s startling 5452ms.

Testing methodology

Test: SunSpider 0.9.1

Devices: HTC Evo (Android 2.1), HTC Incredible (Android 2.1), HTC Nexus One (Android 2.2)

The SunSpider test was run five times on each phone. The phone was completely turned off and on before each test. The most extreme values of the five tests were thrown out, and the resulting four tests were averaged (sometimes from three tests when the values were very close together).

Raw results:

SunSpider HTC Evo results (5 tests)

SunSpider HTC Incredible results (5 tests)

SunSpider HTC Nexus One results (5 tests)

Mobile First: Luke Wroblewski on mobile design

David — Sat, 05 Jun 2010 19:12:26 +0000

In episode 6 of The Big Web Show, Luke Wroblewski gives his “Mobile First” talk, explaining his philosophy for designing for mobile, the challenges, and a look at the road ahead. Luke explains that because of the limitations on mobile, developers are forced to really optimize the user experience for mobile. Often times this mobile experience turns out much better than on the desktop, where the “gluttony of resources” results in distracting and excessive webpages.

On designing a mobile webpage (Mobile web part 4)

David — Thu, 27 May 2010 02:58:17 +0000

The frontend engineer lives at the intersection between design and engineering, and this is perhaps nowhere more true than in the world of mobile. In order to make a usable desktop website, an engineer must have at least some sense of design, and fortunately a lot of this has been standardized over the years. But the world of mobile is full of more unknowns, and the field is changing rapidly, especially lately from the shift away from older feature phones to the focus on smartphones. As such, the mobile engineer has to be on their toes in the sense of both design and engineering.

The focus of this article is on mobile design in general. I’m by no means an expert, but these are some things I’ve found to be essential and basic topics. Hopefully you will find this useful!

Only one column?

Mobile websites should only have one column of main content. This point is stressed again and again in mobile design, and for good reason: the paradigm of multi-column layouts is fairly well-entrenched in desktop design, but it’s simply not an option for a well-designed mobile site.

To illustrate this point, the following two images are both 320 pixels wide, which is a common smartphone width in portrait mode. The image on the left is the Yahoo! front page (yahoo.com) in its three-column fixed width desktop size, and the image on the right is Yahoo! mobile’s front page (m.yahoo.com):

This might not be a fair comparison, as the desktop version isn’t optimized for mobile, so you can’t even read the text without zooming in. However, even if the size of the text was increased, it’s apparent that three columns is just too much, both because of screen width concerns as well as concerns about too much content. There’s simply too much information being crammed down the user’s throat. Chances are the user only wants to check a few things and then put the phone back in their pocket, and this three-column version of the site is preventing them from doing that.

Modules, modules, modules

It’s helpful to think of a webpage as being composed of modules. If you’re converting a desktop website into a mobile site then you must essentially think of the website as bits of rearrangeable components:

What you’re doing is essentially grabbing your most important components and making sure they appear at the top, then stacking each module on top of each other. And don’t forget we do have variable screen widths on mobile (even on phones themselves, since they can be either in portrait or landscape mode), so we should be sure that each module is taking up 100% of the available screen space. In more technical terms, yes, this means we have to make a fluid layout.

Clarity and concision

It’s important to be both clear and concise in presentation. On the desktop we can get away with a certain amount of screen bloat, but users always appreciate simple sites when they come across them. This is a huge part of what made Google so successful: users came to the site for one thing, search, and the site was kept simple to facilitate that interaction.

As it turns out, it’s quite hard to be clear and concise. I like to compare this to writing papers for school. Often we were given assignments that needed to be a minimum of X amount of words or pages, and it was sometimes challenging to find information to meet this minimum. Fortunately (or unfortunately) many students developed a highly refined skill of BSing to fill the word limit. But were you ever given an assignment where there was a word/page MAXIMUM? This turns out to be much harder to write for, mostly because you can’t BS it. You have to identify the fluff, the nonessential bits, and surgically remove them from your paper. (As a side note, in the area of computer science, notice how many HUGE tomes there are out there compared to smaller books. I would venture to guess that engineers have a hard time being concise.)

This is just the problem we now face with mobile. We know how to fill up webpages with fluff: add an RSS feed here, add a module that ties into Facebook there, add another feed here, stick a relatively unimportant module there, add an excessive amount of social sharing buttons, and presto, we have a website that looks pretty active. But how does that translate to mobile? The questions you’re forced to ask yourself are: “do I really need this data feed displayed here?”, “do I need this huge Facebook module here taking up space?”. Or more positive questions like “what are the things users will come to my site to check, and how do I make it easier for them to find those things?”.

In the case of the last question, it’s easy to see from the above screenshots what Yahoo mobile thought was most important: Mail, Search, and News, all of which are visible at the top of the page. Think about your website’s main two or three features and try to make those just as visible.

Useful links

W3C Mobile Web Best Practices 1.0
Tips and Tricks for developing Mobile Widgets

The viewport metatag (Mobile web part 1)

David — Fri, 07 May 2010 05:11:44 +0000

The skinny

Use this:

Introduction

This series of posts is intended to introduce web developers to basic techniques for designing for the mobile web. It assumes at least a basic knowledge of creating desktop websites.

The problem

Ok, so you’ve settled down to learn how to write a website for a mobile device using your current knowledge of building desktop websites. So you start off with some pretty basic HTML:

Hello world!

Ok! You can’t get much simpler than that. You check it out and it looks good on all the desktop browsers, since there’s really no opportunity yet for any cross-browser inconsistencies. And then you check it out on your mobile device:

Hello World on the iPhone

Doh! Where’d we go wrong? The text is obviously way too small to read without zooming in.

This is the first lesson in making mobile websites: width is your enemy. This is the first of many countless problems with device width you will encounter. Fair warning.

If you think about it logically, it seems to make sense: mobile Safari took a look at the page and assumed it was a document designed for the desktop, which is true of the vast majority of websites. So it gave the website a width of 980 pixels and presented it zoomed out. Which is why we can’t read anything until we zoom into the page.

Viewport

But this is no good! What we need to do is tell the browser that this webpage is optimized for mobile. And this is where the viewport metatag comes into the picture.

Now we tweak our Hello World just a bit…

Hello world!

And we get this…

Hello World with the Viewport tag

Much better! By setting the viewport width equal to “device-width”, we’re essentially telling it that the device width is 320px, not the default value of 980px that it guessed. If we set width=320 it would achieve the same result on the iPhone and a few other smartphones, but not all phones have this exact width, so it’s best to simply set device-width and let the mobile browser figure it out.

This viewport metatag is supported on many smartphones, from iPhone to Android to webOS (Palm) to even Internet Explorer Mobile, Opera Mini and Opera Mobile.

At the end of the day here’s what the standard viewport looks like, as grabbed from m.yahoo.com:

EDIT: It’s been discussed a bit, and it seems that preventing the user from scaling the page (pinch zooming) isn’t necessarily desirable. So here’s a version of the tag that allows the user to pinch zoom:

More fun with the viewport tag

In addition to solving our biggest concern with the width of the content, the viewport tag has more options to play with:

Property	Description
width	Width of the viewport in pixels (or device-width). If width isn’t set, it defaults to a desktop size (980px on mobile Safari).
height	Height of the viewport in pixels (or device-height). Generally you don’t need to worry about setting this property.
initial-scale	(0 to 10.0) Multiplier that sets the scale of the page after its initial display. Safe bet: if you need to set it, set it to 1.0. Larger values = zoomed in, smaller values = zoomed out
minimum-scale	(0 to 10.0) The minimum multiplier the user can “zoom out” to. Defaults to 0.25 on mobile Safari.
maximum-scale	(0 to 10.0) The minimum multiplier the user can “zoom in” to. Defaults to 1.6 on mobile Safari.
user-scalable	(yes/no) Whether to allow a user from scaling in/out (zooming in/out). Default to “yes” on mobile Safari.

Feature phones: when viewport isn’t available…

Unfortunately the viewport tag is relatively new and as such isn’t universally supported, especially if you’re working on older feature phones. But there are some older methods at your disposal for identifying your website as optimized for mobile:

This tag was originally used to identify mobile content in AvantGo browsers, but has now been made the general standard for identifying mobile websites. However, it’s unknown what range of browsers support this meta tag.

Another tag at your disposal is a Windows-proprietary meta tag that also took root and eventually became used as another means of identifying mobile content. The drawback with this tag is that a specific width must be given, which doesn’t make it as flexible as the viewport tag (see above). Again, it’s unknown what the support for this tag is:

Lastly, your website will be identified as a mobile optimized site if your doctype is either XHTML-MP or WML. However, this is becoming less and less the case these days, as browsers begin to support good old HTML4.01 and HTML5+.

(info for this section comes from Beginning Smartphone Web Development)

Custom Android properties

The official Android documentation lists a special property they’ve added to the meta tag: target-densitydpi. This property essentially allows developers to specify which screen resolution the page has been developed for, or more specifically how to handle the scaling of media such as images.

Here’s an example of the tag in action:

References

Safari HTML Reference: Supported Meta Tags
Mobile META Tags

David Calhoun's Developer Blog » mobile

Does it still make sense to use em rather than px?

The original reason to use EMs instead of PX measurements

Maintainability concerns

Media queries and mobile

Thursday links (July 8)

Mobile

JavaScript

CSS

Books

Etc.

Using mobile-specific HTML, CSS, and JavaScript (Mobile web part 5)

Mobile-specific HTML

Viewport tag

Tel scheme (to initiate phone calls)

Sms scheme (to initiate text messages)

Disable automatic telephone number linking

iOS-specific HTML (some work on Android as well)

Turn off autocorrect, autocomplete, and autocapitalize

Mobile-specific CSS

position:fixed and overflow:scroll

Media queries

Miscellaneous CSS

Mobile-specific JavaScript

window.scrollTo(0,0);

window.matchMedia()

navigator.connection

window.devicePixelRatio

window.navigator.onLine

window.navigator.standalone

Touch and gesture events

Screen orientation (every 90 degrees)

Device orientation (more fine-grained)

devicemotion (shake gestures, etc.)

Media capture API

BlackBerry specific

Use a mobile-optimized JavaScript library

Take advantage of new stuff!

Slides

More from the Mobile Web series:

JavaScript SunSpider: HTC Evo versus HTC Incredible versus Nexus One

Result table

Thoughts

Testing methodology

Related links

Mobile First: Luke Wroblewski on mobile design

On designing a mobile webpage (Mobile web part 4)

Only one column?

Modules, modules, modules

Clarity and concision

Useful links

More from the Mobile Web series:

The viewport metatag (Mobile web part 1)

The skinny

Introduction

The problem

Viewport

More fun with the viewport tag

Feature phones: when viewport isn’t available…

Custom Android properties

References

More from the Mobile Web series: