On the desktop, Viewport is the screen size of the window in a browser. For example, when we resize the browser window, we are actually changing the Viewport size.

On mobile devices, the Viewport size is also independent of the device screen size. For example, Viewport is 850 px for mobile Opera and 980 px for mobile Safari, and the screen size for iPhone is 320 px.

If we compare the Viewport size of 980 px and the screen size of an iPhone of 320px, we can see that Viewport is bigger than the screen size. This is because mobile browsers function differently. They first load the page into Viewport, and then they resize it to the device's screen size. This is why we are able to see the whole page on the mobile device.

If the mobile browsers had Viewport the same as the screen size (320 px), we would be able to see only a part of the page on the mobile device.

In the following screenshot, we can see the table with the list of Viewport sizes for some iPhone models:

We can control Viewport with CSS:

@viewport {width: device-width;}

Or, we can control it with the meta tag:

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

In the preceding code, we are matching the Viewport width with the device width.

Because the Viewport meta tag approach is more widely adopted, as it was first used on iOS and the @viewport approach was not supported by some browsers in this book, we will use the meta tag approach.

We are setting the Viewport width in order to match our web content with our mobile content, as we want to make sure that our web content looks good on a mobile device as well.

Scaling is extremely important, as the initial scale controls the zoom aspect of the content for the initial look of the page. For example, if the initial scale is set to 3, the content will be loaded in the size of 3 times of the Viewport size, which means 3 times zoom. Here is the look of the screenshot for initial scale=1 and initial scale=3:

As we can see from the preceding screenshots, on the initial scale 3 (three times zoom), the logo image takes the bigger part of the screen.

It is important to note that this is just the initial scale, which means that the user can zoom in and zoom out later, if they want to.

Here is the example of the code with the initial scale:

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

In this example, we have used the maximum-scale=1 option, which means that the user will not be able to use the zoom here. We should avoid using the maximum-scale property because of accessibility issues. If we forbid zooming on our pages, users with visual problems will not be able to see the content properly.

The screen density

As the screen technology is going forward every year or even faster than that, we have to consider the screen density aspect as well. Screen density is the number of pixels that are contained within a screen area. This means that if the screen density is higher, we can have more details, in this case, pixels in the same area.

There are two measurements that are usually used for this, dots per inch (DPI) and pixels per inch (PPI). DPI means how many drops a printer can place in an inch of a space. PPI is the number of pixels we can have in one inch of the screen. If we go back to the preceding screenshot with the table where we are showing Viewports and densities and compare the values of iPhone 3G and iPhone 4S, we will see that the screen size stayed the same at 3.5 inch, Viewport stayed the same at 320 px, but the screen density has doubled, from 163 dpi to 326 dpi , which means that the screen resolution also has doubled from 320*480 to 640*960. The screen density is very relevant to RWD, as newer devices have bigger densities and we should do our best to cover as many densities as we can in order to provide a better experience for end users.

Pixels' density matters more than the resolution or screen size, because more pixels is equal to sharper display.

There are topics that need to be taken into consideration, such as hardware, reference pixels, and the device-pixel-ratio, which we will not cover here, as it's out of the scope of this book.

Scalable vector graphics and CSS graphics will scale to the resolution.

This is why we will use Font Awesome icons in our project. Font Awesome icons are available for download at http://fortawesome.github.io/Font-Awesome/icons/.

Font Icons is a font that is made up of symbols, icons, or pictograms (whatever you prefer to call them) that you can use in a webpage just like a font. They can be instantly customized—size, drop, shadow, or anything you want can be done with the power of CSS.

The real problem triggered by the change in the screen density is images, as for high-density screens, we should provide higher resolution images.

There are several ways through which we can approach this problem:

As this book covers only the essentials, we will use the second approach, providing high-resolution images where appropriate.

Media queries are CSS modules, or as some people like to say, just a conditional statement, which tells the browsers to use a specific type of style, depending on the size of the screen and other factors, such as print (specific styles for print). They are here for a long time already, as I was using different styles for print in 2002.

Here is an example of media query declaration:

@media only screen and (min-width:500px) {
  font-family: sans-serif;
}

Let's explain the preceding code.

The "@media" code means that it is a media type declaration.

The "screen and" part of the query is an expression or condition (in this case, it means only screen and no print).

The following conditional statement means that everything above 500 px will have the font family of sans serif:

(min-width:500px) {
  font-family: sans-serif;
}

Here is another example of a media query declaration:

@media only screen and (min-width: 500px), screen and (orientation: portrait) {
  font-family: sans-serif;
}

In this case, if we have two statements and if one of the statements is true, the entire declaration is applied (either everything above 500 px or the portrait orientation will be applied to the screen)

As some older browsers don't support media queries, we will use a respond.js script, which will "patch" support for them.

