The next rules do some sizing on the buttons inside the first two cards, and give all card contents a top margin so that their content won't be lost under the navigation buttons (see below). This was necessary because Mozilla Brick (also see below) forces its components to be 100% of the screen width and height. We have used vw (viewport width) units for these — 1vw is equivalent to 1% of the viewport width. This makes the dimensions scale up and down nicely along with the viewport width. Last for this section, we absolutely positioned all buttons at the bottom of the cards they are in, so the layout looks OK at different viewport size variations. We then add a rule that postions the second button in any card a button's width higher up the card. When you click on an image in the gallery it brings up options to delete or cancel deletion of the card, and you don't want two buttons on top of one another.

x-card:nth-child(3) img {
width: 50%;
}

This rule simply changes the width of the gallery images so now there are two per line.

In this last set of rules, we change the display value of the <nav> to flex to make it show (it was set to none in the default CSS at the top of the stylesheet, as it wasn't needed for the other views.) We then use absolute positioning and z-index to make it take up no space in the document flow, and sit on top of the x-cards (this is why we gave the x-cards that top-margin earlier).

Next up, the font-size of the buttons is set to 6.8vw. Why? Because the top-margin of the x-cards was set to 17vw earlier on. All buttons in the app have been set to have a line-height of 2.5, in the default CSS at the top of the stylesheet (check if you don't believe me.) And 6.8 x 2.5 = 17.

Last, we have used flex: 1; to make the buttons always take up the same proportion of space on the line. Let's have a look at the mobile layout, in the below image.

But there are more tricks up our sleeves for this mobile app layout! As mentioned above, we used Mozilla Brick, a collection of ready-rolled mobile UI components, in the making of the mobile app layout. In particular, we used the deck component for the nice transition effect between cards when the buttons are pressed. For more on using Brick, read Mozilla Brick: ready made UI components.

What's more relevant to this article is that we didn't want the Brick CSS and JavaScript files being applied to the markup unless we were looking at the mobile app view. To achieve this, we applied the Brick CSS to the page using a separate <link> element with a media attribute:

This says that the whole stylesheet will not be linked to the HTML unless the viewport width is 480px or less. Moving on to the JavaScript, <script> elements don't accept media attributes, so I had to do this a different way. Fortunately there is a JavaScript construct called window.matchMedia(), which can conditionally run JavaScript constructs depending on whether a media query returns true or not. We opened up the brick.js file and wrapped the whole lot in the following:

This causes nothing inside the brick.js file to be run unless the viewport width is 480px or less. Problem solved.

Really wide screens

One thing you might notice is that when the viewport gets very wide (such as on a cinema display), the layout stops getting wider, and just centers in the space available. This is pretty simple to achieve. You could use a min-width media query to fix the <body> width at a certain point:

But it's actually easier to just set the following rule instead, and get rid of the media query altogether:

body {
max-width: 1400px;
margin: 0 auto;
}

Orientation fail

We also came across some problems with orientation: the mobile-app layout of our example app is designed for portrait orientation, and looks terrible when viewed on a device in landscape orientation. To fix this, we added in a media query that only applies its contents to the markup when device is viewed in landscape orientation:

Adjusts the nav buttons, changing the direction the flexbox is laid out in, and altering the font size and borders so they sit vertically instead of horizontally.

Removes the top margin from the x-card contents so you don't end up with an unsightly gap at the top of the screen in landscape mode.

Changes the sizing of the control buttons (e.g. Take Picture, Delete Photo) so they don't look too big and sit properly on the screen.

This results in the following layout:

Note: Another solution with respect to orientation might be to just lock the orientation of your app, to portrait or landscape. If you are working on a Firefox OS/installed app, you can easily do this with the orientation manifest field. If you want a solution that works across general web apps, you could use the Screen orientation API, and/or provide a message asking the user to rotate their screen if they are using the wrong orientation (for example, if window.innerWidth is larger than window.innerHeight, assume the
game is landscape mode and show a "please rotate" message.)

Viewport

One last problem to mention for our example app is concerned with mobile browsers and media queries. If we viewed my example in a mobile browser in its current state, we wouldn't see our nice mobile layout. Instead, we'd see the below image.

I'm sure you'll agree that this really isn't what we wanted — why is this happening? In short, mobile browsers lie. They don't render web pages at their true viewport width. Instead, they render pages at a higher assumed viewport width (something approaching a laptop screen), and then shrink the result down to fit inside the mobile screen. This is a sensible defensive mechanism — most old school sites that don't have media queries would look terrible when rendered at say, 320px or 480px wide. But this doesn't help us responsible web developers, who have written small screen layouts into our CSS using media queries and want mobile devices to display those!

There is a way to override this mobile rendering behavior — viewport, which is inserted into our HTML pages in the form of a <meta> tag. In my example, let's add the following into our HTML <head>:

<meta name="viewport" content="width=480">

This causes our browser to render our mobile app layout properly — width=480 tells the browser "render this markup at 480 pixels wide", hence the media queries kick in appropriately. There are many more options available in the viewport meta tag, which you can read about in Using the viewport meta tag to control layout on mobile browsers.

Note: There is a spec called device adaptation, which defines the same functionality but in CSS, using a @viewport at-rule. This is probably a more logical place to put such information, but the spec is not as well supported as the viewport meta tag, therefore you should stick with that for now.

Responsive images/video

Another problem that comes up more and more these days is making image/video weight (size in KB) responsive as well as the dimensions of the image on screen. Yes, you want the images to be contained inside the app UI whether you are using it on desktop or mobile, but you should also consider that mobile apps have much smaller viewport dimensions available than desktop apps, so you should try to give mobile devices a smaller image to download. Mobiles in general (more commonly in some parts of the world than others) are on lower bandwidth connections and have less memory available than desktop devices, so yes, those extra kilobytes really do count.

Another challenge is dealing with high resolution screens — raster graphics designed for low resolutions are in danger of appearing tiny when displayed on a high resolution screen, so devices often apply a default zoom factor to rendered pages to avoid this. The trouble with this, then, is that raster images are zoomed in and as a result can start to look pixellated.

CSS background images

For CSS background images this is a fairly easy problem to solve. If you use the mobile first methodology, you will be creating your mobile layout inside your default CSS, before any media queries have been applied. The media queries then supply CSS that is only applied to the markup when the viewport is above a certain width. Let's look at a quick example:

This means that mobile browsers only download the mobile background image asset — not the desktop mobile assets — because they fail the media query tests and therefore ignore the media queries. You can also serve a larger graphic to a higher resolution device using a resolution media query, like so:

This looks rather complicated, but really it's not — we are providing a number of media query options, as at this time different browsers support different resolution media query types and even units. Brett Jankord has a good explanation at Cross Browser Retina/High Resolution Media Queries.

<video>

HTML5 video is fairly well catered for in terms of responsive capabilities. If you wish, you can point to multiple video files via <source> attributes, each with their own source and MIME type:

But you can go one step further. You can include media attributes on the <source> element containing media queries — the video loaded in the browser will depend on both the format the browser supports, and the results of the media tests. So for example:

This allows your site to serve different video files based on the available space, in order to optimize the user's experience.

<img>

HTML images are a more difficult proposition. There is no mechanism inherent in HTML images for serving different image files dependent on viewport size, and, due to a number of irksome browser behavior realities, solutions are more difficult to hack together than you would imagine. There are currently some standards proposals in the works that would provide this — the W3C responsive images community group discussed this problem for ages and arrived at the <picture> element, which provides a similar markup structure to <video>, with <source> alternatives selectable via media query results. Another proposal, srcset, was put forward by Apple and takes a slightly different approach, instead providing a new srcset attribute for <img> inside which image references are placed along with "hints" that the browser can use to work out which image is most suitable to display given its viewport size, resolution, etc. These are not intended to be mutually exclusive.

This all sounds good. But those solutions are definitely not ready for production yet — both are in a very early stage of standardization, and have no support across browsers. Currently we have to rely on various polyfills and other solutions, none of which are perfect for all situations, so you need to decide which one is right for your particular situation. Some available solutions are as follows:

A very clever technique from Mozilla that allows you to capture the source of the page before it's parsed. This way, you can swap out image src values with JavaScript depending on browser features, circumventing browser preloading issues. This is promising, but doesn't work very well across older browsers.

A server-side solution, which records the viewport size in a cookie, then resizes images via a combination of PHP and .htaccess to a more appropriate size, if appropriate. This doesn't require markup or scripting, but has a number of limitations.

SVG and other vector graphics

For some image requirements (not photographs, but icons and user interface elements are a good fit), a good solution is to use vector graphics. Because vector images are calculated based on mathematical algorithms rather than containing separate data on every pixel in the image, they tend to be smaller in file size, and are infinitely scalable when zoomed or viewed on high resolution devices (at least, in theory). Some ideas follow, which also help to keep the number of HTTP requests down — another key factor in mobile app performance:

You should try to use CSS3 features to programmatically generate graphical effects where possible, rather than relying on image files. these include rounded corners, gradients, and drop shadows. These will scale as the resolution changes or the browser zooms, and although they are not supported very well on older browsers such as Internet Explorer 6-8, this is not too much of a concern when you are creating an interface aimed at modern devices such as Firefox OS, and they also tend to gracefully degrade.

You could also try using SVG to create interface elements. SVG produces vector graphics and is supported well across modern browsers, with polyfills available for older browser support.

Using Web fonts for displaying icons is an effective technique for keeping file size and HTTP requests down, and this is supported well across modern and older browsers.