Responsive Web Design with HTML and CSS3

Book Notes by Julaine

smaller.png

By: Ben Frain

Publisher: Packt Publishing

Pub. Date: April 10, 2012

Print ISBN-13: 978-1-84969-318-9

Viewport Testing Tools

Internet Explorer users should make sure that they have the Microsoft Internet Explorer Developer Toolbar. This can be downloaded from the following URL:

http://www.microsoft.com/download/en/details.aspx?id=18359

If you are using Safari, my personal favourite is Resize (http://resizeSafari.com/), although ResizeMe (http://web.me.com/aaronholla/Safari_Extensions/ResizeMe.html) is similar and free.

If you use Firefox, there is Firesizer (https://addons.mozilla.org/en-US/firefox/addon/firesizer/) and Chrome users should check out the aptly titled Windows Resizer (https://chrome.google.com/webstore/detail/kkelicaakdanhinjdeammmilcgefonfh).

Not a fan of extensions? Here's a further alternative: I wrote a simple HTML page to display the current viewport height and width of a browser window. Using a dab of the JavaScript library, jQuery (http://jquery.com), this page gets the current viewport height and width and displays them. You can keep this page open in another browser tab, resize your window, and then flick back to the website in question to see how it fares. You can find the super simple "What size is my viewport page?" page at the following URL:

Online sources of inspiration

One web destination that is useful for inspiration is http://mediaqueri.es. However, not all websites displayed there necessarily embrace the full responsive methodology of displaying content around small viewports first, and progressively enhancing for larger viewports. Regardless, at this early point, whilst considering the possibilities of what we can do with responsive web design, there are many great examples to draw ideas from. Although viewing these websites and resizing the viewport illustrates what a responsive web design can do, it doesn't demonstrate what's good about HTML5. The benefits of HTML5 occur "behind the scenes" as it were, so let's now turn our attention there and find out what's so great about HTML5.

Can HTML5 and CSS3 work for us today?

  • Does the client want to support the largest growing market of Internet users? If yes, the responsive methodology is suitable.
  • Does the client want the cleanest, fastest, and most maintainable code base? If yes, the responsive methodology is suitable.
  • Does the client understand that experience can and should be subtly different across different browsers? If yes, the responsive methodology is suitable.
  • Does the client require the design to look identical across all browsers, including IE 8 and lower versions? If yes, responsive design is not best suited.
  • Are 70 percent or more of the current or expected visitors to the site likely to use Internet Explorer 8 or lower versions? If yes, responsive design is not best suited.
Media Queries
 A media query consists of a media type and zero or more expressions that check for the conditions of particular media features. Among the media features that can be used in media queries are 'width', 'height', and 'color'. By using media queries, presentations can be tailored to a specific range of output devices without changing the content itself. 

What media queries principally provide is the ability to target styles based upon the capability or features of a device, rather than merely the type of device. Think of it as a question to the browser. If the browser's answer is "true", the enclosed styles are applied. If the answer is "false", they are not. Rather than just asking the browser "Are you a screen?"—as much as we could effectively ask with just CSS2—media queries ask a little more. Instead, a media query might ask, "Are you a screen and are you in portrait orientation?" Let's look at that as an example:

 

First, the media query expression asks the type (are you a screen?), and then the feature (is your screen in portrait orientation?). The portrait-screen.css stylesheet will be loaded for any screen device with a portrait screen orientation and ignored for any others. It's possible to reverse the logic of any media query expression by adding not to the beginning of the media query. For example, the following code would negate the result in our prior example, loading the file for anything that wasn't a screen with a portrait orientation:

 

It's also possible to string multiple expressions together. For example, let's extend our first media query example and also limit the file to devices that have a viewport greater than 800 pixels.

 

Further still, we could have a list of media queries. If any of the listed queries are true, the file will be loaded. If none are true, it won't. Here is an example:

 

There are two points to note here. Firstly, a comma separates each media query. Secondly, you'll notice that after projection, there is no trailing and or feature/value combination in parentheses. That's because in the absence of these values, the media query is applied to all media types. In our example, the styles will apply to all projectors.

Just like existing CSS rules, media queries can conditionally load styles in a variety of ways. So far, we have included them as links to CSS files that we would place within the section of our HTML. However, we can also use media queries within CSS stylesheets themselves. For example, if we add the following code into a stylesheet, it will make all h1 elements green, providing the device has a screen width of 400 pixels or less:

@media screen and (max-device-width: 400px) {
h1 { color: green }
}

What can media queries test for?


When building responsive designs, the media queries that get used most often relate to a device's viewport width (width) and the width of the device's screen (device-width). In my own experience, I have found little call for the other capabilities we can test for. However, just in case the need arises, here is a list of all capabilities that media queries can test for. Hopefully, some will pique your interest:
  • width: The viewport width.
  • height: The viewport height.
  • device-width: The rendering surface's width (for our purposes, this is typically the screen width of a device).
  • device-height: The rendering surface's height (for our purposes, this is typically the screen height of a device).
  • orientation: This capability checks whether a device is portrait or landscape in orientation.
  • aspect-ratio: The ratio of width to height based upon the viewport width and height. A 16:9 widescreen display can be written as aspect-ratio: 16/9.
  • device-aspect-ratio: This capability is similar to aspect-ratio but is based upon the width and height of the device rendering surface, rather than viewport.
  • color: The number of bits per color component. For example, min-color: 16 will check that the device has 16-bit color.
  • color-index: The number of entries in the color lookup table of the device. Values must be numbers and cannot be negative.
  • monochrome: This capability tests how many bits per pixel are in a monochrome frame buffer. The value would be a number (integer), for example monochrome: 2, and cannot be negative.
  • resolution: This capability can be used to test screen or print resolution; for example, min-resolution: 300dpi. It can also accept measurements in dots per centimetre; for example, min-resolution: 118dpcm.
  • scan: This can be either progressive or interlace features largely particular to TVs. For example, a 720p HD TV (the p part of 720p indicates "progressive") could be targeted with scan: progressive whilst a 1080i HD TV (the i part of 1080i indicates "interlaced") could be targeted with scan: interlace.
  • grid: This capability indicates whether or not the device is grid or bitmap based.
Just in case you missed the memo, "reset" styles are a bunch of cover-all CSS declarations that reset the various default styles that different browsers render HTML elements with. They are added to the beginning of the main stylesheet in an attempt to reset each browser's own styles to a level playing field so that styles added afterwards in the stylesheet have the same effect across different browsers. There is no "perfect" set of reset styles and most developers have their own variation on the theme. The reset styles I use in HTML 4 documents are a combination of Eric Meyer's original (http://meyerweb.com/eric/tools/css/reset/) and a bunch of personal preferences and tricks I have picked up from studying the code of other incredibly clever folks such as Dan Cederholm (http://simplebits.com). If you don't currently use reset styles, inserting Eric's reset styles at the start of your HTML 4 document will be a good first step. I feel there are better starting points for HTML5 documents, such as normalize.css (http://necolas.github.com/normalize.css/) and we'll look at that in Chapter 4,HTML5 for Responsive Designs.

Getting the iOS and Android emulators

Although there is no substitute for testing sites on real devices, there are emulators for Android and iOS. Android emulator for Windows, Linux and Mac is available free by downloading and installing the Android Software Development Kit (SDK) at http://developer.android.com/sdk/. It's a command-line setup; so not for the faint-hearted. The iOS simulator is only available to Mac OS X users and comes as part of the Xcode package (free from the Mac App Store). Once Xcode is installed, you can access it from ~/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications iOS Simulator.app.
Noticing that the viewport meta element is seeing increasing use, the W3C is making attempts to bring the same capability into CSS. Head over to http://dev.w3.org/csswg/css-device-adapt/ and read all about the new @viewport declaration. The idea is that rather than writing a tag in the section of your markup, you could write @viewport { width: 320px; } in the CSS instead. This would set the browser width to 320 pixels. Some browsers already support the syntax (Opera Mobile, for example), albeit by using their own vendor prefix; for example, @-o-viewport { width: 320px; }.

CSS Grid systems

CSS Grid systems/frameworks are a potentially divisive subject. Some designers swear by them, others swear at them. In a bid to minimize hate mail, I'm going to say I sit entirely on the fence. Whilst I can understand why some developers think they are superfluous and in certain instances create extraneous code, I can also appreciate their value for rapidly prototyping layouts.

Here are a few CSS frameworks that offer varying degrees of "responsive" support:

 
Of these, I personally favour the Columnal grid system as it has a fluid grid built in alongside media queries and also uses similar CSS classes as 960.gs, the popular fixed-width grid system that most developers and designers are familiar with.

Most sites can be written in HTML5

Currently, if I'm tasked to build a website, my default markup would be HTML5 rather than HTML 4.01. Where the opposite was the case only a few years ago, at present, there has to be a compelling reason not to markup a site in HTML5. All modern browsers understand common HTML5 features with no problems (the new structural elements, video and audio tags) and older versions of IE can be served polyfills to address all of the shortfalls I have encountered.

What are polyfills?

The term polyfill was originated by Remy Sharp as an allusion to filling the cracks in older browsers with Polyfilla (known as Spackling Paste in the US). Therefore, a polyfill is a JavaScript shim that effectively replicates newer features in older browsers. However, it's important to appreciate that polyfills add extra flab to your code. Therefore, just because you can add three polyfill scripts to make Internet Explorer 6 render your site the same as every other browser doesn't mean you necessarily should!

Want a shortcut to great HTML5 code? Consider the HTML5 Boilerplate

If time is short and you need a good starting point for your project, consider using the HTML5 Boilerplate (http://html5boilerplate.com/). It's a pre-made "best practice" HTML5 file, including essential styles (such as the aforementioned normalize.css), polyfills, and tools such as Modernizr. It also includes a build tool that automatically concatenates CSS and JS files and strips comments to create production ready code. Highly recommended!

The

element

The

element is used to define a generic section of a document or application. For example, you may choose to create sections round your content; one section for contact information, another section for news feeds, and so on. It's important to understand that it isn't intended for styling purposes. If you need to wrap an element merely to style it, you should continue to use a

 

as you would have before.

The

The

element is used to define major navigational blocks—links to other pages or to parts within the page. As it is for use in major navigational blocks it isn't strictly intended for use in footers (although it can be) and the like, where groups of links to other pages are common.

The

element

The

element, alongside

can easily lead to confusion. I certainly had to read and re-read the specifications of each before it sank in. The

element is used to wrap a self-contained piece of content. When structuring a page, ask whether the content you're intending to use within a

tag could be taken as a whole lump and pasted onto a different site and still make complete sense? Another way to think about it is would the content being wrapped in

actually constitute a separate article in a RSS feed? The obvious example of content that should be wrapped with an

element would be a blog post. Be aware that if nesting

elements, it is presumed that the nested

elements are principally related to the outer article

The

The

element is used for content that is tangentially related to the content around it. In practical terms, I often use it for sidebars (when it contains suitable content). It's also considered suitable for pull quotes, advertising, and groups of navigation elements (such as Blog rolls, and so on).

The

element

If you have a number of headings, taglines and subheadings in

,

,

 

, and the subsequent tags then consider wrapping them in the

tag. Doing so will hide the secondary elements from the HTML5 outline algorithm as only the first heading element within an

contributes to the documents outline.

The HTML5 outline algorith

Be aware that with HTML5 there may be multiple

,

, and

elements within a page so you may need to write more specific styles for individual instances.

HTML5 allows each sectioning container to have its own self-contained outline.

The

element

The

element doesn't take part in the outline algorithm so can't be used to section content. Instead it should be used as an introduction to content. Practically, the

can be used for the "masthead" area of a site's header but also as an introduction to other content such as an introduction to a

element.

The

element

Like the

, the

element doesn't take part in the outline algorithm so doesn't section content. Instead it should be used to contain information about the section it sits within. It might contain links to other documents or copyright information for example. Like the

it can be used multiple times within a page if needed. For example, it could be used for the footer of a blog but also a footer within a blog post

. However, the specification notes that contact information for the author of a blog post should instead be wrapped by an

 

element.

The

element

The

 

element is to be used explicitly for marking up contact information for its nearest

or ancestor. To confuse matters, keep in mind that it isn't to be used for postal addresses and the like unless they are indeed the contact addresses for the content in question. Instead postal addresses and other arbitrary contact information should be wrapped in good ol'

 

tags.

These are notes I made after reading this book. See more book notes

Just to let you know, this page was last updated Saturday, Dec 21 24