Polyfill (or polyfiller) is code that provides features that are not built or supported by some web browsers. For example, a number of HTML5 features are not supported by older versions of IE (older than 8 or 9), but these features can be used if polyfill is installed on the web page. This means that if the developer wants to use these features, he/she can just include that polyfill library and these features will work in older browsers.

@media only screen and (max-width: 480px) {
  //mobile styles
  // up to 480px size
}

@media only screen and (min-width:481px) and (max-width: 768px) {
  //tablet styles
  //between 481 and 768px
}

@media only screen and (min-width:769px) {
  //desktop styles
  //from 769px and up
}

@media only screen and (max-width: 30em) {
  //mobile styles
  // up to 480px size
}

@media only screen and (min-width:30em) and (max-width: 48em) {
  //tablet styles
  //between 481 and 768px
}

@media only screen and (min-width:48em) {
  //desktop styles
  //from 769px and up
}

The major point in RWD is that the content should adapt to any screen it's viewed on. One of the best solutions to do this is to use fluid layouts where our content can be resized on each breakpoint.

Reference: http://www.1stwebdesigner.com/tutorials/fluid-grids-in-responsive-design/.

To make the grid flexible (or elastic), we can use the % points, or we can use the em values, whichever suits us better. We can make our own fluid grids, or we can use grid frameworks. As there are so many frameworks available, I would recommend that you use the existing framework rather than building your own.

Grid frameworks could use a single grid that covers various screen sizes, or we can have multiple grids for each of the break points or screen size categories, such as mobiles, tablets, and desktops.

Last but not the least important, are images and media (videos). The problem with them is that they are elements that come with fixed sizes. There are several approaches to fix this:

We will tackle this quest in more detail in Chapter 7, Working with Images and Videos.

Before we begin with any coding, we need to make sure that we set up our development environment. There are numerous ways we can do it, but my preference is to have:

I perform autosyncing to my server because my local environment is Windows and my server environment is Linux (CentOS). Through many years of development, I've seen many times that local and server environment differences can cause a lot of headache, so I try to test the code on both while I am working.

In order to make your life easier, I would recommend that you download the PHP development environments. For Windows, there are three PHP development environments that I highly recommend:

These packages will install and configure Apache, Mysql, and PHP automatically for you. Only Bitnami will install WordPress for you as well. All of them are pretty good and the choice just depends on your preference. I use XAMPP as I am used to it.

For Mac OS X, I recommend:

I was using MAMP on Mac OS X and had no issues. MAMP Pro is even better, as it provides more options to make our life easier, and it is well worth the investment. When these packages are installed, WordPress should be downloaded from http:/www.wordpress.org/download/. After it is downloaded, WordPress should be unpacked (unzipped) and placed in web server's public directory with the project name; in my case, on Windows with XAMPP installed, this is C:\xampp\htdocs\topcat.

After WordPress is installed, our _s or underscores starter theme should be downloaded and installed.

Underscores (_s) is the starter theme for WordPress. It has been created by the people from Automattic (the company that stands behind WordPress) and numerous contributors. Why is this theme so good? It is good because it follows all the rules from WordPress.org, and it really makes our lives easier, as we don't have to start developing the theme from scratch. There are a number of starter themes that can be used for the projects, and I have closed this one as it's really popular and has a lot of features implemented (page templates, customizer, layouts, and languages) in order to make our lives easier.

If you are an inexperienced developer and you want to follow me from now on, I suggest that you go and download the same version of the theme as the one I downloaded from: https://github.com/dejanmarkovic/topcat_start. Make sure that the theme directory is named topcat and not topcat_start. If you want to start with the finished code, then please download this version from: https://github.com/dejanmarkovic/topcat. On the other hand, if you prefer to start with the latest _s version (at your own risk, as the code might change a lot further in this book), you can download it from https://github.com/Automattic/_s/, or from here http://underscores.me/.

Now let's get started:

Unit test data fills the WordPress database with sample posts, pages and comments spanning across different post types, image sizes, tags, and categories. It makes our lives easier while developing the theme, as we don't have to add all that content ourselves and we are sure when we test the code of our theme with all that content loaded that we will be able to see if something breaks.

We can test the features of our theme by using the unit test data that is also used by the WordPress.org theme team when we submit our theme. It can be downloaded from: https://wpcom-themes.svn.automattic.com/demo/theme-unit-test-data.xml.

In the final step in this chapter, we have to install the Developer plugin. We can install it by going to plugin section of wp-admin and then by searching for that plugin at http://localhost/topcat/wp-admin/plugin-install.php. Here is the screenshot of how the exact result should look like:

Note that the author of the plugin should be Automattic. Or, we can download the .zip file from https://wordpress.org/plugins/developer.

Now, perform the following steps:

This is my choice of plugins within the developer pack that I use, and you are free to use others if you want. If you want to change any of the settings that you have already chosen, you can go to Tools | Developer in wp-admin and change them there.