Changing the Layout for Mobile Devices CSS3

If you got very zealous in resizing your window to test the narrowscreen styles, you may have noticed that—even with the changes we made—the layout doesn’t look very good at extremely narrow widths like the ones you find on mobile devices. Well, there’s only one thing to be done: add another media query!

Media queries are a great way to customize the styles on mobile devices quickly and easily. But please be aware that we were not suggesting they’re the only way you should deal with mobile sites; you may need to add server-side scripting or other techniques to change the content and functionality on the mobile version of your site. While media queries may be enough customization for the mobile version of a small business’s brochure site (such as our example bakery site), a big, complicated news site probably needs to use additional techniques to significantly change the content, navigation, and other functionality on their mobile site. Plus, hiding or swapping in different content extensively using media queries is not efficient—the browser may still download the content it doesn’t need. So don’t think media queries are necessarily going to solve all your mobile web design problems—use media queries as one of your mobile optimization tools.

When adding a mobile media query, what size should you target?
Mobile phone screen sizes vary dramatically, but many of the most popular phones—including iPhones and many Android phones—have screens that are 320 by 480 pixels wide. Screens on other phones are rarely larger than this. But the design of our bakery page starts to break down around 550 pixels. So let’s use 550 as the width to target with our third media query, which will work in 320 by 480 mobile phones as well as mobile phones with slightly larger screens.

Before we add this media query, however, let’s talk a bit about device width.

What is Device Width?

One of the media features you can use in media queries is called device-width, along with min-device-width and max-device-width.

Device width refers to the number of pixels available across the actual device or display, rather than within the viewport. This means that a desktop computer with its screen resolution set to 1280 by 800 has a device width of 1280 pixels. When you target device-width in your media queries, browsers ignore the size of the user’s browser window and instead pay attention to the user’s screen resolution.

Mobile phones generally don’t use windows—the “window” is always the same size as the entire screen, so the idea of a viewport, as we traditionally think of it, doesn’t really fit. Device width seems more relevant.

But there’s a little catch. Apple doesn’t always make its products’ device-width equal to the number of pixels available across the width of the screen, as most other phones do. iPhones before version 4 and iPod Touches, though they both have screen sizes of 320 by 480 pixels, always have Mobile Safari report that the device width is 320 pixels, even when the user is viewing the device in landscape mode and is seeing 480 pixels of width. iPads work the same way—the device width is always reported as 768 pixels, despite the orientation of the iPad. This is even more confusing in the iPhone 4, which has a highresolution screen of 640 by 960 pixels, but reports its device width as 320 pixels.

This doesn’t mean you can’t or shouldn’t use device-width, but it does mean that you may find it more intuitive to use min-width and max-width instead of min-device-width and max-device-width. They both work the same way on mobile phones; the main difference is whether or not each applies on non-mobile devices too. For instance, a media query targeting a max-width of 550 pixels will apply to both mobile devices with screens under 551 pixels and desktop browser windows narrower than 551 pixels. But a media query targeting a max-device-width of 550 pixels has almost no chance of applying to anything other than mobile devices—We don’t think there are many desktop computers with screen resolutions under 551 pixels wide! So neither one is inherently better or worse than the other—they’re just different options that you can choose between depending on what you’re trying to target.

The Third Media Query

Let’s add the third media query now to apply to windows up to 550 pixels wide:

Make sure you add this beneath the second media query (the one targeting a maximum width of 760 pixels). That’s because the second media query applies to mobile devices as well—a mobile device with a 480-pixel-wide screen is under the maximum width of 760 pixels. If you put the 550-pixel media query before the 760-pixel media query, the 760 one would override the styles in the 550 one. This is just how the CSS cascade works—rules that come later override rules of the same specificity that were declared earlier.

If you didn’t want the two media queries to overlap, you could add a minimum width onto the 760-pixel media query, such as:
@media screen and (min-width: 551px) and (max-width: 760px)

This media query would apply only to windows between 551–760 pixels, not to mobile devices under 551 pixels wide. This might be good or bad, depending on your particular project. In our case, it would mean repeating a lot of the rules from the 760-pixel media query in the 550-pixel one, since we want a lot of the styles to be the same in both. For instance, we want the intro paragraph to have only one column of text in both the 550- pixel layout and the 760-pixel layout. When these two media queries overlap, we only have to declare the one column in the 760-pixel media query, and then it will also apply to windows under 550 pixels.

In our example page, overlapping the media queries lets us reuse several styles and keep our CSS more streamlined. On other sites, however, you may want very different styles at each width, so it may make more sense to not let your media queries overlap. Keeping them separate may also be less confusing for you, as you don’t have to keep track of the cascade. Again, there’s no right or wrong answer here—it all depends on what you’re trying to accomplish.

