Controlling the Mobile View-port for your web Applications

  • Share this:
Controlling the Mobile View-port for your web Applications

In this article, We are going to learn about how to control the Mobile view-ports and how your content should display on mobile screens in order to maintain a better responsive design for your website.

Perhaps the most confusing aspect of mobile displays is the concept of the Mobile view-ports.

To understand that, we first have to understand what the Mobile view-port is and how it relates to the mobile screen.

A simple Example

So, for your understanding, Let’s take an example of a smart phone of 320 x 480 pixels, meaning that the screen is 320 pixels wide when in portrait mode.So when we browse to a site that hasn’t been optimized for mobile screens, the entire site is scaled to fit itself into the 320 pixels worth of space, even though it was design for a much wider screen resolution. To read a site like this, the user needs to zoom up and then aim to the areas of the page that they want to read.

So what’s going on here, and why is this the default approach for most mobile devices?

But When we’re browsing on a desktop device, the concept of the view-port becomes a little more obvious, as any open browser window is defined as the view-port. Because the view-port is independent of the screen, we can resize it to whatever size we want. On mobile devices, the view-port functions in much the same way. It gives you a defined area to display web pages that is independent of the device’s screen. It’s simply not as obvious as the desktop view-port, and users don’t actually resize the view-port as much as they scale it up or down when they zoom in and out of web pages.

Since view-ports have a minimum scaling factor, users rarely ever see their edges as they do when they resize floating browser windows. Because of the small size of mobile screens, mobile view-ports are designed to be larger than the screen’s resolution.

Another Example of Mobile Browsers

For instance Mobile Safari has a view-port of 980 pixels, while Opera’s is around 850 pixels. When you compare that to an iPhone with a screen width of 320 pixels, you can see that the view-port is much larger than the actual screen itself. This is due to mobile view-ports having to display content that’s designed for much wider screens. Typically, mobile browsers will display a web page within the view-port and then shrink that view-port down until the content fits within the width of the screen itself. While this usually results in tiny pages, it does allow the user to see the page in its entirety and decide which areas of the page they’d like to zoom up to, and read. If mobile browsers didn’t behave this way, you’d only be able to see a small portion of most web pages.

This would be much more confusing as you’d have to pan around the page to explore its content without really knowing where anything was. This has been described as keyhole browsing, as it’s similar to viewing an entire room through a small keyhole. So, while the default view-port scaling is helpful for users browsing sites designed for larger screens, it can make it extremely frustrating when browsing pages that are designed specifically for mobile screen sizes.

Let’s say that you’ve created a responsive design that has a mobile phone layout designed for 320 pixels.

On an iPhone, the default mobile view-port is 980 pixels, so your 320-pixel layout is only going to occupy about a third of that. The view-port will then be scaled down to fit the 320-pixel screen, making your layout really tiny and defeating your carefully crafted 320-pixel layout. So, in order to build responsive sites that fit neatly within mobile screen sizes, you’ll need to know how to control both the view-port size and its initial scale factor.

Now that i’m pretty much sure that you have a clear picture of what the mobile view-port is, now we need to discuss how to control them.

So, without wasting more time, let’s discuss on how to control the mobile view-ports.

Generally, there are two mechanisms available for overriding the User Agent’s default view-ports, which are.

Viewport meta tag

@ view-port CSS Rule

Since they both use similar syntax, We are going to explore their code examples , and then describe their effects on the view-port.

Viewport meta tag

The meta view-ports tag appears in the head of your HTML, and has two basic parts: name, which is view-port , and content, which will contain the properties and values you wish to set for the view-port itself.

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

@viewport CSS Rule

The @viewport rule can appear anywhere in your CSS that you want, but since it can affect media queries, it’s recommended that you place it prior to any media queries in your styles. Most designers place it near the top of their styles. The syntax is similar to the meta view-port tag. You simply declare an @viewport rule and then populate it with the properties that you wish to control.

