Picture this. You’ve just created a responsive masterpiece, and then you check it out on a mobile device. Things break in ways you never would have expected. Text is going haywire, animations are choppy, and your forms don’t look anything like how you styled them. You spend hours scouring the internet for answers to be led in circles. In frustration, you throw your computer out the window and accidentally hit the neighbor’s cat.
The good news is that I’m here to protect you from the types of mobile development pitfalls that will lead to you throwing your computer out a window. Here are the major pitfalls we’re going to cover:
- Unexpected font size changes
- Unwanted form styles
- Emulator errors that can make you think you have a problem when you don’t
- Animations that looked nice on desktop but appear choppy on mobile
- Touch events whose coordinates are not registering properly even though no errors are showing
Let’s get started!
Assumptions for This Tutorial
This tutorial assumes you have some awareness of the basics of responsive web development, but in case you need to get up to speed, I’ve written a brief guide.
1. Unexpected Font Size Changes
Rotating an iOS device sideways can change the text size of your pages and ruin your layouts. This issue frequently happens with fixed position elements like navigation bars and menus. Once this happens, the only way to fix it is to refresh the page. Fortunately, there’s a way to stop unwanted text size changes before they happen.
Insert this code into your CSS:
html {
/* Prevent font scaling in landscape while allowing user zoom */
-webkit-text-size-adjust: 100%;
}This code nullifies the font size adjustment in landscape by saying, Hey, browser. If you’re going to adjust the text size in landscape mode, adjust the text to 100% of its current size, or in other words, the same size.
Problem solved.
2. Unwanted Form Styles
Tablets and mobile devices often come with default styles that can mess up your forms. To get rid of default styling on your form elements, put the following code in your CSS:
input[type=text], button, select, textarea{
-webkit-appearance: none;
-moz-appearance: none;
border-radius: 0px;
}Feel free to mix and match depending on what types of form element styles you want to reset. For example, if you want to reset the styles of all types of inputs, change input[type=text] to input. Be forewarned that this will affect your checkboxes and radio buttons too, so make sure you intend for that to happen.
3. Emulator Errors Can Mislead
If you’re testing your websites with a browser-based mobile emulator, sometimes the emulator itself can become confused. This is one of the trickiest kinds of errors because you’ll see a problem even though nothing seems to be wrong with your code.
For example, I once had a navigation bar that kept disappearing from the bottom of a page I was developing. After trying to figure out what was wrong, I discovered that the Chrome emulator’s viewport was getting cut off at the bottom. What revealed the problem was that half of the scrollbar disappeared at the bottom of the page. I resolved the issue by opening the page in a new tab, switching mobile view off and on, and then refreshing.
In situations like these, it’s important to first ensure nothing is wrong with your code. I suggest isolating the problem area and seeing if the code works by itself. If the code works, then try it on a real mobile device. If it works there, then there’s a chance your emulator might be the source of the problem.
4. Smooth Animation on Desktop Could Be a Rough Animation on Mobile
If you’re using animations on mobile devices, pay extra attention to performance. In general, browsers can animate the following properties efficiently: translate, scale, rotate, and opacity. Here are examples of how that might look.
transform: translate(15px, 40px); /* shift left 15px and down 40px */
transform: scale(2); /* scale to 2 times original size */
transform: rotate(30deg); /* rotate 30 degrees */
opacity: 0.5; /* set opacity at 0.5 */The reason you’d want to animate these properties is that they sit on the top layer of what the browser renders. If you think of a web page as a dining table, animating things on the top layer is like moving a single spoon while animating something on the lower layers is like trying to move the whole table cloth. You can do it, but it’s more work because you’re dragging all the higher layers along with it.
For more information about high performance animations, see this article.
To maximize browser support for your animations, especially on iOS devices, include the -webkit- prefix on the transform properties. Here’s an example:
-webkit-transform: rotate(30deg);
transform: rotate(30deg);For more information about compatibility you can refer to this chart
As a note, box shadows can sometimes make animations slow on mobile depending on how heavily they are used and what else is happening on the page. For box shadows, I recommend testing to see what you can get away with.
5. The Coordinates of a Touch Are Stored Differently the Coordinates of a Click
Fetching the coordinates of a touch event can be tricky because those coordinates can be stored in different places depending on the device. On some devices (such as iOS), you can find touch coordinates in the same place as click coordinates, but on other devices (such as Android), you have to look elsewhere. The good news is that touch coordinates can be found in the specialized touch event data of any mobile device you’d realistically need to support.
For touch events, use e.touches[0].pageX instead of e.pageX to fetch the x coordinate of that touch. Replace all instances of X with Y to fetch the y coordinate. Here are some examples so you can compare how this code looks in practice.
For a mouse click, you might fetch the coordinates like this:
document.onclick = function(e){
var x = e.pageX; // get x coordinate of click
var y = e.pageY; // get y coordinate of click
console.log('x = ' + x + ', y = ' + y); // show coordinates in console
}For a touch event, you can fetch the coordinates like this:
document.ontouchstart = function(e){
var x = e.touches[0].pageX; // get x coordinate of touch
var y = e.touches[0].pageY; // get y coordinate of touch
console.log('x = ' + x + ', y = ' + y); // show coordinates in console
}Even on devices where e.pageX and e.pageY don’t work, they’ll still be available, but they’ll be 0 for touch events no matter what. The reason I mention this is so that you won’t think checking for their existence is enough to ensure they actually work.
If you ever forget where to find the coordinates for an event, you can use the console to check it out. I suggest Chrome’s mobile emulator for this because it shows JavaScript objects in a readable way. Here’s the code to see what kind of data the ontouchstart event spits out:
document.ontouchstart = function(e){
console.log(e); // show data from ontouchstart event
}If you’re using jQuery events, be aware that they have their own set of data. You can see the differences with the following code:
$(document).on('touchstart', function(ev){
console.log(ev); // jQuery version of event data
console.log(ev.originalEvent); // native JavaScript version of event data
});Whether you are detecting the locations of mouse clicks or touches, the key point is to make sure you are accessing your coordinates properly. When in doubt, test it out.
Conclusion
We’ve covered some important mobile development pitfalls including unexpected font size changes, unwanted form styles, misleading emulator errors, choppy animations, and improper touch coordinate detection. Hopefully the information in this article will save you a lot of time and heartache.
If you have any questions or points to add, feel free to leave a comment.
Yaphi BerhanuYaphi Berhanu is a web developer who loves helping people boost their coding skills. He writes tips and tricks at http://simplestepscode.com. In his completely unbiased opinion, he suggests checking it out.