In this case, we’re going to leave the 760-pixel media query as it is, and make sure the 550-pixel media query comes below it so that both apply to windows under 551 pixels wide.

REMOVING FLOATS

The primary change we need to make to the mobile design of the site is getting rid of the floats so that the entire page is one column. Most mobile web pages are a single column—there’s simply not enough room for columns to sit side by side on those little screens.

Add the following rules to the third media query:


Now the sidebar column displays under the main content column, and the “Credits” block in the footer displays under the “About” block . The top margin added to the credits div keeps the blocks in the footer spaced out from each other.

The layout is all one column now in extremely narrow mobile viewports.

The layout is all one column now in extremely narrow mobile viewports.

The layout is all one column now in extremely narrow mobile viewports.

REDUCING HEIGHTS

Another useful change to make to many mobile pages is to reduce the vertical space that elements take up, reducing the amount that users have to scroll down the long single column.

The text in the tagline and introductory paragraph doesn’t need to be quite so large when viewed up close on a mobile device, so you can reduce both font sizes by creating new h1 and h1 + p


Making the introductory text smaller reduces the need for so much scrolling in tiny mobile screens.

Making the introductory text smaller reduces the need for so much scrolling in tiny mobile screens.

Working our way further down the page, you’ll see that the product icons look rather large in the context of such a narrow window, and the text beside them could use more room. Luckily, the Yummy icon set we have used for the illustrations came in three sizes: 128 pixels, 64 pixels, and 48 pixels. We can switch the background images to the 64-pixel size in our mobile media query:


Now the featured products area takes up less overall height and looks more balanced .

Reducing the size of the icons in the featured products area makes them look more balanced against the blocks of text in narrow widths.

Reducing the size of the icons in the featured products area makes them look more balanced against the blocks of text in narrow widths

Next, check out the email newsletter subscription block. The text field within it takes up its full width, but there’s now room to display the label text and button on the same line as the text field, at least on larger mobile screens. Add these rules to the media query:

These changes tighten up the newsletter block’s appearance (Figure below). In portrait-oriented mobile screens, the subscribe button will drop down to a second line, but even then the form still makes better use of the space overall.

Finally, we can make a small change in the footer to slightly reduce its height. Float the dt elements within the credits div, since there’s room to show the label text, like “Web Fonts,” next to the description text, like “Nadia Serif from Kernest”:

PREVENTING OVERLAPPING HEADER ELEMENTS

In small mobile screens, the possibility of page elements overlapping each other is of course increased. You can see this problem in the header of our example page. With the viewport at 550 pixels wide, the search form fits fine beside the logo, but at around 400 pixels they start to overlap. If the user has a larger text size, the overlap will happen even sooner.

To reduce the chance of overlap, reduce the width of the text field in the search form by adding this rule to the third media query:

The form elements in the newsletter subscription block now all display on the same line in landscapeoriented mobile screens.

The form elements in the newsletter subscription block now all display on the same line in landscapeoriented mobile screens.

With each credit label and description on a single line, the Credits block in the footer takes up less space.

With each credit label and description on a single line, the Credits block in the footer takes up less space.

Next, add a fourth media query below the 550-pixel one. This media query will target windows less than 401 pixels wide:

Add a rule within this media query to make the label in the search form display as a block-level element so it will sit on a line above the text field:

Now the search form takes up less width at both 550 pixels wide and 400 pixels wide, and it’s not likely to overlap the logo even in 320- pixel wide mobile phone screens .

The search form now also takes up less space, so it’s less likely to overlap the logo in small mobile screens such as 480 pixels wide (left) and 320 pixels wide (right).

The search form now also takes up less space, so it’s less likely to overlap the logo in small mobile screens such as 480 pixels wide (left) and 320 pixels wide (right).

Improving the Look on Highresolution Displays
The iPhone 4 has a new type of screen called a “retina display” that is higher resolution than that on previous versions of the iPhone and iPod Touch. Its resolution is 640 by 960, but it displays the same area as older iPhones because it uses two device pixels for every one CSS pixel. This means it doubles up the pixels it uses to display each pixel you declare in your CSS—this is what makes it high resolution, and this is why its device width is still 320 (half of 640).

For the most part, you’ll want all versions of the iPhone to have the same styles, but you may want to take advantage of the retina display by feeding higher resolution images to the iPhone 4. For instance, our three product icons look a little pixelated compared to the razorsharp text seen on a retina display.

To target the iPhone 4, you can set -webkit-min-device-pixel-ratio, one of Webkit’s proprietary media features, to 2:

This makes the media query apply only when the phone’s device-to- CSS pixel ratio is two to one—like on the iPhone 4. Right now, this is the only device the media query will apply to, but other Apple devices may have retina displays in the future. So to make this media query more future-proof, add another condition onto the media feature to make it apply only to the small screen of the iPhone 4:

