No bias in that title, right?

Generally I don't like the idea of denying the user standard browser/OS functionality. More often than I find appropriate I come across sites (including at my own workplace) that use the viewport meta tag to disable the user's ability to zoom the page. This is primarily a phone or tablet issue where screen space is limited.

I tend to include that tag as follows:

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

My thinking behind this is that I just want to ensure that my site is displayed in its default form more or less as designed and conceptualized. However I never want to pretend to know what viewing experience the user is most comfortable with.

I hear and read often that user-scalable=no or maximum-scale=1.0 is included so that the website is more 'native app-like'. Or that the page in question has been optimized for small screens and therefore zooming is not needed.I don't buy this, because 1. I have grandparents and have seen the size of the buttons on their landline phones, and 2. I think any good native app should also be zoomable. This got me interested in finding any other reasons for including this tag with the user-scalable or maximum-scale values.

I came across a few fairly quickly.

Possible Issues

  1. Pages with Google Maps or a similar component that have their own zoom functionality.

  2. Input field that has a font-size of less than 1rem when focused will be zoomed in until the font-size is 1rem. Upon leaving the field the display will not, however, be zoomed back out to its original state.

  3. Eliminate the 300ms (or so) click delay on touch devices.

  4. iOS problem with hover states. I've had this pop up from time to time and didn't know until reading the article below that it is only an issue when changing visibility states through visible or display. I think this is more of a design issue, as mentioned in the article as well.

    • A great explanation of the phenomenon by Nicholas C. Zakas, but nothing about user-scalable=no: iOS has a :hover problem

      Safari on iOS has an issue with :hover. If you apply :hover to a non-link that contains a link and also shows or hides and other element then you must twice to navigate. The first applies the changes for :hover while the second Actually does the navigation.

  5. Ensure that ads are visible in their entirety when on screen.

The last point is a huge can of worms, that I don't want to open up here and now.


I made two simple pens to test all but the last point. Each pen has text and search input fields, with a base font-size of 1rem. They also contain a google maps container that is bound to 500px x 500px or as a max, 50% of the viewport's height and 85% of its width of the viewport. Additionally there is a link with event listeners for touchstart and click. For the problem with the hover states I copied the code from the demo for the article I mentioned above. You can find the original demo here: An important note: Including the Google Maps v3 scripts on the page must manipulate the way the :hover state is handled, because without it my test for iOS :hover works as expected (double click necessary) but with maps only one click is neccessary. I guess to be completely scientific about this, I should break up every test point into its own pen and test again to ensure that components aren't having unexpected effects on each other. If this post generates any interest I will take the time to do this and post an update here.

Here are two pens, both with all of my little test cases. Be aware though, that not all tests will give the expected or in this article documented results because of factors like the Google Maps V3 script affecting click and hover state handling. For this reason I have also created 8 individual pens, each with one test.

This first pen is without user-scalable=no and the second with:

Here you can find all of the tests in one collection, seperated into individual tests: meta@user-scalable

I used the follwing devices and browsers to test:

  • iPhone 6 - Chrome, Safari
  • Nexus 5 - Chrome, Firefox
  • MacBook Pro - Chrome, Safari, Firefox
  • iPad Air 2 - Chrome, Safari
  • Windows 8 machine with touchscreen - Chrome, Firefox, IE11

On the iPhone ...

  • I found that although my simple handler for the touchstart event was not always run, when it was, the corresponding click event was delayed by approximately 400ms. This occured both with and without the scale meta values.
  • The input field was indeed zoomed as described without the meta values, but not when zoom was disabled. This occured in both Chrome and Safari.
  • I was able to zoom the Google Map as expected regardless of the meta values and could also zoom the page just fine when scalability was allowed.
  • In both Chrome and Safari I had the expected issue, but user-scalable=no didn't change anything.

Nexus 5 ...

  • Google Map interaction in Chrome and Firefox was identical to on the iPhone.
  • The view was never zoomed on input field focus.
  • Click delay was always less than 100ms ... so basically instant. This is what was aluded to in several of the sources noted above under point 3.
  • Firefox dealt with :hover in the same way that iPhone browsers do, but ALL elements that have :hover states, not only those that manipulate other elements' visibilities. Chome displayed no problems. A click led immediately to the expected navigation. This was made all the stranger by the results of another test I did where I changed this code:

        .hover4:hover span {

    to this

        .hover4 a:hover + span {

    This changed eliminated the problem on iOS devices (but from a design standpoint is probably not a solution. I'm think of nested list items that expand on parent level hovers). But it only seemed to worsen the situation in Firefox. After this change not only did I have to tap the link twice to navigate, but the text that was supposed to be set to display:inline never appeared.

iPad Air ...

  • Same Google Map interaction as everywhere else.
  • No input focus-based zooming.
  • Click delay of around 400ms.
  • Deals with :hover the same way as the iPhone does.


  • unsurprisingly the value of user-scalable didn't have any noticable effect on the test pages. In none my my test cases was I able to eliminate the user's ability to zoom by modifying the meta tag.

Mac (mouse interaction) ...

  • Normal Google Map interaction
  • No input focus-based zooming.
  • No click delay because I was not working with a touch based device.

Windows (touch and pointer (touchpad) interactions) ...

  • IE11 & 10 handled Google Maps zooming with touch gestures seperate from site zooming, just as on the tested mobile devices. IE9 did this to some extant as well, but the maps zoom was often delayed considerably. In Chrome and Firefox the map was not zoomable with touch interactions, but worked fine with my multi-gesture touchpad.
  • No input focus-based zooming. Strangely enough, when focusing on my simple input fields only Chrome opened the on-screen keyboard.
  • In Chrome the click delay was around 100ms, but the touchstart event did not seem to fire every time. In the other browsers this event didn't seem to be fired at all. Maybe the desktop browsers just don't fully support touch events, or possibly a different implementation. I'll have to read up on that, but seeing as it was not really the point of this test, I'll leave that for another day.


I wasn't able to detect any difference with regards to page and Google Maps zooming. Perhaps this was an issue with earlier browsers and or operating systems.

The input element zooming on focus is indeed affected by adding user-scalable and maximum-scale values. However, I personally feel that this alone is not enough of a reason to disable zooming altogether. I am rather extreme in my website design decisions and like to leave the base text for my content at the browser defined standard. I know that not many users venture into the browser settings to change this value, but some do, and those are the folks that need this flexibility the most. If you absolutely need your base font-size to be something like 12px, then I would encourage you to find a fix for it like those mentioned in the links describing the issue.

The logic behind the click delay seems to indeed have been changed by Firefox and Chrome. As mentioned in the linked articles and posts, it seems like they recognize a 'mobile-enhanced' page and handle events interaction events appropriately. The rest of the browser/os combinations showed no difference in click delay whether or not the user-scalable and maximum-scale values were set. Craig Buckler: 5 Ways to Prevent the 300ms Click Delay on Mobile Devices


My findings have strengthed my opinion that adding this property to the viewport meta tag is not a good design idea. I found only limited advantages and think that alternative solutions based on progressive enhancement or more accessibility-oriented design decisions (larger fonts perhaps) are better solutions than to eliminate a feature users may be accustomed to or even dependent upon.


a github repo I just came across that addresses the 300ms delay and its relationship to meta viewport values: FastClick