@viewport {

So, Now that we have the basics of the syntax down, let’s examine the individual properties that you can control.

Let’s look at another Example, where we will see how a simple web page would look with and without the view-port.

without viewport
with viewport

As we have set the view-port properties, we’ll examine the site optimized for mobile screen sizes to see how the mobile browser reacts to changes to its default view-port.

Syntax differences between both Approaches

Note that in the view-port meta tag syntax, we don’t append PX to the pixel value, while in the @viewport CSS syntax you do. While a specific pixel value for width might be fine for some projects, remember that not all mobile screens are 320 pixels wide.

If your website is using a fluid layout, you’re going to want the layout to be based on the available screen width of the device and not limit the view-port to just one single size. To do that, we can use the property value device-width.

Using the meta tag

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

Using the CSS rule

@viewport {
 width: device-width;

This value instructs the browser to set the view-port to the exact size as the available screen pixels. Setting this will remove any initial view-port scaling and allows you to create fluid layout that will adapt to multiple devices.

As you can set width, you can also set the height of the view-port, to either a specific value or by using the value device-height using the similar approach.

You probably won’t need a control view-port height all that often, but you should know that the capability exists if you need it.

You can also set the initial-scale value for the property’s content as well. It’s easy to get this property confused with view-port width, so let’s talk about exactly what it does.

What exactly is Initial-scale for?

Initial-scale controls the zoom factor of your content for the initial view of the page.Once the page has been viewed, the user is then free to scale the page at any factor they want.Now, it’s important to note that this is independent of the view-port width.

So if the initial-scale is set to 2, notice that our content is now scaled up to 200%, even though the width of the view-port remains unchanged. Setting the initial scale to 1 ensures that the content appears at 100%, regardless of the view-port width.

It’s quite common to see people set width to device width and then also set initial scale to 1, but in reality that’s not really necessary. If you set the view-port width to the device width, the browser automatically sets initial scale to 100%. So, it’s advisable to leave initial-scale off entirely unless you need to set the value other than 100%.

In terms of syntax,meta view-port tag use an integer to set the scaling factor, while @viewport uses zoom. The @viewport syntax currently also allows a percentage value as well, but since that may change in the future, you’re safer just using a number.

You can also control the range of scaling allowed by your site as well. Let’s say you want to allow people to zoom in and out on your page content, but you do want to control just how much zooming they can do. By using the minimum and maximum scale properties, you can do just that.

Now, if we set up the minimum scaling to 1 and the maximum scaling to 2. Now the user can scale up to 200% but can’t scale down pass 100%. In terms of syntax, there is a little bit of difference between the meta view-port tag and the @viewport syntax.

In the meta view-port tag, you’ll use the minimum and maximum scale properties and a positive numeric value, which indicates the scaling factor. In the @viewport syntax, you’ll use the minimum and maximum zoom properties, and can use either a positive number or a percentage value.

If you wish, you can turn scaling off entirely by using the user-scalable property. This allows you to either enable or disable user’s ability to zoom in and out on your page content, and is more commonly used actually for applications than websites.

For the meta view-port tag syntax, you’ll use user- scalable and values of either yes or no, and for @viewport, you’ll use the user-zoom property which will accept either the zoom or fixed values.

Keep in mind that users are accustomed to having the ability to zoom in and out of web content.If you disable this for your site, you should have a clear and compelling reason to do so. These are just a few of the properties you can control when overriding a browser’s default view-port.


Now, it’s important to note that support for the meta view-port tag is almost universal, while the @viewport syntax is still relatively new and largely unsupported for now. Existing support for the @viewport rule is also largely restricted to using vendor prefixes, so you’ll need to be mindful of that if you choose to use that syntax.

Adoption of @viewport is happening fairly rapidly, and the specification is maturing, so I expect we’ll see full support for it in the very near future. Once this happens, we’ll be able to choose exactly how we want to control user agent’s view-ports when creating responsive designs.

If you liked my article, please don’t forget to click on the heart button below or if you have any questions, feel free to ask. You can also follow me on Twitter.

Usama Muneer

Usama Muneer

A web enthusiastic, self-motivated & detail-oriented professional Full-Stack Web Developer from Karachi, Pakistan with experience in developing applications using JavaScript, WordPress & Laravel specifically. Loves to write on different web technologies with an equally useful skill to make some sense out of it.