Now we can feed larger images to the iPhone 4, and then shrink them using the background-size property, to effectively squeeze more pixels into the same amount of space. Add these rules inside the new media query:

These images are twice as big—128 pixels by 128 pixels—as the size we really want them to display at: 64 pixels by 64 pixels. When they’re shrunk down to 64 pixels using background-size, a normal browser now has twice as many pixels as it needs to display those 64-pixelsworth of image. So when the iPhone 4 doubles each pixel, it already has two pixels there to display, instead of having to make a single pixel of the image twice as large, which would result in blurriness.

The images now look sharp.
This is only one of the changes we could make on the iPhone 4. For more ideas on how to take advantage of its high-resolution display, see “Designing for the Retina Display (326ppi)” by Luke Wroblewski.

The Viewport meta Tag
If you save and test the page at this point in a desktop browser, it will work just as you expect it to as you narrow the window. But if you load it up on a smartphone like an iPhone or Android device, you may be surprised to find that none of the media queries are taking effect.

The page will display with the normal styles, showing a two-column layout that’s been zoomed out .

The page displays with a wide, two-column layout in many mobile devices, instead of using the styles from the third media query.

The page displays with a wide, two-column layout in many mobile devices, instead of using the styles from the third media query.

This is because many smartphones use a virtual viewport that’s larger than the actual screen size in order to not destroy all those web pages out there that weren’t designed for mobile by squeezing them into a tiny 320-pixel-wide viewport. The mobile web development expert Peter-Paul Koch calls this virtual viewport the “layout viewport” and the actual viewable area the “visual viewport.”

When you load a page on a mobile phone that uses a layout viewport, the mobile browser will zoom out to the maximum level so that the entire layout viewport fits on screen. This makes everything appear tiny, but it ensures that your layout looks the same as it does on a typical desktop browser. Different mobile browsers use different widths for the layout viewport—Mobile Safari on the iPhone and iPod Touch uses 980 pixels, Android Webkit uses 800 pixels, Opera uses 850 pixels— but the point is that the mobile phones are pretending they have larger screens than they do, when sometimes you want them to fess up and show only the number of pixels they truly have.

Luckily, there’s a specific meta tag whose whole purpose is to tell the mobile browsers that you’ve optimized your site for them and let you adjust the size and zoom level of the layout viewport.

HOW IT WORKS
This mobile-optimized tag is called the viewport meta tag, as you set the name attribute’s value to viewport. It looks like this:

<meta name=”viewport” content=””>

Inside the content attribute, you include whatever instructions you want to provide about how to handle the viewport. Table below shows the possible properties you can include in the content attribute.

content attribute properties for the viewport meta tag

content attribute properties for the viewport meta tag

The viewport meta tag was invented by Apple and is not yet a standard.
However, many mobile browsers beyond iPhones support it.

ADDING IT TO THE PAGE
Let’s add a viewport meta tag to the bakery page now. Add the following tag to the head of the page:

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

This tells the mobile browser that you want it to make the size of the layout viewport equal to the device width, or the size of the screen.

If you save your page and view it on an iPhone or similar device now, you will see that the mobile browser is showing only 320 pixels of width to display the layout in, allowing our media query to take effect.

With the viewport meta tag added, the iPhone shows only 320 pixels across the screen, instead of zooming out to show 980.

With the viewport meta tag added, the iPhone shows only 320 pixels across the screen, instead of zooming out to show 980.

However, if you rotate the iPhone to landscape orientation, the page still displays in 320 pixels, not 480. Mobile Safari simply zooms in on it instead of changing the size of the layout viewport, making the logo and other images a little blurry .

In landscape mode, the iPhone still shows only 320 pixels, zooming in so it fills the 480 pixels of width available.

In landscape mode, the iPhone still shows only 320 pixels, zooming in so it fills the 480 pixels of width available.

This is because the reported device width on iPhones and iPod Touches is 320 pixels in both portrait and landscape, remember? To get Mobile Safari to make the layout viewport 480 pixels in landscape mode, you need to stop it from zooming in on the 320 pixels to fill the screen. Setting the maximum-scale value to 1.0 keeps the browser (and user) from being able to zoom in past the true size of the page, so add it to the meta tag:

Now when you view the page in landscape, Mobile Safari will keep the same zoom level of 100 percent, forcing it to expand the layout viewport to 480 pixels to fill the screen .

Changing the maximum-scale of the viewport meta tag forces the iPhone to expand the layout to 480 pixels in landscape mode.

Changing the maximum-scale of the viewport meta tag forces the iPhone to expand the layout to 480 pixels in landscape mode.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

CSS3 Topics