HTMLBOY Javier Usobiaga, web designer & front-end developer.

Stop using the viewport meta tag (until you know how to use it)

In the early years, when the smartphones came to Earth, they knew the Internet wasn’t prepared for them… so they expected every website to be around 1000px width (980px on the iPhone) and zoom out the website to fit into the screen. And so the <meta name="viewport"> was created, basically to tell those smart dudes that your website was prepared for them.

Nowadays, some popular front-end frameworks like HTML5 Boilerplate, Twitter Bootstrap and other pre-made templates include this meta tag by default –which is great for responsive web design, but very harmful for “traditional” web design. This is how it works.

Briefly

If you are not coding a responsive site, just don’t use any meta viewport. If you are coding a responsive website, all you need to write is

<meta name="viewport" content="width=device-width, initial-scale=1">

Any additional parameters in the content attribute usually screw up user’s experience.

EDIT: As Brad Frost correctly pointed out, you should also use the viewport meta if you are building a dedicated mobile site, so it’s not just for responsive sites.

Device-width

The most important part of the viewport tag is telling the browser what’s the width of your website. If we code it like this:

<meta name="viewport" content="width=device-width">

we’ll be telling to the browser “my website adapts to your width”. If we use this parameter on a non-responsive site, the website will zoom to the top left corner, forcing the users to zoom out (just to understand where they are) and zoom in to the see the details. Not the best user experience, right?

Initial-scale

Since the browser tends to scale the website, this parameter sets the initial zoom level, which usually means that 1 CSS pixel is equal to 1 viewport pixel (which is not always the same as 1 physical pixel). A responsive site should work without this parameter, but it might help fixing some issues with certain browsers when changing the orientation mode, or preventing a default zooming.

Maximum-scale

Setting a maximum scale means setting a maximum zoom. On a website where the access to the information is the top priority (most, if not all, websites), setting a maximum-scale=1 won’t allow the user to zoom. This might seem unimportant if you have a responsive website, but there are lots of cases when the user might need to zoom: small body font (at least, for the user’s needs), checking some details in a photograph, etc. Don’t trigger an accessibility issue just for aesthetic reasons.

User-scalable=no

This parameter removes the ability to zoom in or zoom out, and it’s even worse than maximum-scale. If there’s a really special reason to use it (e.g., you are coding a web app and need to avoid zooming in form inputs), try adding and removing it with JavaScript, just for the action you want to fix. Anyway, remember that smartphone users are used to zoom in and out any website, so having to zoom out after filling a form might be a default behavior and you don’t probably have to fix it.

Combo breaker

Now picture the combo-breaker: a non responsive website (fixed layout, about 960px width) with a viewport tag like

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

Congratulations, your website zoomed to the first 300px or 400px of the top left corner, the user can’t zoom out and the only way to access the information is by patiently viewing the website in pieces of 300px width. A whole experience screwed up by an extra tag.

Just don’t use the viewport tag in vain

Lots of non-responsive websites are using the viewport tag without noticing how harmful it can be for the users, or they are using some of the viewport parameters “just because somebody copied and pasted them there”. Unfortunately, this is not an isolated case; as web designers and developers, we tend to rely too much on frameworks and templates, sometimes adding lots of extra code the website will use for nothing, and sometimes adding complex configuration lines the project doesn’t really need. It’s time to recover control over our websites: never add a line of code you don’t really understand, never add a line of code you don’t really need.