CSS Zen Garden is ten years old. If you started coding recently you may not have heard about the site, but Zen Garden was a defining moment in web history.

Zen’s developer, Dave Shea, had a simple objective: to illustrate why CSS should be taken seriously and inspire designers. The concept provided a static HTML page and allowed developers to apply and submit their own styles. The only restrictions were that the CSS should validate and the resulting page worked in IE5+ and Mozilla (Firefox’s predecessor).

The number of submissions increased exponentially and there was a sudden realization that CSS could do more than just apply color to H1 titles. To put it into historical context, by 2003 CSS techniques had been viable for several years but tables and spacer GIFs remained the predominant page layout methods. Tables worked in all browsers and were well understood.

Zen Garden did for CSS what Jesse James Garrett’s A New Approach to Web Applications did for Ajax a couple of years later. The technologies already existed, but it required a spark to ignite developer passion and revolutionize its application.

Zen Garden 2013

Zen Garden achieved its goal — who isn’t using CSS layouts now? To celebrate an amazing ten years, Dave Shea has re-released Zen Garden, put the code on GitHub and started work on a new HTML5 version. A lot has happened in the past decade, so the modern requirements permit:

• CSS3 transitions, transformations, animations, shadows, gradients and effects. Remember to prefix properties where necessary but Webkit-only designs will be “discarded with prejudice”!
• Responsive Web Designs
• Web fonts
• Support for IE9+, recent versions of Chrome, Firefox and Safari, and iOS/Android

New designs can be submitted now. Please send us the URLs of your groundbreaking examples or designs you like.

You’ll find mobile-interface-like toggle switches in various places around the web but I wanted to improve existing examples.

Specifically, I wanted a solution which:

1. progressively enhanced standard checkboxes
2. did not use superfluous HTML tags or attributes
3. supported input labels
4. used only CSS without images or JavaScript
5. used relative units so the controls are resizable/responsive
6. had some slick animation
7. ideally worked in a range of mobile browsers, and
8. degraded gracefully so it remained usable in all browsers

View the demonstration page and the HTML/CSS code…

The HTML

We require a input checkbox and a label:

<div>
	<input type="checkbox" id="switch1" name="switch1" class="switch" />
	<label for="switch1">first switch</label>
</div>

The input has a class of “switch” assigned. This ensures we can retain normal checkboxes should we need them.

HTML purists will be horrified to see a wrapper div but it’s only necessary if you require two or more toggle switches — you cannot have more than one switch (or further labels) in the the same parent container. Besides, you’ll probably need div wrappers to separate form elements anyway.

The HTML will render well in most browsers with minimal styling. IE6, 7 and 8 users will see this:

The CSS

Now for the interesting part. First, we’ll hide the input box using a negative margin — this can be preferable to display:none which often disables it on mobile devices:

input.switch:empty
{
	margin-left: -999px;
}

You may have seen the :empty selector used in my recent post, How to Create a Responsive Centered Image in CSS3. It only matches elements which have no children but, since it’s not supported in IE8 and below, those browsers won’t attempt to apply the styles.

Next, we’ll style the sibling labels of the input checkbox:

input.switch:empty ~ label
{
	position: relative;
	float: left;
	line-height: 1.6em;
	text-indent: 4em;
	margin: 0.2em 0;
	cursor: pointer;
	-webkit-user-select: none;
	-moz-user-select: none;
	-ms-user-select: none;
	user-select: none;
}

The main properties to note are position:relative, the text-indent which provides room for our switch, and the line-height which defines its height.

The toggle itself is created using :before and :after pseudo-elements for the colored background and the white switch accordingly:

• both elements are absolutely positioned at the left-hand edge of our label
• the white switch is set to a smaller size and has a left margin applied to align it on the background
• a border-radius and inset box-shadow is applied to give some depth, and
• a transition is defined for the animation.

input.switch:empty ~ label:before,
input.switch:empty ~ label:after
{
	position: absolute;
	display: block;
	top: 0;
	bottom: 0;
	left: 0;
	content: ' ';
	width: 3.6em;
	background-color: #c33;
	border-radius: 0.3em;
	box-shadow: inset 0 0.2em 0 rgba(0,0,0,0.3);
	-webkit-transition: all 100ms ease-in;
	transition: all 100ms ease-in;
}
input.switch:empty ~ label:after
{
	width: 1.4em;
	top: 0.1em;
	bottom: 0.1em;
	margin-left: 0.1em;
	background-color: #fff;
	border-radius: 0.15em;
	box-shadow: inset 0 -0.2em 0 rgba(0,0,0,0.2);
}

Finally, when the checkbox is checked, we move the switch to the right-hand edge and change the background color:

input.switch:checked ~ label:before
{
	background-color: #393;
}
input.switch:checked ~ label:after
{
	margin-left: 2em;
}

View the demonstration page and the HTML/CSS code…

Everyone likes a toggle switch! Please use the code however you like. A link back to this article or a “hey Craig, that’s awesome/awful” tweet is appreciated.

An interesting point was raised by Brendan Davis in my recent post “Responsive Web Design and Scrollbars: Is Chrome’s Implementation Better?”: are RWD breakpoints affected by high pixel-density screens?

The short answer is: no — but we need to delve a little deeper and look at the problems they can cause.

What is Retina?

“Retina” is Apple’s brand name for double-density screens but other manufacturers are creating similar displays. The technology is used in recent iPhones, iPads, MacBook Pros and other high-end devices.

For example, the MacBook Pro 15″ has a resolution of 2,880×1,800 or 220 pixels per inch. At this scale, most people are unable to notice individual pixels at typical viewing distances — applications and websites would be too small to use.

Therefore, the device reverts to a standard resolution of 1,440×900 but the additional pixels can be used to make fonts and graphics appear smoother.

What’s the Problem?

Standard-resolution bitmap images can look blocky on a Retina display. A 400 x 300 photograph is scaled to 800 x 600 pixels but there’s no additional detail. This can be noticeable when compared to smooth fonts and other high-resolution images.

Real-World Usage

If you look around the web, you’d be forgiven for thinking everyone has a Retina display. Currently, it’s only available in high-end devices, but these are coveted by developers so it leads to a disproportionate volume of online discussion. In the real world, the percentage of people using similar displays is in low single figures.

Let’s put it into context: if you’re not developing for the 1% of IE6/7 users, you probably shouldn’t be too concerned about people using Rentina — especially since they can still view your website.

That said, Retina-like screens will eventually migrate to all devices. There’s little reason to fret now, but there’s no harm in some forward planning. Let’s look at the options in order of recommendation…

1. Use SVGs and CSS3 Effects

The clue is in the name but Scalable Vector Graphics are … scalable! It doesn’t matter how big an SVG becomes — it will always be smooth because it’s defined using vectors (lines and shapes) rather than individual pixels.

SVG is not practical for photographs but is ideal for logos, diagrams and charts. The primary drawback is a lack of support in IE8 and below but you could always provide a PNG fallback or use a shim such as Raphaël or svgweb. See also: How to Add Scalable Vector Graphics to Your Web Page.

You may also be able to replace some images entirely. For example, titles, gradients, corners or shadows defined as graphics can be reproduced using CSS3 alone. They will render at a better quality, result in fewer HTTP requests and use less bandwidth.

2. Use Webfonts Icons

The more I use webfonts icons, the more I love them. Like SVGs, fonts are vectors so they’re scalable so you can use font sets which contain icons. They’re ideal for small, frequently used shapes such as email envelopes, telephones, widget controls and social media logos. They also work in every browser including IE6+.

There are plenty of commercial and free icon font sets available:

• Typicons
• Font Awesome
• Iconic
• Foundation

Or you can use a hosted font service such as We Love Icon Fonts.

I recommend creating your own small set of custom icons using online tools such as Fontello or IcoMoon.

3. Use High-Resolution Images When Practical

Retina has four times more pixels than standard screens. If you have a 400 x 300 image (120,000 pixels), you’d need to use an 800 x 600 alternative (480,000 pixels) to render it well on a high-density display.

However, the high-resolution file size may not necessarily be four times larger. Every image is different but if it contains solid blocks of color or details which can be omitted, it may be practical to use a 800 x 600 image and scale it in the browser.

Be pragmatic: if the standard image is 200Kb and the high-resolution version is 250Kb, there is negligible benefit using image replacement techniques. Use the better version throughout.

4. Use CSS Image Replacement

There will be times when high-resolution versions of your image are four times larger — or more. In those circumstances you may want to consider image replacement techniques, i.e. the standard image is replaced by larger alternative on Retina displays. The following media query code could be used:

#myimage {
	width: 400px;
	height: 300px;
	background: url(lo-res.jpg) 0 0 no-repeat;
}
@media
screen and (-webkit-min-device-pixel-ratio: 1.5),
screen and (-moz-min-device-pixel-ratio: 1.5),
screen and (min-device-pixel-ratio: 1.5) {
	#myimage {
		background-image: url(hi-res.jpg);
	}
}

The drawbacks:

1. You will need to create and maintain two sets of images.
2. Some browsers will download both images.

Remember that many of these users will be using smartphones or tablets on slower mobile networks. Detecting the connection speed would be more beneficial than determining the pixel density.

5. Use JavaScript Image Replacement

Retina display detection can be implemented using the following code:

var isRetina = (
	window.devicePixelRatio > 1 ||
	(window.matchMedia && window.matchMedia("(-webkit-min-device-pixel-ratio: 1.5),(-moz-min-device-pixel-ratio: 1.5),(min-device-pixel-ratio: 1.5)").matches)
);

Once a Retina display is determined, you could:

1. Loop through all page images and extract the URL.
2. Append ‘@2x’ to the file name and attempt to load the resulting image URL using Ajax.
3. If found, replace the current image with the high-resolution alternative.

Fortunately, the hard work’s been done for you at retinajs.com. While it only adds 4Kb weight, high-density display devices will download images twice — although the second time will occur as a background process after the page has loaded.

My advice: be practical and keep it simple. Don’t spend inordinate amounts of time attempting to solve minor rendering problems on devices with proportionally few users. Of course, none of that matters when your boss receives his new iPad and starts to complain about image quality…

Before You Get Started

Responsive Web design is intended to ensure that a site’s layout and content scale fluidly to the available screen real estate. This is a great approach for focusing your investments on improving site content and user functionality while ensuring that users have a good experience regardless of what device and screen size they use to visit your site. If you didn’t read the first article in this series, “Why the Web Is Ready for Responsive Web Design,” be sure to read it first.

It’s worth taking a step back, however, to think through your site’s experience and understand whether the device with which a user accesses your site changes the user’s expectations of the site’s functionality. Is the user checking your site for quick updates with her cellphone while she’s on the go? Is he sitting down, 10 feet away from a large TV screen, looking to immerse himself in a relatively passive consumption experience of rich content, videos and games? Are other users sitting down at their PCs, looking to get the most from your site content? Most of all, how do these expectations affect the site layout and functionality that you provide at those corresponding screen sizes?

What Kind of Site Is This?

Planning the content hierarchy for your site across different form factors is definitely the first step to having a great responsive-site experience. Consider the following examples, which evaluate and compare the top experiences that customers want to have when they access your site from a 4-inch phone while they walk or take public transportation, when they’re sitting at their computer desk, and when they’re lounging on their couches in their living rooms.

News Site (Content Consumption)

People visit ContosoNews.com primarily to do one thing—catch up on the day’s current affairs. When you see how this site is presented on a PC screen, it’s designed to have a layout like a newspaper. More important, the single home page is expected to attract and retain different kinds of readers, with interests in current affairs, business, sports, entertainment and other topics, and show them that ContosoNews has content that will interest them. The home page has a rich layout with slide shows, cycling of recommended articles, various categories of news available below the fold if you scroll down, recommended editorials and even the weather. Figure 1 shows a schematic illustration of the site at different resolutions.

Figure 1. Comparing Layouts for ContosoNews.com

If you visit this site on your mobile phone browser, you see a subset of the content, with menu and link navigation to the remaining content. The content that was available on the PC has been prioritized, and the top headline has been given focus above the fold. The slide show of recommended articles is replaced by a series of blurbs with links. The top articles from the Other Categories section are gone, replaced with a single category picker that navigates away from the home page.

In this way, users visiting the site on a phone can, in a cursory glance, become aware of the content available for consumption and dig deeper at their convenience.

Local Attraction (Hyper-Local Site)

Contoso Station is a hip new restaurant in Seattle. When people visit the restaurant’s site on their PC or TV screen, the restaurant proudly shows its latest Yelp reviews, news articles and tweets from users who add the hashtag #i&lt3contoso.

However, when you visit the site on a smartphone, the company makes a fair assumption that you’re visiting its site on the go with hopes to find its location, hours of operation and phone number. The phone might even request your location and show you a map with the quickest route to the restaurant. Some of the remaining content can be presented with much less detail—for example, the Yelp reviews are boiled down to one-line snippets—and the rest of the content (the Twitter feed, for example) can be hidden altogether for users visiting the site on their phones. Figure 2 shows an example of this scenario.

Figure 2. Comparing Layouts for Contoso Station

As seen in Figure 2, local businesses should prioritize and show an entirely different set of content to phone users and make their mobile experiences more sensitive to location.

Media Site (Rich Audiovisual Content)

ContosoTube is a popular Internet service where people share all kinds of videos. Users can see the latest top-rated and most frequently watched content. As they sign-in and explore the site, they can create and edit playlists of videos, get personalized recommendations, subscribe to other users’ playlists and even send each other messages.

The experience of ContosoTube on a phone is geared toward showing videos that a user has opened from other apps (instant messages, email, Twitter and so on), searching to view a video, and letting logged-in users access their existing subscriptions and playlists. Their experience is very limited for content curation.

What’s interesting about ContosoTube is that the Xbox site experience is similar to the phone experience from a user-functionality perspective, although the Xbox site is laid out differently based on screen real estate because even when ContosoTube users visit the site on their large screens, they are probably accessing it from their living room and doing so with controls less precise than a mouse. While the screen size of the TV might tempt developers to provide a more PC-like experience in terms of available functionality, it would be highly likely that users accessing ContosoTube on their TVs would focus primarily on watching content and not on creating it, managing it and messaging with others. Figure 3 compares site layouts for ContosoTube.

Figure 3. ContosoTube on a PC, TV and Smartphone.

HTML5 Games

On Build New Games, a website that explores HTML technologies for creating immersive gaming experiences on the browser, Jack Lawson provides a great discussion about what a gaming experience might be like for a responsively designed Web site.

A game is a great example of site design where users expect entirely different experiences based on the context in which they visit the site. For example, if a user visits the site WorldOfContosoCraft.com from his PC, he probably expects a full-fledged gaming experience—he can play the game himself, interact and communicate socially with other players through the in-game chat feature, make customizations and settings to his avatar and even participate in the in-game marketplace to buy upgrades, armor and other goodies.

On the console, this user might expect a similarly feature-rich experience, but he would also have expectations about being able to use his controller to drive the experience instead of the mouse and keyboard. (There are currently libraries for Chrome and Firefox—although with limited cross-browser support, as Nikhil Suresh points out in his discussion of controller support in JavaScript libraries.)

On the phone itself, the user might be looking to perform simpler actions, such as checking up on his inventory and gamer stats, performing some customizations on the avatar and maybe buying some add-ons from the in-game marketplace. Game developers, who can provide such a contextually relevant experience to users who visit their site from their cellphone for a few minutes, can keep their users engaged in the overall experience even when they can’t play the game.

Considerations for UI Design (aka Fat Fingers)

In addition to information design, you need to think about modes of user input. Today, first and foremost, this means that your site UI be touch-friendly. Visitors are not using touch for your Web site only on phones and tablets; they also use touch-screen-based PCs. Moreover, when you think about users on the Xbox, they’re interacting with the UI elements of your Web page by using a joystick, which is not as precise as a mouse.

Ideally, you do not want to design and code your user interface elements (buttons, links, form controls and so on) differently for touch (tablets and phones) than for PCs with traditional mouse-keyboard elements. In fact, Windows 8 makes this distinction nonexistent, with users able to run Microsoft Surface with a USB mouse as well as desktops with touch-screens. Moving forward, it’s reasonable to assume that more traditional PCs will be equipped with touch-screen functionality.

That’s why the best approach is to design a one-size-fits-all interface for user inputs that is comfortable for touch users to access. Mouse and keyboard users can still interact with these pages just fine.

To highlight some paradigm shifts in this approach, let’s take the example of one of the most common forms of navigation, the drop-down menu, on my favorite local radio station, Contoso Music. (See Figure 4.) This is just one example of a solution to links and navigation menus for touch, but it illustrates the most important considerations we need to take.

Figure 4. The Drop-Down Navigation Menu for Contoso Music

This navigation menu has a couple of issues that go beyond responsive layout, but they are still an integral part of building a unified site experience that scales across multiple devices.

1. First, a lot of sites use navigation menus on which links are revealed when a user mouses over the menu titles. This is absolutely unacceptable because a mouse-over does not translate well to touch browsers. In fact, touch-input aside, you shouldn’t rely on a mouse-over to reveal any useful information at all because it is not keyboard accessible and goes against W3C accessibility guidelines.
2. Second, look at the relative sizes of the links Playlists and DJs. These two pieces of information are supposed to be at the same level in the hierarchy. However, the size of the link is determined by the size of the text. This makes the DJs link less prominent, and also harder to precisely tap on a touch-screen. The DJs link could be as small as 20 px by 40 px, which is not accessible.
3. Another subtle problem, which you can see by glancing at the menu list items, is that only the text items themselves are hyperlinks. Here again, the touch user would be better served if the target for the link Foo was the entire width of the flyout menu instead of just the text width.

Moreover, users on all-in-one devices might utilize the same machine in different device configurations, in which case they might access your site with a mouse at one point and then revisit it later by using touch. It’s beneficial to provide the user with touch-friendly, well-spaced hyperlinks and navigation.

A common example of touch-friendly navigation that lots of sites use for their menus, especially on mobile apps or in a sidebar for tablets, is shown in Figure 5.

Figure 5. A Touch-Friendly Redesign of the Contoso Music Navigation Menu

The navigation menu utilizes touch, mouse or keyboard to expand and collapse the accordion-style submenus. All the links are the same width (even the submenu items), and for each link, the entire rectangle is clickable, not just the text.

A good example of a site that has made this transformation is MSN.com. The old MSN.com (shown in Figure 6) sports a significantly higher content density, with lots of text links (with smaller clickable areas) that are tightly packed (creating room for error when using touch and gaming joysticks), as well as a mouse-over to reveal the subcategories of news (see the menu under Entertainment).

Figure 6. The Old MSN.com

Figure 7 shows the new touch-friendly version of MSN.com. While currently offered only on Windows 8, the touch-friendly UI will be rolled out across the board for all browsers after testing. Notice the more spacious layout and larger hit targets.

Figure 7. The New Look for MSN.com

One Site Fits All

Responsive Web design should not only be about resizing the same content gracefully based on user screen sizes. To best connect with your users across multiple screens, your site should not only be aware of the device’s physical characteristics (such as screen size) but also infer the user’s physical circumstances, modes of input and the kind of information she is seeking.

In the next article in this series, I’ll cover some implementation techniques for responsive design.

The top scalable and modular approaches I covered in the previous article in my CSS Architectures series all have pieces of brilliance that can help you change the way you think about and structure your CSS. They also overlap in many areas, which indicates which aspects of the process of improving your CSS are truly critical. Although you could follow any single approach while constructing a new site to great success, the fact of the matter is that what most of us are doing is trying to make sense of existing CSS run amok.

So, while the approaches I described are great on their own, what we really need is a way to combine the superpowers from them all to combat the evil of crazy code – a sort of “Justice League” of scalable and modular techniques. Furthermore, just as Rome wasn’t built in a day, it’s a fool’s errand to try to correct in one fell swoop thousands of lines of code that lack rhyme or reason. Thus, it’s a good idea to pass over the code in focused waves through a phased approach.

Giving CSS Refactoring a Good Name

Last year, I had a project for a client where I was retained to do exactly that. After studying DRY CSS, OOCSS, SMACSS, and CSSG, I endeavored to distill them into their essential practices. In a moment of insight, I realized that all these approaches boiled down to the well-known adage “measure twice, cut once.” Of course! They all encourage looking at patterns, creating portable styles and modules that can be reused and not adding superfluous and redundant selectors or styles.

Additionally, my client had a lot of code and wanted to have flexibility in terms of the amount of changes that could be made to the CSS.  So, I developed a cohesive, phased plan of attack to reduce the number of lines in my client’s CSS. By the end, all of the practices and techniques for all four scalable CSS frameworks were incorporated, and the process I developed is very effective at reducing lines of CSS.

Once I created the process, I had to figure out what to name it. Taking “measure twice, cut once” as my base, I added CSS to it and this is what I got:

measure twice, cut once css → mtco css → meta coa css → MetaCoax!

So, in this article, I’ll share with you my MetaCoax CSS refactoring process, designed to “de-bloatify” thousands of lines of redundant CSS—improving the readability, simplicity and extensibility of the CSS while keeping the visible design and functionality of the site the same. (Check out the slides from my recent presentation on de-bloatifying CSS.)

To get yourself ready to refactor CSS, here are some suggestions. First, be conversant with specificity and the cascade – it will make a huge difference. I hope that in the first two articles in this series (Part 1, Part 2), I’ve driven home that making selectors and rules overly specific limits their reusability. When using descendent selectors especially, specificity can easily and quickly spiral out of control, and that’s precisely what we’re working to avoid. Second, remember inheritance rules: certain properties are inherited by child elements; thus, how these properties cascade down the DOM should always be kept in mind.

The MetaCoax Process

The MetaCoax process is a four-phased approach. Each phase builds on the previous one, and they all incorporate practices that decrease the amount of code, increase scalability and maintainability and, as an added bonus, lay the foundations for a future-friendly site. We’ll look at a detailed breakdown of each phase and the practices and techniques each encompasses. In this article, I’ll cover phases 1 and 2. Details about phases 3 and 4 will appear in the final article in the series.

Note: An excellent tool to use while you’re going through the MetaCoax refactoring process is Nicole Sullivan’s CSS Lint, which identifies additional places in the CSS to clean up and gives you ideas on how to do so.

Phase 1: Shorten Selectors and Leverage and Layer Rulesets

The first phase is focused on a minimum amount of work to improve a site’s CSS. These changes involve modifying the CSS but don’t touch the current HTML for a site’s pages. The goal is to make the stylesheet a little more lightweight and also easier to maintain and update with a small amount of time and effort. The method involves optimizing selectors while reducing redundancy with smarter reuse of rulesets. Even if you apply only the practices from this phase to your CSS, you’ll see an improvement in maintainability.

Here’s what we’re going to do:

• Shorten selectors chains
  • Kill qualifiers
  • Drop descendants
  • Make the selector chain three or less
• Leverage and layer declarations
  • Leverage the cascade by relying on inheritance
  • Review, revise and reduce !important properties
  • DRY (“don’t repeat yourself”) your rulesets

Shorten Selector Chains

To best optimize selectors, the goal is to use a shallow instead of a deep selector chain, making the chain as short as possible. This practice makes the code easier to work with, and the styles become more portable. Other advantages are reducing the chances of selector breakage, reducing location dependency, decreasing specificity and avoiding specificity wars by preventing overuse of !important declarations.

You have several ways in which you can shorten the selector chain, incorporating practices from all of the scalable architectures I outlined and further applying the “reduce, reuse, recycle” ethos. All of the practices are guaranteed to make the CSS code more forgiving. And isn’t that essentially the goal of updating our stylesheets?

Drop Descendent Selectors

The descendent selector (a b) is one of the most “expensive” combinatory selectors to use to target an element. Other expensive CSS selectors include the universal selector (*) and the child selector (a > b). What makes them expensive? They are very general, and thus force the browser to look through more page elements to make a match. The longer the selector chain and the more checks required, the longer the browser takes to render the styles on the screen. When matching a descendent selector, the browser must find every instance of the key selector (which is the one on the far right) on the page, and then go up the ancestor tree to make the match.

While this might not be a problem for a stylesheet of a few hundred lines, it becomes more of an issue when the size of a document nears 10,000 lines or more. Even more important, in adopting a future-friendly and mobile first approach, long selector chains create a situation where small, less capable devices are forced to load and process unnecessarily large CSS documents.

Overdependence on descendent selectors is a vestige of the days of coding for Internet Explorer 6, as Internet Explorer 6 did not render the other CSS 2.1 combinator selectors at all. Because Internet Explorer 6 usage is now almost nonexistent in the United States and other major markets, it’s completely safe to start employing selectors that are compatible with Internet Explorer 7 and Internet Explorer 8 and let go of the heavy use of descendent selectors once and for all. Table 1 shows the selectors you can use with Internet Explorer 7. All versions of Internet Explorer since then support all the selectors shown here.

Table 1. CSS 2.1 Selectors Safe for Internet Explorer 7.

Note: Check the charts at http://caniuse.com/ and http://www.findmebyip.com/litmus/ to determine the browser support of other CSS selectors.

Instead of the descendent selector, use the child selector. The child selector selects elements that are direct descendants of the parent element—that is, direct children in the first generation—as opposed to a grandchild or great-grandchild, which is what the descendent selector includes. Figure 1 illustrates this selection process.

Figure 1. A Descendent Selector vs. a Child Selector

Although the child selector is still an “expensive” selector, it is more specific. This means that the browser won’t search as far down the inheritance chain to match the key selector. Thus, such a selector targets the element you need much better.

If you must use a descendent selector, eliminate all superfluous elements in it. For example:

.widget li a

would become

.widget a

The style will be applied whether the li is there or not.

Kill Qualified Selectors

Qualifying both #IDs and .classes with elements causes the browser to slow unnecessarily to search for the additional elements on the page to make a match with the selector. It is never necessary to qualify an ID. An ID has one of the highest specificity weights in CSS because it is unique to whatever page it is on, and it will always have a direct match on its own. Qualified selectors also cause the specificity of the selectors to be ridiculously high, necessitating the use of even more specific selectors and the use of !important to trump these super-specific rulesets.

Selectors such as

div#widget-nav div#widget-nav-slider

can be simplified to

#widget-nav #widget-nav-slider

and further whittled down to

#widget-nav-slider

Each provides the same outcome.

Dropping an element class qualifier in selectors lessens the specificity of the selector, which better enables you to correctly use the cascade to override the style if necessary. For example,

li.chapter

would ideally be changed to

.chapter

Even better, because it is more specific to the case of the <li>, you could consider changing the class on your <li> tag, and scoping the CSS to

.li-chapter or .list-chapter

Make It Three or Less

When working on optimizing selectors, institute a “three or less” rule: a combinator selector should have no more than three steps to get to the key selector. For example, take this doozy of a selector:

div#blog-footer div#col2.column div.bestright p.besttitle {margin-bottom: 4px;}

To have three steps or less to get to the key selector, make a change like this:

#col2.column .besttitle {border: 1px solid #eee;}

Leverage and Layer Declarations

The next order of business is to focus on the style declarations themselves. When refactoring bloated CSS down to something more manageable, it’s easy to focus primarily on the selectors and believe that the styles will work themselves out. However, paying attention to what style declarations you’re creating (see Figure 2) and where they go makes a difference as well in moving toward sleek CSS.

Figure 2. Anatomy of a CSS Ruleset

Leverage Inheritance

Often, we think we know something really well when actually we don’t, and inheritance in CSS may just be one of those areas. You might remember that inheritance is a fundamental concept of CSS, but you might not remember exactly which properties naturally inherit and which do not. Table 2 shows the most commonly used properties that get inherited by descendent elements, unless the descendent elements are styled otherwise. (There are other more obscure properties that are inherited as well.)

Table 2. Common Elements Inherited by Descendent Elements

These properties are important to keep in mind when you’re looking for redundant styles to consolidate or eliminate. When you’re updating the stylesheet, properties that can be inherited should be placed in the CSS so that they are best utilized and not repeated. With proper placement of these properties, later redundant style declarations could be eliminated completely.

Review, Revise and Reduce !important Properties

If your CSS boasts an impressive number of !important declarations, then it’s time to reduce it. You should really use !important declarations only in certain instances. Chris Coyier of CSS Tricks recommends using them with utility classes or in user stylesheets. If you use them otherwise, you may end up being branded as selfish and lazy, and who wants that?!

How to cut down on !important? First, keep the specificity of selectors low by following the suggestions I made earlier.  Second, remember that, ideally, new styles should not undo previous rulesets but add to them.

Here’s what I mean: if you find yourself writing new styles to undo an earlier style (and then using !important to try to trump the style in the event of a specificity war), then you need to rethink the older style, distill it down to its necessities, and then create new styles that augment the original style instead of working to undo what’s already there. This is what I think of as “layering” style rulesets. This can also be referred to as “extending” (or “subclassing”) a style, which is part of creating modules in phase 2.

If you have a large number of !important properties for the same styles, I bet those properties could be turned into a portable style that could be applied to multiple elements, which I’ll also talk about when I describe phase 2.

DRY Your Rulesets

To cut down on large numbers of repeated styles in the CSS, a little DRY coding can help. While adopting the full DRY CSS approach may be a bit draconian, being aware of when you repeat the same ruleset and then getting your group on is a great practice.

Phase 2: Restructure, Adjust, and Modularize

The techniques in phase 2 are focused on doing a moderate to high level of work to improve a site’s CSS. The changes encompass altering both the CSS and the HTML of the pages, with the changes to the HTML most likely to involve renaming or reassigning class names. The goal is to give structure and organization to the stylesheet, through grouping styles by category rather than by pages, by removing archaic HTML, clearing the excess from the selectors and creating modules to increase code efficiency.

This phase will further eliminate redundancy, make the stylesheet more lightweight by improving selector accuracy and efficiency and also aid in maintenance. This level of improvement takes more time and effort than phase 1, but it includes the bulk of the work required to make your CSS better and is estimated to dramatically cut down the number of lines of CSS code.

Here is what we are going to do:

• Restructure to refactor
  • Categorize CSS rules in the stylesheet
  • Restructure styles that rely on qualifiers high in the DOM
  • Use class names as key selector
• Begin instituting modules
  • Extend module substyles with a double hyphen (–)
• Create portable helper styles
  • Surgical layout helpers
  • Typographical styles
• Adjust the HTML
  • Eliminate inline styles
  • Decrease use of <span> for better semantics

Restructure to Refactor

Let’s not forget that restructuring the CSS is our main objective. These practices start the process of moving away from thinking about and creating styles that are based on and specific to page components and page hierarchy, and moving toward thinking of styles in a portable, reusable and modular manner.

Categorize CSS Rules in the Stylesheet

In the first article in this series, I suggested creating a table of contents to make finding the sections of the styles in your CSS easier. In this phase of CSS refactoring, I recommend stepping up that process several notches by transforming these sections to the types of styles they describe, following the SMACSS categories. These categories are:

• Base The default styles, usually single element selectors that will cascade through the whole document.
• Layout The styles of the page sections.
• Module The reusable styles of the various modules of the site: callouts, sidebar sections, product, media, slideshows, lists, and so on.
• State The styles that describe how a module or layout looks in a particular state.
• Theme The styles that describe how modules or layouts might look.

So now, your table of contents and document sections will look like this:

/* Table of Contents
- Base
- Layout
- Module
- State
- Theme
*/
…
(later in the document…)
/* =Layout */ (etc.)

This reorganization of the stylesheet helps lay the foundation for the rest of the phase 2 practices and is a part of phase 3 as well.

Restructure Styles That Rely on Qualifiers High in the DOM

This recommendation is one of most important in this whole article: to completely eliminate page specific styles—that is, styles that are based on adding a class to the body element to signify a different page. A style such as this forces the browser to check all the way up the DOM chain to the <body> tag.   Here’s an example:

body.donations.events div#footer-columns div#col1 div.staff span.slug {
display: block;
margin: 3px 0 0 0;
}

This practice is the root of long selector chains, super-high specificity of selectors and the need to use !important to override styles higher up the cascade, as in the following example:

body.video div#lowercontent div.children.videoitem.hover a.title { background: #bc5b29; 
color: #fff !important; 
text-decoration: none; 
}

In other words, it’s bad. Mmkaay?

To fix it, you need to follow all of the previous suggestions, such as three or less, kill the qualifiers and reduce specificity. What you could end up with is something more like this:

.donations-slug {
display: block;
margin: 3px 0 0 0;
}

Use Class Names as Key Selector

Because IDs are highly specific, you should avoid using them whenever possible, as they cannot be reused as classes can. However, in creating classes you want to keep your class names semantic yet portable. The goal is to make a selector as direct as possible. By doing this, you avoid specificity problems and can then even combine styles to layer them as suggested earlier.

From SMACSS, you should instill the practice that when you create selectors, the key selector should be a .class instead of a tag name or an #id.  Always keep in mind that the far-right key selector is the most important one. If a selector can be as specific to the element in question as possible, then you’ve hit the jackpot. This way, the styles are targeted more directly because the browser matches only the exact elements.

Review all places where child selectors are used, and replace them with specific classes when possible. This also avoids having the key selector in the child combinator as an element, which is also discouraged.

For example, instead of doing this:

#toc > LI > A

it’s better to create a class, as shown next, and then add it to the appropriate elements.

.toc-anchor

Begin Instituting Modules

Nothing epitomizes the “measure twice, cut once” adage in the scalable CSS approaches as well as modules, which are the heart and soul of all of them. Modules are components of code that can be abstracted from the design patterns—for example, frequent instances of lists of items with images that float either to the left or right or underneath; these can be abstracted into a module with a base set of styles that every module would share. Then the module can be extended (or skinned) with changes in text, background, font color, borders, floats, and so on, but the structure remains the same.

The best thing about modules is that they are portable, meaning that they are not location dependent. Abstracting a design pattern into a code module means that you can put in anywhere in any page and it will show up the same way, without you having to reinvent the wheel style-wise. Now that’s what CSS was made for, right?! In addition to my earlier suggestions, modularizing your CSS is one of the best ways to dramatically decrease the amount of code.

OOCSS provides a great way to think about how to structure and skin a module and also about what can be made into a module. SMACSS provides clear guidelines on how to name modules and extend them.

Extend Substyles with  –

Although SMACSS gives great guidance for thinking about extending modules, I prefer the technique from CSS for Grownups of extending substyles with –. This makes a lot of sense to me because it is a visual indication that the new style is based on the previous one but is taking it further.

Here’s an example:

#go, #pmgo{
    width: 29px;
    height: 29px;
    margin: 4px 0 0 4px;
    padding: 0;
    border: 0;
    font-size: 0;
    display: block;
    line-height: 0;
    text-indent: -9999px !important;
    background: transparent url("/images/go.jpg") 0 0 no-repeat;
    cursor: pointer; /* hand-shaped cursor */
    x-cursor: hand; /* for IE 5.x */
}
#pmgo{
    margin: 2px 0 0 3px;
    background: transparent url("/images/go.jpg") no-repeat center top;
}

This code could be modified and changed into something more like this:

.button-search{
    width: 29px;
    height: 29px;
    margin: 4px 0 0 4px;
    padding: 0;
    border: 0;
    font-size: 0;
    display: block;
    line-height: 0;
    text-indent: -9999px !important;
    background: transparent url("/images/go.jpg") 0 0 no-repeat;
    cursor: pointer; /* hand-shaped cursor */
    x-cursor: hand; /* for IE 5.x */
}
.button-search--pm{
margin: 2px 0 0 3px;
background: transparent url("/images/go.jpg") no-repeat center top;
}

Create Portable Helper Styles

Along with the process of modularization, portable styles are another handy tool to have in your arsenal. Here are some examples from CSS for Grownups.

Surgical Layout Helpers

By CSS for Grownups’ standards, there’s no shame in having a little extra layout help. While a grid takes care of a lot of issues, these styles may give elements a little nudge when needed (especially in terms of vertical spacing), while eliminating lines of code.

.margin-top {margin-top: 5px;}
.margin-bottom {margin-bottom: .5em;}

Although in most cases we strive to keep names semantic when creating classes, in this instance descriptive names are fine.

Typographical Styles

Typographical styles are perfect if you find that much of your CSS is devoted to changing the font face, size and/or line height. Both OOCSS and CSS for Grownups suggest dedicated typographical styles that are not tied to the element, such as the following:

.h-slug {font-size: .8em;}
.h-title {font-size: 1.5em;}
.h-author {font-size: 1em;}

A great exercise is to search for the properties font, font-size, font-face, and h1 through h6 and marvel at the sheer magnitude of the instances of these properties. Once you’ve had a good laugh, figure out which styles apply to what, which sizes are important, and then start making some portable typographical styles.

Adjust the HTML

While the practices in phases 1 and 2 that we’ve covered so far offer miracles in terms of CSS cleanup, we can’t forget about the page markup. Most likely, as suggested by Andy Hume in CSS for Grownups, you’ll need to make changes to the HTML beyond adding new class names.

Decrease Use of <span> for Better Semantics

Do you have a rampant use of the <span> tag where a more semantic tag would be much more appropriate? Remember, the <span> tag is really for inline elements, not block-level elements, as stated by the W3C (http://www.w3.org/TR/html401/struct/global.html#h-7.5.4), so using <span> for headers and other elements intended to be block-level is technically incorrect.

Here, for example, the spans should really be paragraphs or header tags that indicate where this content fits in the document’s hierarchy. Either of those other elements could have provided a base for the class hooks.

<li>
<a href="/learning/hillman" title="">
<img src="/images/brenda-hillman.jpg" alt="Air in the Epic" />
</a>
<span>Brenda Hillman Essays</span>
<span><a href="/learning/hillman" title="Air in the Epic" class="title">Air in the Epic</a></span>
<span>Brenda Hillman</span>
</li>

The following version of this code would be an improvement from a semantics standpoint:

<li>
<a href="/learning/hillman" title="">
<img src="/images/brenda-hillman.jpg" alt="Air in the Epic" />
</a>
<p>Brenda Hillman Essays </p>
<h3><a href="/learning/hillman" title="Air in the Epic" class="title">Air in the Epic</a></h3>
<p>Brenda Hillman</p>
</li>

Eliminate Inline Styles

Finally, you need to get rid of inline styles. In this day and age, inline styles should rarely if ever be used. They are much too closely tied to the HTML and are akin to the days of yore when <font> tags were running rampant. If you use inline styles to override specificity, then making the changes suggested in this article should already help you avoid specificity wars, effectively eliminating the need for inline styles.

For example, this inline style:

<span class="text-indent: 1em">Skittles are tasty</span>

could easily be turned into its own class that can be applied throughout the document, like so:

.indent {text-indent: 1em:}

Your mission, should you choose to accept it, is to find all the instances of inline styles and see where you can make those styles portable helpers. The property you’re using could easily be made into a portable style that can be reused on the other instances of text.

Try It, It Will Be Good for You!

At the Øredev Web development conference in Malmö, Sweden, I had the pleasure of seeing the brilliant Katrina Owen present “Therapeutic Refactoring.” She suggested that when faced with a deadline, she turns to refactoring horrible code to help her gain a sense of control and rightness in the world.

You can approach restructuring your CSS for the better the same way. By healing what ails your CSS, you can gain a sense of calm and power, while beginning to make the world of your site’s stylesheets a better place, one line of code at a time.

Stick with me, though, because we aren’t quite finished. We have two more phases to cover in the MetaCoax process that will fully oust the evil from your CSS once and for all, and will also enable you to leave a legacy of goodness behind for all of the front-end devs that come after you.

Links for Further Reading

• CSS Lint Pages
• Breaking Good Habits – Harry Roberts’ talk at Front Trends Conference 2012
• Big CSS – Another great Harry Roberts presentation

—–

The Mobile Playing Field

Today, a large portion of site traffic comes from mobile devices—namely smart phones and tablets—in addition to traditional PCs. Across the globe, mobile devices now account for 12 percent of Internet traffic, and this is scaling up faster than desktop Internet traffic. The fraction of mobile Web traffic is sufficiently higher in nations with high smartphone penetration (for example, 20 percent of US-based Web traffic is via mobile browsing). What’s more, this figure is expected to grow significantly over the next 10 years, as smartphones evolve and mature in terms of hardware and software and adoption picks up in South America, Asia and Africa.

Site owners have begun to take advantage of this trend over the past several years and have primarily relied on native mobile apps for top sites such as Facebook, Hulu and the New York Times. Moreover, up-and-coming Web services such as Pulse, Flipboard and others have even taken to a mobile-first approach, by building apps for iOS and other ecosystems before building a Web site experience. Native apps allow developers to create unique phone-first, touch-optimized experiences for users to interact with their content to take advantage of features like camera integration, geo-location and offline data storage.

Targeting users on mobile natively makes good sense, especially within the US, where more than 50 percent of mobile users own a smartphone. While mobile apps offer site owners a way to connect with users on new form factors, new ways to monetize across platforms and new mobile-scenario-centric experiences to empower and delight their users, they offer an incomplete opportunity for developers compared to the ubiquity and reach of the Web. There are a couple of problems that affect a native mobile-only approach.

Problem 1: Cost of Supporting Multiple Platforms

Creating similar content and experiences across multiple platforms is costly and requires site owners to choose platforms for which to optimize. Additionally, this translates to a limited Web site experience for users who seek out your content from other platforms, especially when you need to prioritize your development investments.

Adopting a responsively designed Web site can help address the investment costs and ensure that your users across all the latest mobile operating systems are enjoying a consistently useful experience.

Scott Scazafavo, former vice president of product management at Allrecipes.com, whose responsibilities included mobile product development, puts it this way:

“To do a decent job developing a native mobile application that can compete with “best in class” offerings that are powered by live data or content (like we have at MSN and also at my previous employer, Allrecipes.com), it typically takes a minimum initial investment of about $250k to define, design and engineer that native application, and then an annual maintenance investment for that native app of $75K to $100K per platform to keep it evolving, feature wise, to keep consumers interested and adoption numbers healthy. That is over and above any internal work needed for design or engineering to create and maintain the services (APIs) that power those products.

The approach we have taken here at MSN for our TMX product (the new touch-first version of MSN.com currently available on IE10) with HTML5, as well as thin-shell apps to help deliver that product into app marketplaces, in addition to mobile browsers, comes only with a small incremental initial investment to what we do with internal resources to create that app product. [That figure is] probably a $25K to $50K initial investment per platform for each app, and a negligible maintenance cost thereafter to maintain those apps.”

Similarly, by using responsive Web design techniques, Clipboard.com was able to target many mobile, small device browsers like Internet Explorer 10 on Windows 8 and Safari on iPhone/iPad at half its expected costs to develop when they began the project.

Problem 2: Fragmented Ecosystems

Even within a given platform, a plethora of device geometries and sizes—as well as supported platform versions—exist. This requires site owners to not only design for near-similar display sizes and resolutions, but also to submit to multiple app stores (Kindle store, Google Play and Nook store, all on the Android platform). Managing multiple assets within the same platform adds complexity to the support matrix. Fix a layout bug in your native app for the Nexus 7, and you might have to fix it again for the Kindle Fire app. This means all your users are not on the same app version, with the same feature set and the same bug fixes.

Similarly (even within the iOS app ecosystem), top apps like ESPN, Spotify, Angry Birds Space and the App Store itself did not correctly occupy the full screen when the iPhone 5 was released, instead just showing users a black bar at the top and bottom of the app. The addition of iPhone 5 required developers to ship app updates to address this simple layout bug.

We’re also still at a stage where vendors are experimenting with new form factors, such as the big screen. For example, more than 25 million Xbox Live users now have access to Internet Explorer 10 on their living room TV screens and are interacting with it not just through a pointer but also through more human-centric mechanisms such as Kinect and Xbox SmartGlass. Today’s technical decision makers are facing a fragmented and very volatile landscape of devices that their users have integrated into their daily routines.

A Unifying Approach: Responsive Web Design

Responsive Web design aims to provide an optimal viewing/consumption experience—easy reading and navigation with minimum resizing, panning, and scrolling —across the gamut of devices that exist in the market, as well as to future-proof your site for those that are yet to come. There already exist different Web tutorials regarding individual techniques that help a site become more responsive. This series aims not only to provide a unified approach to responsive Web design, it aims to impress upon decision makers and developers the immediate need for adopting responsiveness as part of their reach strategy. According to a crawl of the top 5,000 Web sites by modern.IE, only about 14 percent of sites have some form of responsive design. It’s not difficult to see why developers think it’s a daunting task to consider.

Take a look at Figure 1. You can see the relative screen resolutions for the Web browsers on popular smartphones and tablets (the devices are identified in Table 1). The device resolutions, as well as ratio of CSS pixels to hardware pixels (a concept we’ll explain in part 3), are taken from Wikipedia. (Each square corresponds to 100 x 100 px of Web content, laid out at 1x optical zoom.)

Figure 1. Sampling of Resolutions for Several Current Devices

Table 1. Key to Figure 1

 
 
So is cross-browser, cross-device code the solution?

Traditionally, OS-specific apps have been able to provide more sophisticated user engagement because they have access to valuable user information, such as geo-location, offline storage and even custom font support for customized interfaces.

However, modern browsers such as Internet Explorer 10, Google Chrome (version 22), Safari 6 and Firefox (version 17) now offer the lion’s share of these experiences as part of their support for HTML5 and CSS3. HTML5 is not your grandpa’s HTML, which was originally designed to let people encode and deliver pieces of textual information across the Internet. HTML5 is intended for developers to write rich Web-based apps for the twenty-first century. Between HTML5 and CSS3, you get access to once-native features such as media queries, geo-location, custom font support, offline storage and even touch events! This way, your sites can have a different look and layout on hardware of different dimensions, provide users with location-aware services and even provide a valuable experience when the user is disconnected from the Internet.

HTML5 Myths

There are some common HTML5 myths out there. These include:

I can’t monetize HTML5.

HTML5 sites have arguably more monetization opportunities than their app equivalents. App monetization today includes app purchases (although most apps in the iOS apps store are in the free to $0.99 range). This is probably the only way in which HTML5 site experiences can’t be directly monetized. Otherwise, developers have a lot of control over advertising and in-app or in-site purchases. More importantly, a lot of apps tend to limit the amount of navigation a user can do. For example, most reader and newspaper/magazine apps offer textual content and don’t provide the “linky-ness” of the Web, which allows users to navigate to related content while consuming the current Web page.

The Web site experience, when responsively implemented, retains the “linky” nature of the Web and can lead to a higher number of user impressions.

HTML5 cannot be offline.

HTML5 has a couple of different solutions for ensuring that users have a great offline experience. First and foremost, Web pages can specify which of their assets should be made available to users when they are disconnected (using App Cache). This way, the user can still interact with the page even while offline. Additionally, HTML5 can locally store user information and input using Local Storage, as well as IndexedDB. This data persists even if the user closes the browser and can be synced back to the server at a later point in time when the user relaunches the Web page.

Check out the demo for this offline calculator. A user needs to be connected to the Web only the first time he visits it. Subsequently, he can access it offline. Moreover, the user’s calculation and results are stored via Local Storage so he can come back at a later time and continue a calculation.

The Mozilla hacks blog is a great start at busting some common myths about HTML5. It’s important to note here that native apps use APIs that are optimized for device-specific performance. However, HTML5 and CSS3 provide developers with tools to build engaging experiences across a variety of form factors and ensure that you are not missing out on users visiting from other platforms.

CanIUse.com is a great resource for understanding the available browser support for specific HTML5 and CSS features.

Media Queries and Responsive Design

One of the new tools in CSS3 to aid in responsive Web design is called media queries. Media queries allow you to offer your users the same HTML content but enable the browser to detect the size constraints of the device (in pixels) and layout the same content in a different, relevant manner. You can grow or shrink the width of your text and image content, increase or decrease the number of columns in your newspaper-style layout or even hide pieces of information entirely, depending on what you think the right consumption experience is for your user on a given device.

With a combination of media queries to dictate the layout of your content, as well as browser detection to identify additional constraints of the user experience (for example, if the user is interacting with a site via Xbox 360 on a large TV screen), you can identify your users’ needs and deliver the right experience for the current context in which a user has accessed your content—whether it be to consume it richly on a desktop, interact with it via touch on a slate or quickly skim through it on the go on a phone—and do so gracefully with Web technologies.

What’s best, most modern mobile devices support HTML5 and CSS3! This way, you can create near-native experiences directly within the browser. Short of DRM support or access to certain device-unique hardware, there’s no limit to the kinds of experiences you can offer through HTML5, CSS3 and JavaScript. Check out retro Atari video games to get an idea of the kind of cool experiences you can build purely with standards-compliant Web technologies.

It should be noted that using media queries alone to build three different fixed-width layouts for your Web site can definitely help you target common screen dimensions today (for example, desktop, tablet and phone). However, this is not truly responsive Web design. It does not provide an optimal experience for users visiting your site with a device that has an intermediate width, nor does it prepare you for the next wave of “it” devices with new geometries and dimensions.

Build Once! Deploy Once!

If you choose to invest in your site experience, you can design a single HTML5, CSS3 and JavaScript experience that can scale across form factors, from a small smartphone touchscreen to a large cinema display or TV set. We’ll go into the implementation details later in the series, but what’s great to note here is that you never have to choose which of your users you want to delight with that cool new feature, or protect with that high-security patch.

In addition to simplifying your code base and support matrix, this has the following advantages.

Benefit 1: Leave No Users Behind

Betting on powerful native apps for the top one or two mobile platforms can mean that some of your users migrate to competitors if they offer a useful Web experience, with more reach, on all platforms.

Benefit 2: Unified Ad Story

Often, when sites rely on advertising for revenue, they engage with their business partners and sell them advertising piecemeal, based on whether the users are experiencing the full-blown Web version or a limited app version. Also, click-through rates for ads on mobile devices are less than those on desktop PCs, in which case the extra cost of engaging with partners, creating advertising assets for native apps and selling app-specific ad real estate does not justify the additional gains. For example, MSN.com (which has now begun to roll out a unified, media-query-based HTML5 Web site across its international markets) can now unify its ad partnership story across all device types.

With a single HTML5 experience that responsively scales to different form factors, you can cater to a single ad customer with the same set of ad assets across a variety of devices—in the living room, on the work desk and on the go.

Benefit 3: Upgrade Your Site Experience Directly into Your App Experience

Occasionally, you might still hit a roadblock where you want to deliver a great mobile experience to your users that takes advantage of their unique hardware—for example, you want users to get new content from your site by shaking their phone. In this case, you need to access the device accelerometer.

Well, the great news is that you can create a native app by applying a wrapper around your site content and only write the necessary native app code to interact with the additional hardware on the phone. For example, you can host (the responsively scaled down view of) your site content within a WebViewController on an iPhone and just listen for the accelerometer event in your objective-C native code.

This means that for any fixes/features that you build within the Web layer, you don’t need to go through the trouble of shipping app upgrades!

“So, how do I start?”

At this point, we have yet to talk about the “how-tos” of responsive Web design. I’ll get to that in the next part of the series, but I hope you’ve had a chance to consider the long-term benefits of a solution for delivering your content to your users that consists of a single code base, written in familiar Web technologies, with ever-growing support of open JavaScript libraries, rich HTML5 device integration and high-quality CSS3 layout and graphic support. If not, you can always look back at the quickly increasing list of devices in Figure 1.

As the online industry matures, so do approaches to dealing with code for large Web sites. Cleaner CSS is a great starting point, but front-end developers can elevate a site’s stylesheet to another level by applying methodologies that are part of increasingly popular scalable CSS architectures.

By using an approach in its entirety or by applying selected tenets and practices from them all, you can say good-bye to problems that typically plague the CSS for large sites, such as verbose and difficult to read code that’s painful to maintain and update and the redundancy that creates code bloat.

Diagnosing the Origins of Bloated CSS

If you recognize any of the following symptoms or ailments, making your stylesheet modular and more scalable is just what the doctor ordered. To get a proper handle on just how bad things are, search for certain properties and see what the numbers tell you. In Nicole Sullivan’s presentation, the Top 5 Mistakes of Massive CSS, she provides a rubric to diagnose the roots of an overabundance of several key properties:

• A large number of floats means there is an ineffective or nonexistent grid.
• A large number of margins means you need a reset.css (or normalize.css).
• A large number of padding means that the design parameters aren’t explicit and thus multiple developers have tweaked details a lot.
• A large number of font-size means that the cascade is not being leveraged. Headings are probably hidden within the rule sets with font-size as well.
• A large number of !important means that this property is being used to override specificity and, again, that the cascade is not being leveraged.

Any of this sound familiar? It’s okay, you’re in good hands, because now that you’ve diagnosed the origins of your CSS bloat, we can talk about some sure-fire cures.

Scalable and Modular Approaches: The Essentials

The main concepts of the different scalable approaches can be boiled down to two core practices:

1. Reduce, Reuse and Recycle

Reducing means writing the shortest chain of elements possible in selectors, and dropping element qualifiers, much of which I discussed in the previous article. Equally important is creating appropriate selectors by favoring classes over IDs, avoiding the use of elements, and using combinator selectors that more directly target the element you need on the page.

Reusing involves creating generic classes instead of overly specific ones, and combining classes to create different visual outcomes.

Recycling involves better leveraging the cascade to cut down on redundant style declarations, modularizing page components to use throughout the site with minimum code and extending modules through subclassing.

2. Organize, Structure and Inform

Providing good, well-organized information is critical for clarity and understanding. The practices listed in the first article, like providing developer information in the stylesheet and creating a structure in terms of the document itself (by categorizing styles in the document), play a part in the scalable approaches. However, developers can add even more structure by breaking the style categories into multiple documents, indicating structure and meaning through a naming convention for reusable classes and establishing page structure with grids. Web site style guides are the final component for making sure the team is well informed about styles, structure and nomenclature.

An Overview of Scalable and Modular Approaches

Now that I’ve introduced the key concepts, let’s take a look at specific practices that support these concepts through an overview of the best-known and most popular approaches to dealing with large CSS projects. The approaches I’ll cover are DRY (Don’t Repeat Yourself) CSS, Object-Oriented CSS (OOCSS), Scalable and Modular Architecture for CSS (SMACSS), and CSS for Grownups.

DRY CSS

The ease of learning and applying CSS is mitigated by the language’s lack of logic. Unlike programming languages that have reusable components like variables and functions, CSS almost encourages flagrant reuse of selectors and property-value pairs. Indeed, even when redundant and bloated, CSS is perfectly functional.

DRY CSS is based on taking the “don’t repeat yourself” principle of software development very literally. That’s right: when coding CSS, the goal is never to repeat a property-value pair. Ever. I know it seems rather…ah, intense, but it can be done.

Get Your Group On (So to Speak)

The core of DRY CSS is grouping, which at its roots entails structure, organizing, reducing and recycling. Jeremy Clarke, who devised DRY CSS, suggests creating groups of selectors with shared properties, rather than repeating property-value pairs for each selector separately, as is typical when writing CSS. While a group may have many selectors, each property-value pair is defined only once.

The groups actually define shared properties. With DRY CSS, you have to relinquish the deeply ingrained habit of naming classes and IDs based on semantics, like .alert-box for example. Instead, groups use descriptive names based on their appearance or on their role in the design—like .rounded-corners—but then all selectors that share that property should be grouped with that style. While doing this takes away the possibility of mixing and matching, it does lessen the amount of your code.

How do you create a group? Start by naming the group based on its role in the design. Then use the name of the group as an ID at the top of the list and a class at the bottom. Then add the rest of the selectors that share properties above the descriptive class name that they share. Jeremy gives the example shown in Figure 1 in his presentation “DRY CSS: A don’t-repeat-yourself methodology for creating efficient, unified and Scalable stylesheets.”

Figure 1.Example of DRY CSS groupings

What about selectors that don’t immediately seem to be part of a group? Another goal in “drying out” your CSS is to make individual selectors as rare and sparse as possible, employing them only as exceptions. This means you need to perform a mental exercise when you’re coding. As you create a style declaration for a selector, always ask “Why isn’t this part of a group?”—and then figure out how to make it part of a group if you can.

Once you create groups, you need to think about organizing them. Clarke recommends using colors, text, shapes, structures and modules as categories, but he also encourages developers to create whatever categories they feel are best for a project.

Benefits

In his presentation on DRY CSS, Clarke lists many benefits to the approach. Here are some that I feel are most compelling:

• Decreases the size of CSS files. Clearly, this is the prime objective, and by using DRY CSS you more than achieve it.
• Optimises elements and generalizes selectors. The occurrence of this increases as you see their interrelatedness and how they can be inherited.
• Edits to a group affect all its members, which encourages consistency. You can see the members of a group change at the same time, which is a great advantage over making changes to a lot of individual selectors.
• The HTML remains untouched. This is useful for sites with generated HTML that can’t easily be controlled, such as content management systems or blogging tools.
• Encourages thinking through design elements/styles and design patterns and the consistency thereof. This promotes good design practices and uniform updates.

Clarke also asserts that DRY CSS integrates with other scalable architectures, such as OOCSS and SMACSS.

Successes

Clarke had great success applying his approach to the Global Voices site, which also had to support localization into multiple languages. According to Clarke, in developing and applying DRY CSS, the site’s stylesheet went from roughly 4,500 lines to 2,400 lines. That’s an improvement that most front-end developers would welcome.

OOCSS

Object-Oriented CSS starts with pattern recognition: determining what page elements are similarly structured and used frequently on the site. Once a pattern is identified, the design element can be made into a module. Then the module can be skinned for the different ways it shows up across the site.

OOCSS has two key principles. The first is to separate structure and presentation (or structure from “skin”), which means decoupling the structure of an element from its looks, and treating the looks like “skins.” This principle shouldn’t be too difficult to implement, as it’s similar to one of the foundational tenets of Web standards: the separation of presentation and content.

The second principle is to separate the container and the content, which means to use styles that are specific to an element and don’t depend on location. All too often, the common way to create CSS selectors is to attach an ID or a class to an element high in the DOM (like <body>), and then to create long-chain selectors to create variations on elements. This practice is responsible for most heinous CSS transgressions that lead to unwieldy and difficult to maintain stylesheets. Instead, in OOCSS, a container is modified by extending it, which effectively alters the container based on the content. In other words, you add an additional CSS class to provide for the differences in appearance only.

Sullivan breaks down the OOCSS approach into the following steps:

1. Determine the reusable elements sitewide, such as headings, lists (action list, external link list, product list, or feature list), module headers and footers, grids, buttons, rounded-corner boxes, tabs, carousels, toggle blocks.
2. Delineate between:
   • Container and content
   • Structure and skin
   • Contour and background
   • Objects and mixins
3. Mix and match container and content objects to achieve high-performance design.
4. For visual differences, skin the modules. Skins/themes are the module’s presentation—how it looks. The goal is to have very predictable skins, changing only values that can be easily calculated or measured.

Modules: The Building Blocks of a Site

Much of the practice of OOCSS is built on reusable components. Sullivan likens these components to Legos and refers to them as modules. The goal for a module is that it relies neither on the DOM tree nor on specific element types. It should be flexible enough to adapt to different containers and be skinned easily.

Identifying, creating and employing a module is a very DRY aspect of OOCSS. By finding common elements and presentations and abstracting them into reusable code modules, front-end developers don’t repeat themselves and really do practice reducing, reusing and recycling.

An excellent example of a module that can take care of images with text in various forms and incarnations is Sullivan’s .media module. The .media module was developed to handle instances of images floating off to the side of text and related permutations. She gives this example of various forms that the media module can take.

Here is the HTML that forms the structure of the media module:

        <!-- media -->
	<div class="media">
	  <img class="fixedMedia" src="myimg.jpg" />
	 
	  <div class="text">
	...
	  </div>
	</div>

The CSS of the initial module establishes the basis of the style, and any differences come from extending the styles and thus the appearance of the elements.

         /* ====== media ====== */
	.media {margin:10px;}
	.media, .bd {overflow:hidden; _overflow:visible; zoom:1;}
	.media .img {float:left; margin-right: 10px;}
	.media .img img{display:block;}
	.media .imgExt{float:right; margin-left: 10px;}

The media module is just the tip of the iceberg. Many more modules, including buttons, grids, carousels, and content, are on the OOCSS project on GitHub.

Benefits

Adopting OOCSS, or at least elements of the system, saves many lines of code. Furthermore, it provides an approach that is easily sandboxed and can be used by everyone on the team.

Successes

One of the biggest and most famous sites that Sullivan has applied OOCSS to is Facebook. According to the numbers given in her presentation CSS Bloat, she and the Facebook team cut CSS bytes per page by 19 percent and HTML bytes per page by 44 percent. Just with headers alone, they reduced the number from 958 to 25, and reduced the site’s response time by half.

SMACSS

SMACSS (https://smacss.com/) is another approach to writing scalable and modular CSS for large-scale sites. According to Jonathan Snook, its creator, “SMACSS is about identifying patterns in your design and codifying them.” Sure, I’m biased, but we could take “codifying” patterns as simply another way of describing the core tenants (reduce, reuse, and recycle; organize and structure), could we not?

Snook has several practices for applying organization and structure to large CSS projects. The core of SMACSS is the categorization of CSS rules. Categories help design patterns become more obvious, thus enabling developers to make better definitions for and of these patterns.

The categories that Snook suggests are:

• Base—These are defaults styles, usually for single element selectors.
• Layout—Divides the page into sections, usually holding modules together.
• Module—Reusable, modular parts of the design: callouts, sidebar sections, product lists, and so on.
• State—Describes how the module or layout looks in a particular state, also in different page views.
• Theme—Describes how modules or layouts might look.

In small projects, these can all be in the same file. In larger projects, multiple files are recommended.

However, there is a trick with the categories, and it involves thinking about what the styles actually do and what part of the site, design and functionality they apply to. This forces developers to ask during the building process “How are we going to code things, and why are we going to code them this way?” Thus, implicit in the categories are guidelines on how the styles are used, which further helps to prevent mixing styles across categories.

What’s in a Name?

The next important part of SMACSS is naming style rules. Clear class names are one of the key ways for knowing the category that a style rule is part of and what it does in the grand scheme of the page.

To indicate the differences between layout, module and state styles, Snook suggests appending prefixes to the class names. For layout, for example, you would add l- or layout-, creating a class name like .l-aside or .layout-aside. To indicate classes that create a state change, use .is-state, such as .is-active or .is-collapsed.

When creating names for modules, which include navigation bars, carousels, dialogs, widgets, tables, icons and so on, use the name of the module itself. For instance, an example module would be called, appropriately, .example (note that it is a class and not an ID). A callout module would be called .callout. If you need to add a state to a module, you know what to do: add .is-state, so, a collapsed callout module would be .callout.is-collapsed.

What about extending (or subclassing) a class? Easy. Instead of using a module’s class name as part of a combinator selector (and thus creating specificity issues), create a new class name based on the original class. For example .pod is extended by creating .pod-callout, and then you apply both styles to the element. With the new style, both styles have the same specificity, and thus the new style rules can play well with the first one.

Focus on Good, Clean Code, and Don’t Worry About “Classitis”

Clearly, one of the objectives of SMACSS (much like OOCSS) is to create shallow instead of deep selectors with the fewest generations of elements, striving for the shallowest selector possible. If you follow the recommendations in the first article in this series, you’re well on your way. But a little reminder never hurts, so to help limit the number of elements in a selector, follow these rules:

• Avoid tag selectors for common elements unless they are completely predictable. Using a class is preferable, even if you think the element is going to stay predictable. This includes qualifying classes with elements.
• Use class names as the right-most (key) selector.
• Use child selectors (e > f) instead of descendent selectors (e f).

Another goal of creating shallow selectors is to eliminate issues with selector specificity. One of the primary ways to ensure that you won’t have any specificity wars within your CSS is to avoid IDs for selectors. Don’t dismiss IDs completely, however. In SMACSS, it’s okay to use them for layout sections and for JavaScript hooks.

Some of us have had the old-school best practice “Don’t use too many classes!” deeply ingrained into our front-end development psyche. However, when it comes to SMACSS (and most of the scalable CSS approaches), you’re better off adding classes to the elements in question and repeating the class in the HTML than you are creating and applying a bevy of overly specific styles, which is the true cause of classitis. You’ll find that using multiple well-named classes clarifies intent and increases the semantics of the elements in question.

Benefits

The benefit of SMACSS is the clarity that comes from being conscious about your coding from the very start. Categories help slash redundancy, and naming conventions greatly aid efficiency in quickly identifying style rules in the CSS.

Successes

Snook developed SMACSS from his experiences working on enormous Web projects, one of the most notable being the redesign of Yahoo mail. He has had great success applying his principles with large sites built by large teams.

CSS for Grown Ups

Andy Hume, the creator of CSS for Grown Ups, jokingly refers to his system as “CSS for grumpy old people.” (You can watch a video here.) Like many of the creators of scalable approaches, Hume is concerned that our industry has become married to archaic, so-called best practices (most, ironically, created by developers who worked alone). He thinks that front-end developers have trudged unwittingly down a path that creates CSS that is feared and despised in most projects. This front-end code adheres to Web standards at ridiculous lengths to keep content and session separate, but it pays no mind to managing style and project complexity.

It’s clear that we need to optimize code for change. With CSS for Grown Ups, the goal is to style modules, not pages, and to go a step further by having a style module library that you can reuse.

Layers, Like an Onion. Or Cakes (or Parfaits)*

Much like the use of categories in SMACSS, CSS for Grown Ups describes styles being in “layers.” A style’s layer is related to:

• Document—From HTML code, element selectors.
• Base styles—Applies to element selectors, typographical styles, colors.
• Module styles—Lists, navigation, promo box, and so on.
• Layout styles—Establishes the grid or columns and page layout.

When creating selectors, be aware of whether they are document, base or module selectors, and make an effort to keep them all at the modular level. How will you know? If there is a tag as part of the selector, it will be a document style. However, if you create a class for it, you release it from the tag and make it a module style.

The goal is to try to avoid styles that are document-, base- or layout-related, and to shoot for ones that are module-related instead. Why? Let’s look at an example:

         .promo-box h2 { ... }

This selector is a module-level selector (.promo-box) combined with a document level selector (h2). This is all well and good at the outset, but what if somewhere down the line the structure of the HTML changes?

Instead, we should be shooting for the document and the module to be less tightly coupled so that the selector can be scaled in the future. This example does just that:

         .promo-box-h { ... }

In this instance, the style is not tied to a document’s element, and is thus far more flexible and portable, as it can be applied to anything, even elements that haven’t yet been invented in HTML.

Free Your Selector Name, and the Rest Will Follow

It should not surprise you that CSS for Grownups epitomizes the tenets of organize, structure and inform. According to Hume, styling with clear, informative class names is “like an API into your document—an API lets you style your document in the most simple and efficient manner.” Class names should be descriptive and should have meaning within the context of the site you’re working on. They should make sense to the members of the team working on the site so that you know which shared terms to reuse.

Like the other approaches, CSS for Grownups advocates creating and using modules. And like OOCSS and SMACSS approaches, the names of the modules should be descriptive and semantic and not tied to location or appearance:

         .promo-box { ... }

CSS for Grownups has a methodology for extending or substyling a module. Just use the module’s name, append it with two dashes (–), and add a clear, informative name for the extension, like so:

         .promo-box--light { ... }

The two dashes indicate that the style is an extension of the first and also that it is dependent on the first. Thus, it must come after the first style in the source order of the CSS in order to overwrite one or more style rules in the original.

Use Helpers. Be a Sharer

To handle presentation issues, Hume recommends using “surgical layout helpers,” which are standalone classes that provide either padding or margin. Here’s an example:

         .margin-top {margin-top: 1em;}

This would be the style you could add to whatever element needed it on the page, instead of wrapping that style into a component. Then these classes can be used on a case-by-case basis when a module needs to be spaced vertically on a page. Use these helper styles in your base stylesheet so that they can be used easily throughout the project.

Finally, writing online style guides is strongly recommended as a way to codify the naming and structure established and to disseminate this information to the team, making it available for those who will work on, add to and alter the site in the future. The style guide and corresponding module library needs be in code so that team members don’t have to reinvent the wheel to implement repeated visual styles.

Benefits

As Hume stated in his presentation at SXSW 2012, “Nobody is really smart enough to style web pages.” And because of this, he argues that we need certain constraints and parameters such as those supplied by CSS for Grownups. Constraints are good—they are a way to manage complexity. Hume developed CSS for Grownups as a way to manage complexity of CSS over large sites, over time and amongst teams of developers. Furthermore, CSS for Grownups creates what Hume calls a “design-meets-development touchpoint,” where the design language of an organization is turned into code, and clear collaboration from both teams results in a higher-quality product.

Successes

CSS for Grownups has roots in the vast amount of work that Hume did while he was at Clearleft, which has had many large clients, such as Channel 4, Amnesty International, and Mozilla. Now that he is at the Guardian, he has successfully applied his system to create a framework for the front-end developers there.

Progress, Not Perfection

In his presentation Breaking Good Habits, Harry Roberts accurately states that “CSS is such a mess that even when you clean it up, it’s still a mess.” Our goal is to make our CSS better, not perfect. So look at each of these approaches with an open mind. Remember, the point is not to drive yourself crazy trying to get your CSS to fit perfectly within some methodology. Even if you adopt only some of the techniques, you still gain the benefits of fewer lines of code that will scale.

The scalable and modular approaches all have pieces of genius and brilliance to them, and are particularly great when you are starting to code a project from scratch. But what do you do when you have to deal with a mountain of existing CSS, whose sheer immensity strikes fear in your heart? The next article will share a process to coax order and sanity into the wildest of CSS beasts, so stay tuned!

Links for Further Reading

• Structuring CSS – State of Play in 2012
• CSS Strategy Square-off
• CSS Architecture
• CSS ID Selectors: Never Say Never

In part 1 we took a look at some of the UI layout implementation details of the InstaFuzz app.  You can get the source code for the app from here if you wish to run it locally.  In this installment we’ll take a look at some of the other bits such as how drag/drop, File API, Canvas and Web Workers are used.

Drag/Drop

One of the things that InstaFuzz supports is the ability to drag and drop image files directly on to the big blackish/blue box.  Support for this is enabled by handling the “drop” event on the CANVAS element.  When a file is dropped onto an HTML element the browser fires the “drop” event on that element and passes in a dataTransfer object which contains a files property that contains a reference to the list of files that were dropped.  Here’s how this is handled in the app (“picture” is the ID of the CANVAS element on the page):

var pic = $("#picture");
pic.bind("drop", function (e) {
    suppressEvent(e);
    var files = e.originalEvent.dataTransfer.files;
    // more code here to open the file
});
 
pic.bind("dragover", suppressEvent).bind("dragenter", suppressEvent);
 
function suppressEvent(e) {
    e.stopPropagation();
    e.preventDefault();
}

The files property is a collection of File objects that can then subsequently be used with the File API to access the file contents (covered in the next section).  We also handle the dragover and dragenter events and basically prevent those events from propagating to the browser thereby preventing the browser from handling the file drop.  IE for instance might unload the current page and attempt to open the file directly otherwise.

File API

Once the file has been dropped, the app attempts to open the image and render it in the canvas.  It does this by using the File API.  The File API is a W3C specification that allows web apps to programmatically access files from the local file system in a secure fashion.  In InstaFuzz we use the FileReader object to read the file contents as a data URL string like so using the readAsDataURL method:

var reader = new FileReader();
reader.onloadend = function (e2) {
    drawImageToCanvas(e2.target.result);
};
reader.readAsDataURL(files[0]);

Here, files is the collection of File objects retrieved from the function handling the “drop” event on the CANVAS element. Since we are interested only in a single file we simply pick the first file from the collection and ignore the rest if there are any.  The actual file contents are loaded asynchronously and once the load completes, the onloadend event is fired where we get the file contents as a data URL which we then subsequently draw on to the canvas.

Rendering the filters

Now the core functionality here is of course the application of the filters.  In order to be able to apply the filter to the image we need a way to access the individual pixels from the image.  And before we can access the pixels we need to have actually rendered the image on to our canvas.  So let’s first take a look at the code that renders the image that the user picked on to the canvas element.

Rendering images on to the canvas

The canvas element supports the rendering of Image objects via the drawImage method.  To load up the image file in an Image instance, InstaFuzz uses the following utility routine:

App.Namespace.define("InstaFuzz.Utils", {
    loadImage: function (url, complete) {
        var img = new Image();
        img.src = url;
        img.onload = function () {
            complete(img);
        };
    }
});

This allows the app to load up image objects from a URL using code such as the following:

function drawImageToCanvas(url) {
    InstaFuzz.Utils.loadImage(url, function (img) {
        // save reference to source image
        sourceImage = img;
 
        mainRenderer.clearCanvas();
        mainRenderer.renderImage(img);
 
        // load image filter previews
        loadPreviews(img);
    });
}

Here, mainRenderer is an instance created from the FilterRenderer constructor function defined in filter-renderer.js.  The app uses FilterRenderer objects to manage canvas elements – both in the preview pane as well as the main canvas element on the right.  The renderImage method on the FilterRenderer has been defined like so:

FilterRenderer.prototype.renderImage = function (img) {
    var imageWidth = img.width;
    var imageHeight = img.height;
    var canvasWidth = this.size.width;
    var canvasHeight = this.size.height;
    var width, height;
 
    if ((imageWidth / imageHeight) >= (canvasWidth / canvasHeight)) {
        width = canvasWidth;
        height = (imageHeight * canvasWidth / imageWidth);
    } else {
        width = (imageWidth * canvasHeight / imageHeight);
        height = canvasHeight;
    }
 
    var x = (canvasWidth - width) / 2;
    var y = (canvasHeight - height) / 2;
    this.context.drawImage(img, x, y, width, height);
};

That might seem like a lot of code but all it does ultimately is to figure out the best way to render the image in the available screen area considering the aspect ratio of the image.  The key piece of code that actually renders the image on the canvas occurs on the last line of the method.  The context member refers to the 2D context acquired from the canvas object by calling its getContext method.

Fetching pixels from the canvas

Now that the image has been rendered we will need access to the individual pixels in order to apply all the different filters that are available.  This is easily acquired by calling getImageData on the canvas’s context object.  Here’s how InstaFuzz calls this from instafuzz.js.

var imageData = renderer.context.getImageData(
    0, 0,
    renderer.size.width,
    renderer.size.height);

The object returned by getImageData provides access to the individual pixels via its data property which in turn is an array like object that contains a collection of byte values where each value represents the color rendered for a single channel of a single pixel.  Each pixel is represented using 4 bytes that specify values for the red, green, blue and alpha channels.  It also has a length property that returns the length of the buffer.  If you have a 2D co-ordinate you can easily transform that into an index into this array using code such as the following.  The color intensity values of each channel ranges from 0 through 255.  Here’s the utility function from filters.js that accepts as input an image data object along with 2D coordinates for the pixel the caller is interested in and returns an object containing the color values:

function getPixel(imageData, x, y) {
    var data = imageData.data, index = 0;
 
    // normalize x and y and compute index
    x = (x < 0) ? (imageData.width + x) : x;
    y = (y < 0) ? (imageData.height + y) : y;
    index = (x + y * imageData.width) * 4;
 
    return {
        r: data[index],
        g: data[index + 1],
        b: data[index + 2]
    };
}

Applying the filters

Now that we have access to the individual pixels, applying the filter is fairly straightforward.  Here, for instance is the function that applies a weighted grayscale filter on the image.  It simply picks intensities from the red, green and blue channels and sums them up after applying a multiplication factor on each channel and then assigns the result for all 3 channels.

// "Weighted Grayscale" filter
Filters.addFilter({
    name: "Weighted Grayscale",
    apply: function (imageData) {
        var w = imageData.width, h = imageData.height;
        var data = imageData.data;
        var index;
        for (var y = 0; y < h; ++y) {
            for (var x = 0; x < w; ++x) {
                index = (x + y * imageData.width) * 4;
                var luminance = parseInt((data[index + 0] * 0.3) +
                                         (data[index + 1] + 0.59) +
                                         (data[index + 2] * 0.11));
                data[index + 0] = data[index + 1] =
                    data[index + 2] = luminance;
            }
 
            Filters.notifyProgress(imageData, x, y, this);
        }
 
        Filters.notifyProgress(imageData, w, h, this);
    }
});

Once the filter has been applied we can have that reflected on the canvas by calling the putImageData method passing in the modified image data object.  While the weighted grayscale filter is fairly simple most of the other filters use an image processing technique known as convolution.  The code for all the filters is available in filters.js and the convolution filters were ported from the C code available here.

Web Workers

As you might imagine doing all this number crunching to apply the filters can potentially take a long time to complete.  The motion blur filter for instance uses a 9×9 filter matrix for computing the new value for every single pixel and is in fact the most CPU intensive filter among them all.  If we were to do all this computation on the UI thread of the browser then the app would essentially freeze every time a filter was being applied.  To provide a responsive user experience the app delegates the core image processing tasks to a background script using the support for W3C Web Workers in modern browsers.

Web workers allow web applications to have scripts run in a background task that executes in parallel along with the UI thread.  Communication between the worker and the UI thread is accomplished by passing messages using the postMessage API.  On both ends (i.e. the UI thread and the worker) this manifests as an event notification that you can handle.  You can only pass “data” between workers and the UI thread, i.e., you cannot pass anything that has to do with the user interface  – you cannot for instance, pass DOM elements to the worker from the UI thread.

In InstaFuzz the worker is implemented in the file filter-worker.js.  All it does in the worker is handle the onmessage event and apply a filter and then pass the results back via postMessage.  As it turns out, even though we cannot pass DOM elements (which means we cannot just hand a CANVAS element to the worker to have the filter applied) we can in fact pass the image data object as returned by the getImageData method that we discussed earlier. Here’s the filter processing code from filter-worker.js:

importScripts("ns.js", "filters.js");
 
var tag = null;
onmessage = function (e) {
    var opt = e.data;
    var imageData = opt.imageData;
    var filter;
 
    tag = opt.tag;
    filter = InstaFuzz.Filters.getFilter(opt.filterKey);
 
    var start = Date.now();
    filter.apply(imageData);
    var end = Date.now();
 
    postMessage({
        type: "image",
        imageData: imageData,
        filterId: filter.id,
        tag: tag,
        timeTaken: end - start
    });
}

The first line pulls in some script files that the worker depends on by calling importScripts.  This is similar to including a JavaScript file in a HTML document using the SCRIPT tag.  Then we set up a handler for the onmessage event in response to which we simply apply the filter in question and pass the result back to the UI thread by calling postMessage.  Simple enough!

The code that initializes the worker is in instafuzz.js and looks like this:

var worker = new Worker("js/filter-worker.js");

Not much is it?  When a message is sent by the worker to the UI thread we handle it by specifying a handler for the onmessage event on the worker object.  Here’s how this is done in InstaFuzz:

worker.onmessage = function (e) {
    var isPreview = e.data.tag;
    switch (e.data.type) {
        case "image":
            if (isPreview) {
                previewRenderers[e.data.filterId].
                    context.putImageData(
                        e.data.imageData, 0, 0);
            } else {
                mainRenderer.context.putImageData(
                    e.data.imageData, 0, 0);
            }
 
            break;
        // more code here
    }
};

The code should be fairly self-explanatory.  It simply picks the image data object sent by the worker and applies it to the relevant canvas’s context object causing the modified image to be rendered on screen.  Scheduling a filter for conversion with the worker is equally simple.  Here’s the routine that performs this function in InstaFuzz:

function scheduleFilter(filterId,
                             renderer,
                             img, isPreview,
                             resetRender) {
    if (resetRender) {
        renderer.clearCanvas();
        renderer.renderImage(img);
    }
 
    var imageData = renderer.context.getImageData(
        0, 0,
        renderer.size.width,
        renderer.size.height);
 
    worker.postMessage({
        imageData: imageData,
        width: imageData.width,
        height: imageData.height,
        filterKey: filterId,
        tag: isPreview
});
}

Wrapping it up

The source for InstaFuzz is available for download here.  We saw that fairly intricate user experiences are possible today with HTML5 technologies such as Canvas, Drag/Drop, File API and Web Workers.  Support for all of these technologies is quite good in pretty much all modern browsers.  One thing that we did not address here is the question of making the app compatible with older browsers.  That, truth be told, is a non-trivial but necessary task that I will hopefully be able to talk about in a future article.

There are few reasons not to use a Responsive Web Design. Unless you have the time, budget and inclination to develop a separate mobile site or app, RWD techniques can assist your users on mobile and older devices.

But what if a user doesn’t want a mobile-optimized view of your site?

This question has been discussed by industry giants including Bruce Lawson and Roger Johansson. The possible reasons include:

1. The user regularly uses the desktop site but becomes disorientated in mobile view.
2. The mobile website hides content or features the user wants to use (admittedly, that may be bad design decisions but many sites do exactly that).
3. Modern smartphone browsers render desktop sites reasonably well and a user prefers scanning and zooming.
4. It would allow developers or support personnel to view desktop layout issues when using a mobile device.
5. Shouldn’t the user be able to select what’s best for them?

On the plus side, the concept appears to tick usability boxes and providing options is a good thing.

Or is it?

How many people would understand the switch? How many would use it? In my experience, non-technical users prefer fewer choices and, ideally, want the software or someone else to select what’s best for them. In addition, could they hit “switch to fixed layout” then find it difficult to revert to mobile view.

I’m sure there will be some good use cases but, personally, I think RWD offers more compelling advantages to the majority of users than disadvantages to the minority.

Perhaps this is a real issue users have encountered with your site? Or perhaps this is an over-engineered solution looking for a problem? I’m leaning toward the latter, but would love to hear your views…

When I started out on this app I was only really just interested in seeing if the web platform had really evolved to a point where an app like the hugely popular Instagram app could be built using just HTML, JavaScript and CSS.

As it turns out we can in fact do exactly that.  This article walks you through the technologies that make this possible and shows how it is entirely feasible today to build interoperable web applications that provide a great user experience no matter what brand of browser the user is running.

If you happen to be one of the two or so people who have not heard about Instagram then you might be pleased to hear that it is a hugely popular photo sharing and social networking service that allows you to take pictures, apply interesting digital filters on them and share them with the world.  The service became so popular that it was acquired by Facebook for a bag full of cash and stock in April of 2012.

InstaFuzz is the name of the app I put together and while I don’t expect to be acquired by Facebook or anybody else for a billion green it does, however, make the case that an app such as this one can be built using only standards compliant web technologies such as Canvas, File API, Drag/Drop, Web Workers, ES5 and CSS3 and still manage to run well on modern browsers such as Internet Explorer 10, Google Chrome and Firefox.  And you could easily use the code to build a Windows Store app too.

About the app

If you’d like to take a look at the app, then here’s where it is hosted:

http://blogorama.nerdworks.in/arbit/InstaFuzz/

As soon as you load it up, you’re presented with a screen that looks like this:

The idea is that you can load up a photograph into the app either by clicking on the big red “Add” button on the bottom left hand corner or drag and drop an image file into the blackish/blue area on the right. Once you do that you get something that looks like this:

You’ll note that a list of digital filters listed on the left of the screen shows a preview of what the image would look like if you were to apply the said filter.  Applying a filter is a simple matter of clicking on one of the filter previews on the left.  Here’s what it looks like after applying the “Weighted Grayscale” filter followed by a “Motion Blur”.  As you can tell filters are additive – as you keep clicking on filters, they are applied on top of what was applied earlier:

Let’s next take a look at how the UI layout has been put together.

UI Layout

The HTML markup is so little that I can actually reproduce the contents of the BODY tag in its entirety here (excluding the SCRIPT includes):

<header>
    <div id="title">InstaFuzz</div>
</header>
<section id="container">
    <canvas id="picture" width="650" height="565"></canvas>
    <div id="controls">
        <div id="filters-list"></div>
        <button id="loadImage">Add</button>
        <input type="file" id="fileUpload"
           style="display: none;"
           accept="image/gif, image/jpeg, image/png" />
    </div>
</section>
&nbsp;
<!-- Handlebar template for a filter UI button -->
&nbsp;
<script id="filter-template" type="text/x-handlebars-template">
    <div data-filter-id="{{filterId}}">
        <div>{{filterName}}</div>
        <canvas width="128" height="128"></canvas>
    </div>
</script>

There’s nothing much going on here.  Pretty much everything should be standard fare.  I will however draw attention to the fact that I am using the Handlebars JavaScript templating system here for rendering the markup for the list of filters on the left of the screen.  The template markup is declared in the HTML file (the SCRIPT tag in the snippet shown above) and then used from JavaScript.  The template markup is then bound to a JavaScript object that supplies the values for handlebars expressions such as {{filterId}} and {{filterName}}.  Here’s the relevant piece of JS from the app with a bit of DOM manipulation help from jQuery:

var templHtml = $("#filter-template").html(),
    template = Handlebars.compile(templHtml),
    filtersList = $("#filters-list");
 
var context = {
    filterName: filter.name,
    filterId: index
};
 
filtersList.append(template(context));

As you can tell from the HTML markup, all the filter preview boxes feature a CANVAS tag, as does the big box on the right where the final output is rendered.  We’ll go into a bit more detail later on in the article as to how canvas technology is used to achieve these effects.

The app also uses CSS3 @font-face fonts to render the text in the header and the “Add” button.  The fonts have been taken from the excellent Font Squirrel site and here’s what the declaration looks like:

@font-face {
    font-family: 'TizaRegular';
    src: url('fonts/tiza/tiza-webfont.eot');
    src: url('fonts/tiza/tiza-webfont.eot?#iefix')
           format('embedded-opentype'),
         url('fonts/tiza/tiza-webfont.woff') format('woff'),
         url('fonts/tiza/tiza-webfont.ttf') format('truetype'),
         url('fonts/tiza/tiza-webfont.svg#TizaRegular') format('svg');
    font-weight: normal;
    font-style: normal;
}

This directive causes the user agent to embed the font in the page and make it available under the name assigned to the font-family rule which in this case is “TizaRegular”.  After this we can assign this font to any CSS font-family rule like how we normally do.  In InstaFuzz I use the following rule to assign the font to the header element:

font-family: TizaRegular, Cambria, Cochin, Georgia, Times,
    "Times New Roman", serif;

You might also have noticed that there is a subtle shadow being dropped on the page by the container element.

This is made possible using the CSS3 box-shadow rule and here’s how it’s used in InstaFuzz.

-moz-box-shadow: 1px 0px 4px #000000, -1px -1px 4px #000000;
-webkit-box-shadow: 1px 0px 4px #000000, -1px -1px 4px #000000;
box-shadow: 1px 0px 4px #000000, -1px -1px 4px #000000;

This causes the browser to render a shadow around the relevant element.  Each comma separated section in the value specifies the following attributes of the shadow:

1. Horizontal offset
2. Vertical offset
3. Spread distance – positive values have the effect of softening the shadow
4. Shadow color

One can specify multiple shadow values separated by comma as in fact has been done above.  Note that I’ve also specified the shadow using vendor prefix syntax for Firefox and Chrome/Safari using the moz and webkit prefixes.  This causes the shadow to continue to work in versions of those browsers where support for this capability was provided using the vendor prefixed version of the rule.  Note that the W3C version of the rule – box-shadow – is specified last.  This is done deliberately to ensure that in case the browser supports both the forms then only the W3C behavior is actually applied to the page.

One often finds that web developers either fail to include vendor prefixed version of a given CSS3 rule for all the browsers that support that rule and/or fail to include the W3C version as well.  Often developers just put the webkit version of the rule ignoring other browsers and the W3C standard version.  This causes two problems – [1] poor user experience for users who are using non-webkit browsers and [2] it ends up resulting in webkit becoming a de-facto standard for the web.  Ideally we want W3C to be driving the future of the web and not one specific browser implementation.  So here are some things to remember when playing with experimental implementations of CSS features:

1. Use vendor prefixed versions of CSS rules by all means but remember to specify the rule for all supported browsers and not just the one that you happen to be testing the page in (if you’re using Visual Studio to edit your CSS then you might be interested in the supremely excellent extension for Visual Studio called Web Essentials that makes the job of managing vendor prefixes about as simple as it can possibly get).
2. Remember to specify the W3C version of the rule as well.
3. Remember to order the occurrence of the rules so that the W3C version shows up last.  This is to allow clients that support both the vendor prefixed version and the W3C version to use the W3C specified semantics for the rule.

That’s all for now.  In the next and final article in this series, we’ll take a look at how the app supports drag/drop of files, the use of File API, how the filters themselves work and how we prevent the UI thread from freezing by delegating the core number crunching work to web workers.

Image gallery lightboxes have been around for many years. They generally provide a great user experience until you attempt to load an image which is larger than the viewport dimensions. Developers often forget this important check and you’re presented with a centered image which is difficult to remove. The problem can be exacerbated on mobile devices.

Until recently, image lightboxes would need to implement several equations to determine the viewport and image dimensions then size and center accordingly. Fortunately, we can now rely on CSS3 media queries and transforms to do the hard work for us.

View the demonstration…

The HTML

Little to see here — we have an img and we’ll assign a class of “ri” (responsive image):

<img src="http://lorempixel.com/600/450/" class="ri" />

Remember to remove any height and width attributes.

Fallback CSS

IE6/7/8 do not understand media queries or transforms so our image will end up in the wrong location. There are shims and proprietary properties which could solve this but, in my opinion, they often cause more problems than they solve, i.e. increased page weight, degraded performance, maintenance headaches, etc.

Therefore, the following code provides a reasonable fallback for legacy browsers and should work on most landscape-oriented desktop screens:

img.ri
{
	position: absolute;
	max-width: 80%;
	top: 10%;
	left: 10%;
	border-radius: 3px;
	box-shadow: 0 3px 6px rgba(0,0,0,0.9);
}

The border-radius and box-shadow won’t be understood by old IEs either, but they’ll degrade gracefully.

Positioning the Image

To center the image, we move its top-left corner to the center of the viewport. To move it back to the true center, we use an appropriate transform (with prefixes for older browsers):

img.ri:empty
{
	top: 50%;
	left: 50%;
	-webkit-transform: translate(-50%, -50%);
	-moz-transform: translate(-50%, -50%);
	-ms-transform: translate(-50%, -50%);
	-o-transform: translate(-50%, -50%);
	transform: translate(-50%, -50%);
}

Take note of the selector: img.ri:empty — empty is a structural pseudo-class which only matches elements which have no children (an image should never have any). This is a CSS3 selector so IE8 and below will not parse the declaration. We could have used an alternative, such as Conditional Comments, but this seems a far more efficient solution and requires just six additional characters.

Making the Image Responsive

Our image must respond to the viewport dimensions to ensure it never overlaps the edge:

• a maximum width must be defined if the viewport is taller than it is wide, and
• a maximum height must be defined if the viewport is wider than it is tall.

We can use the media query orientation property to do the hard work for us:

@media screen and (orientation: portrait) {
  img.ri { max-width: 90%; }
}
@media screen and (orientation: landscape) {
  img.ri { max-height: 90%; }
}

Simple — and all done without any complicated JavaScripting. View the demonstration…

Please use the code as you like for your own projects. It could be used as the basis of your own modern, lightweight lightbox. Unless you’d like me to write one and provide a handy tutorial? Please forward your requests to @craigbuckler.

JavaScript, HTML5, CSS3: it’s a changing landscape. Web Directions brings together practitioners and big thinkers at the leading edge to educate and inspire at a “festival of code”.

SitePoint is partnering with Web Directions Code 2013 in Melbourne, Australia, and we have two free tickets worth $999 each to give away.

To enter, all you need to do is let us know why would you like to be at this year’s conference. We will pick the two most creative answers on Wednesday 24th April.

Sorry, this promotion is now closed. Winners will be contacted directly.

You can still buy tickets to Web Directions Code 2013. Use SITEPOINT as a voucher code to take $150 off the full price.

Fine print:

• Two conference tickets to be given away to the two most creative answers.
• Conference to be held in Melbourne, Australia, 2-3 May, no transport or accommodation included.
• Promotion ends 23th April 2013.

In my recent post, Is Your Responsive Web Design too Fragile?, I described an inconsistency between browsers when firing media query events:

• Chrome and Safari exclude the scrollbar dimensions.
• Firefox, Opera and IE include the scrollbar dimensions.

Assume we have a media query which detects a minimum width of 800px, e.g.

@media (min-width: 800px) { ... }

Chrome and Safari will include those styles when the body width is 800px or greater. However, if your OS shows vertical scrollbars with a width of 20px, other browsers would include the styles at 780px.

Let’s read the W3C media query specification for width:

The ‘width’ media feature describes the width of the targeted display area of the output device. For continuous media, this is the width of the viewport (as described by CSS2, section 9.1.1 [CSS21]) including the size of a rendered scroll bar (if any).

The Webkit engine is wrong. But is it better?

At first glance, Chrome’s implementation seems logical but it’s important to understand that ‘width’ refers to the viewport dimensions, i.e. the total area inside the browser window — not the page width. Using the assumptions above, Chrome’s viewport width is actually 820px (800px body + 20px scrollbar). In other browsers, the viewport width is 800px (780px body + 20px scrollbar).

Unfortunately, knowing the viewport width does not aid CSS development since you don’t know whether the scrollbar is visible or what its dimensions are. However, Chrome’s alternative is far worse since the introduction or removal of a scrollbar can trigger a media query. This is a little complex, so I’ll explain with an example:

1. Assume you have a simple responsive site which shows a desktop layout at 800px or greater and a mobile site at 799px or less. Scrollbar widths are 20px.
2. Currently, the user has their browser window sized to an 810px viewport width. The height is large enough to show the current page (in desktop layout) without scrollbars.
3. You click through to another page. Here, the content is longer than the viewport height and a vertical scrollbar appears. This reduces the body width to 790px and Chrome instantly switches from the desktop to mobile layout. The user becomes confused and vows never to return to your site again.

The situation is exacerbated if you have dynamically generated content. If a page currently fits in the viewport and you display a status message which increases the height, the resulting vertical scrollbar will switch the user from desktop to mobile layout (which could show the message in a different location). Once the status message is removed, the page will return to the desktop layout.

Firefox, Opera and IE do not exhibit this behavior because the viewport dimensions never change unless the user resizes their browser window. However, Chrome and Safari users could experience different layouts just because your site has slightly more content on one page than another. Nasty.

Admittedly, this is an edge case:

• Mobile browsers do not normally display permanent scrollbars so the problem is never apparent on those devices.
• A desktop browser user would be unlucky to have window dimensions set at a point where layouts noticeably changed.
• You could prevent Chrome switching layouts by ensuring the vertical scrollbar is always visible, i.e. body { overflow-y: scroll; }.

That said, I consider it a valid reason for the Webkit and Blink teams to address the issue. I suspect media queries were implemented in Webkit before the syntax became a standard. However, we now have a W3C Recommendation; it makes sense to follow the finalized rules and provide a consistent experience for users and developers.

I’d like to share with you a mysterious internal secret kept within Microsoft for a long time. It’s the real story behind the concept of the CSS Grid Layout imagined by Microsoft for IE10 and Windows Store Apps.

Most of you probably think that this specification was designed to give developers a better layout engine for their websites and applications. But the original motivation was completely different. The very first aim was to be able to create a Tetris-like game in an easy way!

I’m sure you’re not convinced yet. That’s why I’m going to prove it to you using Blend 5 as a companion. Ok, let’s go!

Pre-requisites: to follow this tutorial, you need first to:

1. Download/buy & install Windows 8 RTM on your machine: http://msdn.microsoft.com/en-US/windows/apps/br229516.aspx
2. Download & install the free edition of Visual Studio 2012 Express RTM for Windows 8: http://msdn.microsoft.com/en-US/windows/apps/br229516.aspx that includes Expression Blend 5 for Visual Studio or use the higher versions.

Step 1: discover the secret behind the CSS Grid Layout thanks to Blend 5

Launch Expression Blend 5 and create a new HTML (Windows Store) project of type Blank App. Name it “TheRealCSSGridStory”:

Replace:

<p>Content goes here</p>

With:

<div class="mainGrid">
</div>

Let’s create a grid containing 10 columns and 20 lines, whatever the screen’s resolution, by using fraction units. For that, add this CSS rule:

.mainGrid {
    display: -ms-grid;
    width: 100%;
    height: 100%;
    -ms-grid-columns: (1fr)[10];
    -ms-grid-rows: (1fr)[20];
}

Select in the Live DOM the <div> mainGrid element and you should obtain this:

Let’s draw a shape inside this beautiful grid. Add this block of HTML inside the main grid:

<div class="shape1">
</div>

And insert this CSS associated with it:

.shape1 {
    -ms-grid-column: 4;
    -ms-grid-row: 3;
    -ms-grid-column-span: 3;
    -ms-grid-row-span: 2;
    background-color: red;
}

You should now see that in Blend 5:

Cool, but nothing yet looks like to a Tetris gaming piece. Let’s work on that. Add these two DIVs inside the shape1:

<div class="line1shape1"></div>
<div class="line2shape1"></div>

and replace the previous .shape1 rule with this block of CSS:

.shape1 {
    -ms-grid-column: 4;
    -ms-grid-row: 3;
    -ms-grid-column-span: 3;
    -ms-grid-row-span: 2;
    display: -ms-grid;
    -ms-grid-columns: 1fr 1fr 1fr;
    -ms-grid-rows: 1fr 1fr;
    width: 100%;
    height: 100%;
}
.line1shape1 {
    -ms-grid-column-span: 2;
    background-color: red;
}
.line2shape1 {
    -ms-grid-column: 2;
    -ms-grid-row: 2;
    -ms-grid-column-span: 2;
    background-color: red;
}

The shape1 is currently spanning on three columns and two rows. I’ll then create a new grid inside this area defined by three columns and two rows in order to have cells having exactly the same size as the cells of the main grid, whatever the resolution might be.

Once done, I’ll create two lines in order to mimic the Z shape of the Tetris game. You should now have this result:

Even better, play with the various views available in the Device tab and you’ll see that our game is already implementing a responsive design! This is freaking cool, isn’t it?

Here, for instance, is the outputs for the snapped view and the portrait view:

Let’s now resolve another problem.

The Tetris grid gaming grid is composed of squares. Our current responsive design is stretching 100% width. Building a Windows 8 application for the Windows Store will most of the time meet widescreen monitors (current tablets are 1366×768 or 1920×1080 and most desktop PC have a 16/9 ratio). Let’s then assume that targeting a widescreen ratio is addressing almost all cases. To compute the proper responsive width, you need to do: 9/16 * 10/20 (the ratio of the main gaming grid) which equals to: 28.125%.

Add this rule to target the main grid in full screen landscape mode:

@media screen and (-ms-view-state: fullscreen-landscape) {
    .mainGrid {
        width: 28.125%;
        }
}

Let’s now center the gaming grid by using… the CSS Grid Layout again! (And you should now start to believe it was truly designed for Tetris!)

Switch the body element to –ms-grid made of one column and one row:

body {
    display: -ms-grid;
    -ms-grid-columns: 1fr;
    -ms-grid-rows: 1fr;
    width: 100%;
    height: 100%;
}

Now simply add this attribute to the CSS associated to the the main grid:

-ms-grid-column-align: center;

And the grid is now centered:

At this stage, you’re probably already shocked. “How could I have missed this incredible secret?” you’re wondering to yourself.

Take a breath.

Now that you know THE secret, let’s continue this tutorial together to discover other awesome possibilities delivered by the CSS specifications combined together.

Step 2: moving or rotating a shape

My first idea was to try avoiding JS by using as much CSS as possible. I then first tried to use CSS3 Animations to move and animate the shape on the various rows/columns. But the bad news is that you can’t change the –ms-grid-column or –ms-grid-row values via CSS3 animations. This will then be the job of some JavaScript code.

I then started to think about how I will rotate the shape. CSS Transforms seemed to be perfectly adapted for that. Let’s check that by doing some experiments. Blend 5 is really cool for that as you can directly see live the outcome of your changes.

Add a rotation of 90 degrees on shape1 by adding this class to its DIV element:

.shape1rotated {
    transform: rotate(90deg);
}

I’m sure you weren’t expecting this:

Problem: it’s not properly aligned to the gaming grid. To align our shape to the grid, we need some small adjustments:

.shape1rotated {
    transform-origin: 33% 50%;
    transform: rotate(90deg) translateX(-33%);
}

And we now have the same rotation as a Tetris-like game. Here are two screenshots before/after the rotation:

We can even go further than that by using a transition set on shape1 via this:

transition: all 1s ease-out;

And now, removing/adding the .shape1rotated class on the shape1 DIV will trigger a smooth rotation animation.

Check out the result inside Blend 5 thanks to this short video:

Download Video: MP4, WebM, HTML5 Video Player by VideoJS

At this stage, we could think that this approach is the good one to build our game. But this is unfortunately not yet the case. Here’s why. Try moving the shape by simply changing its –ms-grid-column property. Blend 5 will reflect the changes directly. When not rotated, the shape can be moved up to the 8th column:

So far so good. But when you’re rotating it by adding the .shape1rotated class to the DIV:

You see that there is still 1 row available on the right for the shape’s move. If you think we simply need to move it to the 9th row, you’re wrong! Indeed, here is what we’ll obtain on the 9th row:

You probably forgot that we’re currently moving a DIV element displaying a grid layout of three columns and two rows matching exactly the underlying gaming grid. When moving it, we really have the feeling that this is a block part of the main grid we’re moving. But for this trick to work, we need at least three columns available to contain our shape element. If it’s contained in two columns (when set to the 9th column) or less, it will be “compressed”, as in the screenshot.

There are two ways to resolve that.

1 – Stop using CSS Transforms and draw the rotated shape using another grid definition. For instance, using three divs inside the shape instead of two. But using such an approach will prevent us having the nice CSS Animations in place.
2 – Redefined the main grid to work on 12 columns instead of 10 and we’ll use only the columns from 2 to 11 (a sort of clipping area if you wish). This will resolve our “overflow” problem.

Let’s implement the second solution.

Redefine the main grid using this:

.mainGrid {
    display: -ms-grid;
    -ms-grid-columns: (1fr)[12];
    -ms-grid-rows: (1fr)[20];
    -ms-grid-column-align: center;
    width: 100%;
    height: 100%;
}

To also have the proper ratio, you need to update the associated media query:

@media screen and (-ms-view-state: fullscreen-landscape) {
    .mainGrid {
        width: 33.75%;
        }
}

33.75% = 9/16 *12/20

Let’s also add a “virtual grid” to delimitate the space where we will be able to move the shapes.  Inside the main grid DIV, insert this one:

<div class="virtualGrid">
</div>

Associated with this block of CSS:

.virtualGrid {
    -ms-grid-column: 2;
    -ms-grid-column-span: 10;
    -ms-grid-row-span: 20;
    border-right-style: dashed;
    border-left-style: dashed;
    background-color: #505A5A;
}

It will help to delimit the gaming area with a grey background and some dashed border lines.

Now, if I’m moving the Z shape on column 9, row 2, here is the result:

If I’m rotating it with CSS Transforms, I can move it correctly on column 10:

Bonus – handling the Portrait mode:

If you’d like to support the portrait mode (which is even better for the Tetris grid game), add this CSS Media Query definition:

@media screen and (-ms-view-state: fullscreen-portrait) {
        .mainGrid {
        width: 106.66%;
        }
}

As the ratio need to be computed as = 16/9 * 12/20 = 106,66%.

Step 3: adding some code to handle part of the game logic

Now that we’ve solved the graphics part of the game using only some pure CSS & HTML code, we need the help of JavaScript to move/rotate the shape in the gaming area. We’re going to re-implement the CSS logic via a JS object that’s going to be defined thanks to WinJS.Class.

Open the “TheRealCSSGridStory” in Visual Studio 2012.

Create a TetrisShapeZ.js file in the JS directory and copy/paste this code:

(function () {
    "use strict";
    var ShapeZ = WinJS.Class.define(
    /// Constructor - columnIndex is optional. If provided, defines the column the shape starts in
        function (columnIndex) {
            // We're creating the equivalent of this HTML block :
            // <div class="shape1 ">
            //     <div class="line1shape1"></div>
            //     <div class="line2shape1"></div>
            // </div>
            this._shape1 = document.createElement("div");
            var line1 = document.createElement("div");
            var line2 = document.createElement("div");
            this._shape1.className = "shape1";
            line1.className = "line1shape1";
            line2.className = "line2shape1";
            this._shape1.appendChild(line1);
            this._shape1.appendChild(line2);
            // Boolean to indicate if the shape is in its default orientation mode or not
            // True means not rotated, false means rotated
            this._defaultOrientation = true;
            // Setting the column position in the main grid
            if (columnIndex) {
                this._currentColPos = columnIndex;
                this._shape1.style.msGridColumn = this._currentColPos;
            }
            else {
                this._currentColPos = 1;
            }
            // We always start at line 1
            this._currentLinePos = 1;
            // Boolean to know if the shape can be move/rotate or not
            // If true, this means we've reached the last line possible
            this._fixed = false;
        },
        {
            /// Specify in which HTML element displayed in CSS Grid you'd like to work with
            /// width is the number of columns of the grid & height is the number of lines
            insertIntoGrid: function (element, width, height) {
                element.appendChild(this._shape1);
                this._gridWidth = width;
                this._gridHeight = height;
                // These are the left & bottom max limit for this shape
                // when displayed in default orientation mode
                this._maxLeft = width - 3;
                this._maxBottom = height - 1;
            },
            /// Rotate the Z shape 90 degrees anti/clockwise using CSS Transforms
            /// by simply removing/adding the shape1rotated class
            rotate: function () {
                if (!this._fixed && this._defaultOrientation) {
                    // rotating 90 degrees clockwise, it will trigger also the CSS Transition
                    WinJS.Utilities.addClass(this._shape1, "shape1rotated");
                    this._defaultOrientation = false;
                    // the left limit is now +1 vs the default orientation
                    this._maxLeft = this._gridWidth - 2;
                }
                else {
                    if (!this._fixed && this._currentColPos < this._maxLeft) {
                        // removing the shape1rotated will automatically reset the shape
                        // to its initial matrix and again the CSS Transition will do the
                        // animation for you
                        WinJS.Utilities.removeClass(this._shape1, "shape1rotated");
                        this._defaultOrientation = true;
                        this._maxLeft = this._gridWidth - 3;
                    }
                }
            },
            // Internal function called by public moveLeft/moveRight
            _moveHorizontally: function (direction) {
                if (!this._fixed && (this._currentColPos < this._maxLeft || direction === -1) &&
                (this._currentColPos > 2 || direction === 1)) {
                    this._currentColPos = this._currentColPos + direction;
                    this._shape1.style.msGridColumn = this._currentColPos;
                }
            },
            /// Move the shape on the immediate left column
            /// Test if you've reached the left limit or not
            moveLeft: function () {
                this._moveHorizontally(-1);
            },
            /// Move the shape on the immediate right column
            /// Test if you've reached the right limit or not
            moveRight: function () {
                this._moveHorizontally(1);
            },
            /// Move the shape down on the immediate below line
            /// Test if you've reached the bottom limit or not
            moveDown: function () {
                if (!this._fixed) {
                    this._currentLinePos = this._currentLinePos + 1;
                    this._shape1.style.msGridRow = this._currentLinePos;
                    if (this._currentLinePos === this._maxBottom) {
                        this._fixed = true;
                    }
                }
            }
        }
    );
    WinJS.Namespace.define("CSSTetris", { ShapeZ: ShapeZ });
} ());

Simply read the code to understand what it’s doing. It should be commented enough to be self-explicit.

Add a reference to this script file in default.html and keep only this block of HTML inside the body:

<div class="mainGrid">
    <div class="virtualGrid">
    </div>
</div>

Jump into default.js.

The cool part of having well-documented code is that we now have interesting IntelliSense details like for the constructor:

or the rotate function:

To properly use this code, add this block of JS just after processAll call:

document.addEventListener("keydown", OnKeyDown, false);
mainGrid = document.getElementsByClassName("mainGrid")[0];
myShape = new CSSTetris.ShapeZ(4);
myShape.insertIntoGrid(mainGrid, 12, 20);
init();

And add these two functions:

function init() {
    setInterval(function () {
        myShape.moveDown();
    }, 1000);
}
function OnKeyDown(event) {
    switch (event.keyCode) {
        case KEYCODE_X:
            myShape.rotate();
            break;
        case KEYCODE_LEFT:
            myShape.moveLeft();
            break;
        case KEYCODE_RIGHT:
            myShape.moveRight();
            break;
        case KEYCODE_DOWN:
            myShape.moveDown();
            break;
    }
}

And we’re done! We now have a very basic game using CSS Grid Layout coupled with CSS Transforms & Animations for the graphics part and a couple of JS lines of code to have the beginning of the basics of a Tetris-like game.

Here is a short video demonstrating the final result:

Download Video: MP4, WebM, HTML5 Video Player by VideoJS

You can download the final Visual Studio solution corresponding to the three steps of this tutorial here: http://david.blob.core.windows.net/win8/TheRealCSSGridStory.zip

So, are you now convinced that CSS Grid Layout was made to simplify the creation of Tetris-like games?