CSS Flexbox Grids for Your Apps

ChocolateChip-UI provides a convenient grid system based on CSS flexbox. This means your grid columns use flex to determine their widths. This gives you responsive layouts. Because the grids use flexbox, there are no floats involved, and no need to clear floats, etc. Also all columns are automatically equal height in the same grid.

To make a grid, just put the class grid on a div:

// Define a grid:
<div class='grid'></div>

This gives you a grid row. Inside this you can create grid columns with the class col.

// Define a grid with 3 columns:
<div class='grid'>
   <div class='col'>1</div>
   <div class='col'>2</div>
   <div class='col'>3</div>
</div>

By default all columns have a flex value of 1, so they will all have the same width. You can give columns a specific flex value using specific classes that ChocolateChip-UI uses. These are as follows:

<div class='flex-1'></div>
<div class='flex-2'></div>
<div class='flex-3'></div>
<div class='flex-4'></div>
<div class='flex-5'></div>
<div class='flex-6'></div>
<div class='flex-7'></div>
<div class='flex-8'></div>
<div class='flex-9'></div>
<div class='flex-10'></div>

 

Live Example using “flex-1”

By giving columns various flex values you can create complex layouts for you app

 

Columns Based on Total Flex Value of 10

 

Equal Height Columns

As we mentioned, columns in the same grid row are always equal height.

 

Column Gutters

You can give your grid, both rows and columns, some preset gutters. To do so you can put one of two classes on the grid row: gutter-5 or gutter-10.

 

If you want some other gutter value, you can create your own class. Below is a possible class you could use:

.gutter-15 {
   margin: 15px;
}

Then you can use your class on your grids like with our own gutter classes.

Centered Grids

You can center the columns to the grid row, creating space around them, using the center class:

 

Fixed Width Columns

By their nature, flex columns are dynamic. They flex to fill whatever space is available on screen. This is great for mobile devices, such as when the user changes the orientation of a mobile device from portrait to landscape. You can rest assure that you layout will work equally well in all situations. However, sometimes you may need to give a particular column a fixed width. You can do this by giving it a special class. On this class you will define the width you want, and you will also set its flex value to 0:

.fixedWidth {
  -webkit-flex: none;
  flex: none;
  width: 250px;
}

Putting the above class on a column will force it to always have a width of 250 pixels. Any other columns in its grid row will use whatever space is left after that column is rendered. Below is an example of fixed columns:

 

Learning About Layout in ChocolateChip-UI

To learn more about layouts in ChocolateChip-UI, visit the following links:

From ChocolateChip-UI to TruckJS

It all started with a simple DOM library for mobile use. I named it ChocolateChip, because I liked chocolate a lot and because if was really small.

On this blog, one post after another, I created prototypes of how to replicate iOS with markup, CSS and some JavaScript. After many posts I had the makings of a framework. These were all random, so I needed to bundle it all together. ChocolateChip was the glue, so I named the framework ChocolateChip-UI. That was six years ago.

As time passed, ChocolateChip-UI grew to accommodate new layouts, widgets and support for Android and Windows Phone, and could switch out to use jQuery. And then we made jQuery the default. So many changes…

Recently I was thinking about where to take ChocolateChip-UI. It seemed like it had everything it needed. I went and got some specialty chocolates and some good coffee and sat down to brood. I thought about the difference between Backbone and Angular. Backbone at least had models, where as Angular does not. Because of that, Angular has to run constant polls to compare the state of the raw JavaScript objects. The more you use Angular’s data binding, the more polls you have going and everything starts slowing down, especially on mobile.

In a system with models, it’s the model’s responsibility to inform the system when its data is modified. The system does not need to be running polls to observe the model. It should provide encapsulation and abstraction, protecting data from accidental modification by the system/developer. And so, I began tinkering until I had a model. I created some uses for it, fine tuned it, added some more features, etc. It was an object factory that returned a new model instance without having to use the “new” keyword.

I was pretty happy that ChocolateChip-UI would now have a model, but that got me to thinking – maybe ChocolateChip-UI could use a controller module too. So I looked at how the competition was dealing with controller behavior. And, in the end, I decided to take a completely different approach. I was creating a framework for mobile apps. These have unique challenges because they are mobile. So decided to base this work around the concept of mediators. These sit in the middle of an app’s interactions, like this image:

mediator

I used ChocolateChip-UI pubsub methods as the basis for my mediator module. But mediators have a number of unique features. You can control how many times a mediator can run or when it can run. Then I went back to my model code and updated it so that a model would automatically notify the mediator layer that it had changed. Like the model, this was also an object factory reusing the same pattern.

So now I had a model-controller for ChocolateChip-UI. I had always thought of ChocolateChip-UI as just a view. But it was a very passive and disconnected view because it had nothing built into it to enable working with other MVC frameworks. This meant that to use these required various workaround. It was not optimal, but it worked. I started thinking that maybe I could create a view module in the same way that I had create the model and controller modules. My idea was to enable a more component like pattern. I popped out the template parser from ChocolateChip-UI and put it into a new object factory. The object that this created knew about an element that it was associated with. This would be the container for any template rendering. It would automatically parse the element’s child nodes to extract a template. Or you could define a template in the view’s initializer. And you could define events in the view. And finally, you could bind a view to a model.

In the background the code would generate a mediator that would listen for any changes to the bound model. When a change would occur, it would update the rendered view.

So, I now had a model view controller framework. They had no dependency on ChocolateChip-UI. At the moment they were running on top of jQuery. While I was creating these modules, I kept comparing functions to mechanical ones. So, when I was done I realized I had something totally different from ChocolateChip-UI. It was time for a name change. I thought about vehicle names, but in the end I settled on TruckJS because trucks are powerful, they can carry heavy loads. You can count on trucks.

I then though I’d give a shot at rewriting ChocolateChip using the new patterns I used for TruckJS. But I was going to do one important thing. The new DOM library would be identical in API to jQuery so developers wouldn’t have to learn anything new to use it. In the end I had a DOM library less than half the size of jQuery with 90% of the functionality. But instead of the old Ajax syntax, I used the new Fetch API for remove server interaction. And instead of jQuery’s deferred object implementation, I went with the ECMAScript 6 Promises API. Fetch uses ES6 promises, so this was a perfect fit.

Then I though about routing, so I built a router. Then I added in data formatting and form validation. After that I began porting the widgets over. I wound up rewriting every single widget, changing their behavior to return objects and enabling the form-based widget to work with the new form validation.

TruckJS is a standalone framework without any dependency on other libraries or frameworks. You do not need jQuery, etc. It provides everything you need to build mobile web apps. But, if you really want to use jQuery with Truck, you can. You just have to load jQuery first. When Truck detects jQuery, it switches to using it instead of its own DOM library. I’m not sure why anyone would want to use jQuery. Its bulky and slow on mobile devices. But there’s always those special guys who think something can’t be perfect unless jQuery is loaded.

I’ve put up a site, TruckJS.io, with lots of documentation. And it’s available on Github. If you like ChocolateChip-UI, I think you’re really going to like TruckJS. It gives you the same tradition of great layouts and widgets for creating cross platform mobile web apps.

 

ChocolateChip-UI 3.0.3 Supports jQuery

As of version 3.0.3, ChocolateChip-UI now supports jQuery 2.0.3. We tried earlier versions of 2.x, but there where performance issues that prevented us from offering it as an option. jQuery 2.0.3 has proven to be a good option for mobile Web apps as far as size and speed. As such, going forward we will be supporting jQuery with the latest version of ChocolateChip-UI.

This means you can use other frameworks or plugins with jQuery dependencies and still take advantage of the great features in ChocolateChip-UI for creating cross-platform Web apps for iOS 7, Android Jelly Bean and Windows Phone 8.

For more information about jQuery support in ChocolateChip-UI, please visit ChocolateChip-UI.com and read the documentation for jQuery Support.

iOS 5 Style Switch Control

Recreating the iOS 5 Switch Control with HTML5, CSS3 and a Bit of ECMAScript 5

The final result of this post will run in iOS 5, Safari 5.1, as well as the latest versions of Chrome, Firefox and Opera.

Previously I had created a version of the switch control in iOS. With the launch of iOS5 Apple complete updated the look of the switch control. They went with a rounded style, which they also did with most controls in their desktop operating system, Lion.

After playing around with the early betas of iOS 5, I came up with the following reproduction of the new switch control look using just HTML5, CSS3 and some JavaScript for the interactive part. Functionally the switch control is nothing more than a fancier way of presenting a checkbox. So, for our purposes we are going to use a checkbox. Except that we need a couple of tags to wrap the checkbox so we can make it look like the switch control. Fortunately the amount of wrapper is really minimal. If you examine the picture below, you will notice that the switch control really has only two parts: the oblong base and the circular thumb. In our case we need a third part: a checkbox input.

Switch Control

We’re going to make a minor tweak to this default look. You’ll notice that the version above is in English. Actually, only the English version has labels for “On” and “Off”, everyone else uses the international symbols instead. They look like this:

International version of Switch Control

If we ignore the “On/Off” parts and just look at the colored areas we can see that we’re only really dealing with a simple vertical gradient on the thumb and some inset box shadows on the switch control base. This makes our styling really easy. For the “On/Off” parts we don’t need extra markup. You’ll notice that they exist in relation to the switch control’s thumb. We can use CSS pseudo elements on the thumb to create them.

To recreate the iOS5 switch control all we need is the following markup:

	<div class="switch">
		<span class="thumb"></span>
		<input type="checkbox" />
	</div>

Without styling, this gives us a very normal checkbox:

Unstyled switch control

We know what the dimensions need to be by measuring the screenshots, so we can give the switch control base some styling:

	.switch {
		height: 28px;
		width: 77px;
		border: 1px solid #979797;
		border-radius: 20px;
		overflow: hidden;
	}

This will give us the following:

Switch control with rounded border

It looks kind of funny with the checkboxes. We don’t need to see them. We will be setting their checked state with JavaScript later on anyway. So for now we can hide them:

	.switch input[type=checkbox] {
		display: none;
	}

Now let’s add some color. How to re-create that gray shadow area? We’ll use a series of inset box shadows. Like gradients, you can define multiple box shadows on an element. These stack up like layers, the last one being the bottom-most and the first being the top-most. We need to create a sizable gray choke inside the switch base, so we’ll use a box shadow with four values instead of three to create that effect:

	box-shadow: inset 0 12px 3px 2px rgba(232, 232, 232, 0.5);

To this we’ll add a second inset box shadow to create a darker shadow along the top inside of the switch control:

	box-shadow: inset 0 1px 3px #BABABA, inset 0 12px 3px 2px rgba(232, 232, 232, 0.5);

Switch control with gray box shadow

Here’s the complete CSS definition for the switch control:

	.switch {
		height: 28px;
		width: 77px;
		border: 1px solid #979797;
		border-radius: 20px;
		margin-top: -5px;
		box-shadow: inset 0 1px 3px #BABABA, inset 0 12px 3px 2px rgba(232, 232, 232, 0.5);
		cursor: pointer;
		overflow: hidden;
	}

Now for a tricky part. This gray inset box shadow is for the off state. How do we implement the bluish on state? Well, first of all we need to decide how to represent the states in markup. We’ll do this by added a class of “on” to the switch control base. That means that the base will have a class of “switch on” for when it’s flipped on and just “switch” when it’s off. We can use a pseudo element on the switch base to create the blue state and position it in view or out of view based on the presence of the “on” class. Of course we’re going to need a little JavaScript to set and remove the “on” class when the user clicks. So, here’s the CSS for the on state. We create an empty text node and give it the height we need to match the base. We don’t give it a width just yet since that will get set when the switch has the “on” class. We give it a bluish background color and inset box shadow. The absolute positioning is so that when it’s show, it doesn’t push the thumb out of the switch but instead sits independently inside the switch.

	.switch::before {
		content: "";
		display: block;
		height: 28px;
		width: 0px;
		position: absolute;
		border-radius: 20px;
		box-shadow: inset 0 1px 2px #0063B7, inset 0 12px 3px 2px rgba(0, 127, 234, 0.5);
		background-color: #64B1F2;
	}

To show the “on” state we just need to give the blue pseudo element the same width as the base:

	.switch.on::before {
		width: 77px;
	}

If we add the “on” class to one of our switches, we can see how the on state looks:

	<div class="switch on">
		<span class="thumb"></span>
		
	</div>

Switch control with 'on' state

That’s all we need for the switch control’s base. Now let’s tackle the thumb. We’ll make the span a block element with dimensions, set its positioning to relative so we can give it a higher z-index than the other elements in the switch control, specifically, the blue on state pseudo element. Next up: border, box shadow and gradient, very straightforward. And finally, because we want to have the thumb slide back and forth when the switch is clicked, we need to enable a CSS transition and give it a default translate value. Note: you will need to add an appropriate vendor prefix for the gradient, transition and transform.

	.switch > .thumb {
		display: block;
		width: 26px;
		height: 26px;
		position: relative;
		top: 0;
		z-index: 3;
		border: solid 1px #919191;
		border-radius: 28px;
		box-shadow: inset 0 2px 1px white, inset 0 -2px 1px white;
		background-color: #CECECE;
		background-image: linear-gradient(top, #CECECE, #FBFBFB);
		transition: all 0.125s ease-in-out;
		transform: translate3d(0,0,0);
	}

This gives us the following:

Switch control with thumb

As you can see, all thumbs are in the same place. We need to define a translate value for their “On” state:

	.switch.on > .thumb {
		-webkit-transform: translate3d(49px,0,0);
		-o-transform: translateX(49px);
		-moz-transform: translateX(49px);
	}

Which gives us:

Switch control thumb in 'on' state

Now the only thing left is to create the “on/off” indicators. We’ll start with the “on” one. It’s really quite simple. a vertical stripe with a border around it. We’ll create a pseudo element that has an empty text node, style it and position it beside the thumb. Here’s the CSS:

	.switch > .thumb::before {
		content: "";
		display: block;
		height: 14px;
		width: 2px;
		background-color: white;
		box-shadow: 0px -1px 1px #666;
		border: none;
		position: absolute;
		top: 6px;
		left: -24px;
	}

Switch control with 'on' state indicator

And for the “off” indicator, we create a pseudo element with an empty text node styles as a circle positioned to the right of the thumb:

	.switch > .thumb::after {
		content: "";
		display: block;
		height: 10px;
		width: 10px;
		border-radius: 10px;
		border: solid 2px #777;
		position: absolute;
		right: -32px;
		top: 6px;
	}

Switch control with 'off' state indicator

Now we have a fully styled switch control with minimal markup. We just need to add some interactivity. For that we’ll have to write some JavaScript. Since this is a self-contained example, I’m going to use the very latest version of ECMAScript 5. This gives me an easy way to get DOM elements and toggle classes on elements. If you want to reuse this you’ll need to switch those parts out for whatever methods your chosen JavaScript library provides.

So, first up I’m going to wrap everything up in an anonymous function:

	(function() {
	
	})();

Next I need a convenience method to get a collection of nodes and turn it into an array so I can iterate over it. I use call slice method of the Array object and pass in the results of querySelectorAll. That will convert the node collection into an array:

	(function() {
		var $$ = function(selector) {
			return Array.prototype.slice.call(document.querySelectorAll(selector));
		}
	})();

Now I want to define an event that executes when the DOM is fully loaded:

	(function() {
		var $$ = function(selector) {
			return Array.prototype.slice.call(document.querySelectorAll(selector));
		}
		document.addEventListener("DOMContentLoaded", function() {
		
		}, false);
	})();

After getting an array of all switch controls in the document, we iterate through them with the **forEach** method and bind a click event listener. The listener will execute a function that toggles the class “on”. ECMAScript 5 introduces a new token collection for classes called classList. This has several useful functions: add, remove, contains and toggle. To accomplish these methods with straight JavaScript you would need to use regular expressions. Instead I can just use **Element.classList.toggle(“on”)** to add and remove the class when the user clicks:

	(function() {
		var $$ = function(selector) {
			return Array.prototype.slice.call(document.querySelectorAll(selector));
		}
		document.addEventListener("DOMContentLoaded", function() {
			$$(".switch").forEach(function(switchControl) {
				switchControl.addEventListener("click", function toggleSwitch() {
					switchControl.classList.toggle("on");
				}, false);
			});
		}, false);
	})();

With the above JavaScript in our document, when the user clicks a switch control, the class “on” will be added to or removed from the switch, causing its thumb to slide to the left or right accordingly. This handily takes care of our visual requirements for the functionality of the switch control. However, we do need to manage the checked state of the checkbox. The first thing we’ll do is make sure any switch controls that had the class “on” during page load have their checkboxes set to chekced. Since the checkbox is the last element in the switch control div, we can reference it that way:

	(function() {
		var $$ = function(selector) {
			return Array.prototype.slice.call(document.querySelectorAll(selector));
		}
		document.addEventListener("DOMContentLoaded", function() {
			if (switchControl.classList.contains("on")) {
				switchControl.lastElementChild.checked = true;
			}		
			$$(".switch").forEach(function(switchControl) {
				switchControl.addEventListener("click", function toggleSwitch() {
					switchControl.classList.toggle("on");
				}, false);
			});
		}, false);
	})();

Next we need to update a switch controls checkbox when the switch control itself is clicked. We just need to again get a reference to the checkbox and set its clicked state to the opposite of what it was when the user clicked:

	(function() {
		var $$ = function(selector) {
			return Array.prototype.slice.call(document.querySelectorAll(selector));
		}
		document.addEventListener("DOMContentLoaded", function() {
			var checkbox;
			if (switchControl.classList.contains("on")) {
				switchControl.lastElementChild.checked = true;
			}		
			$$(".switch").forEach(function(switchControl) {
				switchControl.addEventListener("click", function toggleSwitch() {
					checkbox = switchControl.lastElementChild;
					checkbox.checked = !checkbox.checked;
					switchControl.classList.toggle("on");
				}, false);
			});
		}, false);
	})();

And that’s all you need to make the switch controls work. The final example has some extra JavaScript to output some text when the user flips a switch on to show them working. For Safari, Chrome and Opera, I use innerText to set the text value, but Firefox uses textContent. So the code has to deal with those differences.

You can try the working example. If you want the code, just save that page to your desktop. Everything is self-contained in the page.

Back and Next Buttons Revisited

So, many moons ago, I wrote a post about how to make iOS style “Back” and “Next” buttons using CSS. Only problem was that technique used a span tag to create the pointer. For some reason it slipped my mind that I could use the CSS generated content property with the :before pseudo-element. Rather than being bothered with having to stick spans into buttons to turn them into pointers, I now introduce you to a more sane method of creating “Back” and “Next” buttons with just CSS.

Now you might be wondering how we would generate the node we need to style as a pointer. Using the CSS content property we can generate automatic content inside the button, removing the necessity of having a tag sitting there for no other reason. Unfortunately the content property only generates alpha-numeric content. We can’t use it to create a span or any other tag. But we don’t have to use a normal character as the content. A space will suffice to create the desired pointer. We make it display as a block element and then style it as if it were a normal pointer. Problem solved.

To accomplish our goal we need to switch out any reference to < span.pointer for :before

So, here’s the styles for a normal button, followed by the styles for the pointer.


.button.bordered.back:before {
	content: " ";
	display: block;
	z-index: 0;
	background-image: 
		-webkit-gradient(linear, left top, right bottom, 
			from(#92a1bf), 
			color-stop(0.3, #798aad),
			color-stop(0.51, #6276a0), 
			color-stop(0.51, #556a97), 
			color-stop(0.75, #566c98),
			to(#546993)); 
	border-left: solid 1px #484e59;
	border-bottom: solid 1px #9aa5bb;
	-webkit-border-top-left-radius: 5px;
	-webkit-border-bottom-right-radius: 5px;
	-webkit-border-bottom-left-radius: 4px;
	height: 23.5px;
	width: 23.5px;
	display: inline-block;
	-webkit-transform: rotate(45deg);
	-webkit-mask-image: 
		-webkit-gradient(linear, left bottom, right top, 
			from(#000000), 
			color-stop(0.5,#000000), 
			color-stop(0.5, transparent), 
			to(transparent));
	position: absolute;
	left: -9px;
	top: 2.5px;
	-webkit-background-clip: content;
}
.button.bordered.back:hover:before, .button.bordered.back.touched:before {
	background-image: 
		-webkit-gradient(linear, left top, right bottom, 
			from(#7d88a5), 
			color-stop(0.3, #58698c),
			color-stop(0.51, #3a4e78), 
			color-stop(0.51, #253c6a), 
			color-stop(0.75, #273f6d),
			to(#273f6d)); 
}

You can check out the finished version online or download the source code.

ChocolateChip-UI

Learn more about ChocolateChip-UI

ChocolateChip.js is now ChUI (pronounced “chewy”)

In the course of time I’ve created a lot of POCs (proof of concepts) on this blog. Some where fairly good, some where flaky one-offs. In the process I also created a small JavaScript library — ChocolateChip.js — that I used for actualizing most of these demos. Seeing how many people come to this humble blog in search of solutions to their development projects, I though about taking all the good ideas in these demos and putting them together as a one stop solution for mobile Web app development. I’m therefore today announcing ChocolateChip-UI. At present it’s a beta, but I intend to keep developing it to add more useful features over time. I

ChocolateChip-UI consists of ChocolateChip.js plus two other files: ChUI.js and ChUI.css. ChUI.js is a collection of JavaScript methods built on top of ChocolateChip.js. ChUI.js provides controls and widgets enlivened with behaviors needed for Web app development. ChUI.css is the magical CSS that makes simple markup look and act in a amazing way.

ChocolateChip-UI also introduces a new concept: WAML (Web App Markup Language). This is a specialized set of tags and attributes that get around the limits of HTML. HTML tags are really about creating documents, like books and other text publications. In contrast, WAML is a collection of tags and attributes that make sense for Web app development. ChUI.js and ChUI.css are built around the implementation of WAML as the key to how ChocolateChip-UI works.

WAML takes the paradigms of mobile application development and transfers those over to the development of mobile Web apps. There’s no need to smother and bury HTML tags with tons of classes trying to make markup meant for publishing documents work for creating applications. At the same time, WAML is really just a superset of HTML5 markup. You can therefore use any HTML5 tags and attributes along with WAML and ChocolateChip-UI to implement your solution.

ChocolateChip-UI is about making Web app development more straightforward. It provides common controls which have built in functionalities. Instead of having to figure out how to build these yourself, you can spend that time providing the data you want through ChocolateChip-UI’s controls easy to use controls.

The interfaces and controls which ChocolateChip-UI provides are all created using only markup and CSS. No images are required, no gifs or pngs. This means that everything you build with ChocolateChip-UI will be resolution independent. It will look good on a handheld mobile device and on a big HDMI screen. ChocolateChip-UI also provides a set of 52 SVG icons for use with buttons. Because these are vector based, they too are resolution independent. ChocolateChip-UI is therefore the first resolution independent mobile Web app framework.

The Holy Grail of Mobile Layout

The Holy Grail of Mobile Layout

The perfect mobile layout should allow the presence of a navbar, a content area and maybe a footer toolbar. This layout should resize with orientation changes such that the bottom toolbar is always at the bottom and the content area resizes its width and height to fit the new dimensions. This is tough because, first off, there is not fixed positioning, and secondly, there is no single finger scrolling in Webkit for CSS defined scrolling regions.

it’s taken me a while to come up with a solution to these layout requirements. Any of you trying to make a Web app feel like a native mobile app know the frustration of trying to deal with orientation change and complex layout. Not being able to make a toxic mix of viewport meta tags, CSS media queries and onorientationchange events work to give me a fluidly resizing layout when the mobile device’s orientation changed drove me to despair. I compensated early on using JavaScript to resize everything, except I had to pay a performance penalty, especially if an app was complex. After a lot of sweat and blood and endless trial and error, I finally came up with a CSS only solution to making a layout that resizes smoothly with orientation changes.

So, the first big mistake, one that everyone and their brother recommends, is not to use the meta tag viewport settings of device width and device height. Instead, just use the initial scale, maximum scale and user scalability:

<meta name="viewport" content="initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

The reason is that no matter what you set the width and height to with CSS, Webkit insists on thinking the document should have the height and width from when the document first loaded. This happens even if you use a CSS value of “width: 100%”. Switching from portrait to landscape, you’ll see that your layout fails to fill the width of the landscape screen:

iPhone Portrait Layout

iPhone Portrait Layout

iPhone Landscape Layout

iPhone Landscape Layout

As you can see with the landscape orientation the layout fails to fill the available width of the device. This app has its root elements’ widths set to 100% and a meta tag of:

<meta name="viewport" content="width=device-width; height=device-height; initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

Removing the device width and height from the meta tag will give us the fluid layout we seek:

<meta name="viewport" content="initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

With the above change, when switching this document loaded in portrait orientation to landscape mode orientation we get a resized document the way we would like:

iPhone Landscape Layout Correctly Resized

iPhone Landscape Layout Correctly Resized

OK, so we have a navbar on the top, but what if we want a toolbar on the bottom? No problem. We can accomplish that with a few adjustments. To fix the toolbar to the bottom we’ll use absolute positioning. One thing to remember about this layout technique, if you are going to have navbars or toolbars, you’ll need to adjust the height of the content so that it fits the space left over by the bars. I do this using a class or class on the content section. A navbar or toolbar has a default height of 45 pixels, so you’d want to position your content that distance from a navbar or toolbar. To make this work, we’re going to have to use absolute positioning on the content section and on any bottom toolbar. One thing rather frustrating about using absolute positioning on block elements is that it causes them to collapse to what their content is, even with they have a width of 100%. We can get around this by setting the appropriate side to 0 pixels. For a bottom toolbar this could be something like this:

.toolbar.bottom {
    height: 45px;
    position: absolute;
    bottom: 0;
    left: 0;
    right: 0;
}

With the above measurement, we have a toolbar that is 45px high fixed to the bottom and stretching from side to side. This toolbar will maintain these dimensions and placement even with an orientation change. We’ll need to do something similar for the content area. Like I said, we’ll need to use absolute positioning and account for any space taken up by a nav or toolbar. I use classes to do this, such as “withNavbar”, or “withNavbar withBottomToolbar”, or “withBottomToolbar”. The CSS for these classes would be something like this:

/* Definition for content area that fills the screen: */
#content {
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
}
#content.withNavbar {
    top: 45px;
    right: 0;
    bottom: 0;
    left: 0;
}
#content.withBottomToolbar {
    top: 0;
    right: 0;
    bottom: 45px;
    left: 0;
}
#content.withNavbar.withBottomToolbar {
    top: 45px;
    right: 0;
    bottom: 45px;
    left: 0;
}

We also need to make sure that the document’s content doesn’t bleed down below the bottom toolbar. We do this by wrapping the entire document in a div. I give it an id of #main:

<body>
	<div id="main">
		<div class="navbar">
			<h1>The Title</h1>
		</div>
		<div id="content" class="withNavbar withBottomToolbar">
			<ul class="table-view">
				<li><span class="title">Item One</span></li>
				<li><span class="title">Item Two</span></li>
				<li><span class="title">Item Three</span></li>
				<li><span class="title">Item Four</span></li>
				<li><span class="title">Item Five</span></li>
				<li><span class="title">Item Six</span></li>
				<li><span class="title">Item Seven</span></li>
				<li><span class="title">Item Eight</span></li>
			</ul>
		</div>
		<div class="toolbar placement-bottom">
			<div class="button">Edit</div>
			<div class="button">Save</div>
		</div>
	</div>
</body>

The styles for the div#main would be:

#main {
	width: 100%;
	display: -webkit-box;
	margin: 0 0 0 0;
	padding: 0;
	height: 100%;
	-webkit-box-orient: vertical;
	-webkit-box-align: stretch;
	-webkit-box-sizing: border-box;
	-webkit-transition: all 0.25s  ease-in-out;
	overflow: hidden;
	position: absolute;
	top: 0;
	left: 0;
	bottom: 0;
	right: 0;
}

Although the above arrangement solves the layout problems for mobile interfaces with automatic adjustment with orientation changes, it presents a new problem. That’s the problem of making the data in the content area reachable by the user. You’ll need to add a way for the user to scroll just that area. Normally the whole document would scroll with the browser, with the result that the top part would scroll out of view. Since we’ve fixed the toolbar to the bottom and have the height of the content area control by absolute position affecting its top, right, bottom and left, we need to provide a way to enable scrolling. Actually we could do this very simply using the CSS overflow property: #content { overflow-y: auto; }. However, on mobile Webkit this requires a two finger gesture. Most users would not expect this. They’ll use a single finger and think that the content is not scrollable.

There’s a simple way to provide single finger scrolling with a JavaScript module called “iScroll” created by Matteo Spinelli. This is a great implementation which provides deceleration animation of the scrolling, just like iOS, Android and other mobile OSes. One thing to be aware of when using iScroll, you don’t use it directly on the content container as this would cause that contain to slide up and down over the navbar and toolbar. Instead you’ll need to add an extra div tag inside it and use iScroll on that. iScroll will then enable scrolling of the div inside the content div. There are a number of options, my favorite is for desktop simulation. Here how you would do it:

<div id="content" class="withNavbar withBottomToolbar">
    <div id="scrollwrapper">
        <!-- Content In Here -->
    </div>
</div>
.........

<script type="text/javascript">
    var scroller = new iScroll(’scrollwrapper’, { desktopCompatibility : 
        true });
</script>

This gives you a basic mobile Web interface with a top navbar, a bottom toolbar and a content area with scroll that resizes quickly with orientation change.

Since publishing this article, I’ve created a framework for creating mobile Web apps. It uses many of the techniques explored in my blog posts. You can learn more about the framework by visiting ChocolateChip-UI.com. There are demos you can try in your desktop browser or on your mobile device.

Practical Examples of the Flexible Box Model

If there’s one thing in CSS3 that really gives me warm fuzzies, it’s the flexible box model. What it does is provides a way to create many layout affects that otherwise would require workarounds with float or positioning or both. And there are many types of layouts that without out it would require JavaScript to create the same effect. Sadly, at present the flexible box model is only implemented in Firefox, Safari and Chrome. As it turns out, Microsoft’s IE team approached the W3C standards teams with a proposal for a grid-based layout module. It appears to be based on experience implementing the Silverlight grid layout system, which is a good thing. Silverlight grids are a powerful layout tool and is the most important feature for creating interfaces with Silverlight. Because this grid proposal is very solid, the W3C has dropped all further work on the flexible box model and instead are moving ahead in finalizing the draft for the grid layout module. If you read that speck, you’ll realize how much we need a CSS grid system. For now, however, we do have the flexible box model working in Firefox, Chrome and Safari, as well as on mobile Webkit, which includes iOS, Android, WebOS, and Blackberry. This means that if you’re doing mobile development you can use the flexible box model today to help you implement your layout needs. Once you start using the flexible box model, you’ll hate having to go back to situations where it’s not available.

The flexible box model got a lot of attention from a post by Alex Russell back in August 2009. The good thing is that in his post he showed some of the practical things that the flexible box model addresses and provided a stylesheet with a small subset of the flexible box model properties that people could use right away. His post has been replicated and linked to all over the Web. Unfortunately a lot of people who are not familiar with the spec for the flexible box model are under the impression that what’s in his stylesheet is it. So, with that in mind I’m loosing another stylesheet on the public that allows a greater utilization of the flexible box model. I’ll also give you a layout where a lot of these are in use so that you can see how they work.

Before I get going let me say this. The flexible box model is not perfect. It isn’t supported by IE9 or Opera. And now it looks like the W3C is bypassing it for a more robust grid system. Personally, I’d like to see something like the Silverlight grid system combined with aspects of the flexible box model. That would be the best of both approaches. If you’re targeting the mobile Web, in other words you intend on target Webkit browsers, you can expect robust support for the flexible box model. I doubt it’s going to go away just because the W3C doesn’t include it in any recommendation. I expect it to remain in Webkit for the foreseeable future because it’s already been in use for a number of years.

The flexible box model is about the way a collection of child nodes gets laid out in relation to each other and their parent node. To achieve its layout goals, the flexible box model offers properties for the parent node as well as for the child nodes that determine the layout characteristics of the child nodes.

To work with the flexible box model you need to define its display property to box:

#myDiv {
    display: -webkit-box;
    display: -moz-box;
}

Elements with display set to box can order their child nodes in two orientations: vertical or horizontal. If no orientation is provided, the box defaults to vertical:

#myDiv {
    display: -webkit-box;
   -webkit-box-orient: horizontal;
    display: -moz-box;
    -moz-box-orient: horizontal;
}

Besides defining the orientation, you can also designate what direction the child elements stack, either normal or reverse. A box direction of reverse means the elements display in the opposite order in which they physically appear in the document, so that the first would be last and the last first. By default the box direction is normal stacking order.

Then there is the packing order. This allows you to define how the child elements are packed inside the parent. By default they are packed in from the beginning of the parent. For vertical orientation this is the top and for horizontal orientation this is the left. Other packing orders are end, center and justify. If the packing order is end, for a vertical orientation the elements will stack up from the bottom. For a box with horizontal alignment, the boxes will stack from the right. A packing order of center means that for vertical orientation the child elements will be centered vertical with any left over space displayed equally at the top and bottom. For horizontal orientation a packing order of center means the elements are centered horizontally with left over space equally divided on the left and right. A packing order of justified means that any available space is spread equally between the child elements, for vertical orientation this is vertical spacing, and for horizontal orientation this is horizontal spacing.

Box-align-start

A box with alignment set to "start"

box-align-end

A box with alignment set to "end"

box-align-center

A box with alignment set to "center"

And elements can have their box alignment defined. The default is stretch. This stretches the dimensions of the child elements to fill the parent box. If the alignment is start, for horizontal orientation the elements are aligned to the top of the parent. If the orientation is vertical, they are aligned to the left of the parent. An alignment of end will align elements with horizontal alignment to the bottom of the parent. With vertical orientation they will be aligned to the right of the parent. An alignment of center will align horizontal elements along the horizontal center of the parent and for vertical orientation it will center them along the vertical center of the parent. There is also an alignment of baseline, but this is only for horizontal orientation. It aligns the elements along their horizontal baseline.

Then there is a set of properties that you can define on the child elements. These are flex and ordinal group. The flex property tells the browser how to deal with the dimensions of the child element. If you have three child elements and they don’t fill their parent, giving one of the a value of flex:1 will cause that element to take up all the left over space. If you gave one element flex: 1 and another one flex: 2, the available space would be divided up such that the element with flex: 1 would get one third of the available space and the element with flex: 2 would get two thirds of the available space. Of course the element with no flex value would default to whatever its width is. The ordinal group property allows you to designate groups of elements so that they appear in a different order than their document order. I’m not so sure about the practical use for this property. I’ve thought about it for months and have not been able to come up with a use case where I would need it. But it’s there.

I’ve created a flexible box model stylesheet with classes for all the various box properties. This means you can add the classes to an element to build out the definition you need for an element. I’ve also put together a interactive test case where you can dynamically toggle a number of the box properties and see their effect in real time. You can try it out online if you’re using Firefox, Chrome or Safari, or you can download the working example to dissect and learn.

Multiple Background Images & Animation

Multiple background images allow one to build up complex layered visual effects using one element. In the past such effects would require each background image rendered inside its own element, these being either nested or stacked on top of each other with positioning. When I was working on creating the progress bar example, I ran to a problem where I couldn’t seem to get a specific layer to animate. I could figure out what was going on. Recently, after looking at the code and fiddling with it, I found out what the problem was. Animation of background images works a little differently from other CSS properties. Because multiple backgrounds consists of multiple definitions, it works more like other properties with multiple property values: margins, borders, padding. For example, you can animate all borders on an element, otherwise you can animate a single border. Unfortunately, with multiple backgrounds there is no easy way to single out an individual background image for animation as you can with a border, margin or padding property.

Now the thing to bare in mind when dealing with multiple background images is the stacking order. The first image defined is the topmost image, and the last image defined is the bottommost. Same thing with animations for multiple background images. So, in the case of the animated progress bar, I wanted to animate the bottommost gradient image which consisted of white slanted bars. The rest of the progress bar was fine stable. Well, except that I used a single animation which would instead affect the topmost layer, making it impossible for me to get the stacking layer they way I wanted. Here is the gradient:

background-color: rgb(56,138,213);
background-image:
	-webkit-gradient(linear, 18 0, 0 10,
		color-stop(0.23, rgba(255,255,255,0)),
		color-stop(0.3, rgba(255,255,255,0.8)),
		color-stop(0.3, rgba(255,255,255,1)),
		color-stop(0.7, rgba(255,255,255,1)),
		color-stop(0.7, rgba(255,255,255,0.8)),
		color-stop(0.77, rgba(255,255,255,0))),
	-webkit-gradient(linear, 0 0, 0 100%,
		color-stop(0, rgba(255,255,255,.8)),
		color-stop(0.45, rgba(255,255,255,.05)),
		color-stop(0.55, rgba(0,0,0,.05)),
		color-stop(0.85, rgba(0,0,0,.2)),
		color-stop(0.98, rgba(0,0,0,.5))),
	-webkit-gradient(linear, 0 0, 0 100%,
		color-stop(0.20, transparent),
		color-stop(0.20, rgba(255,255,255,.5)),
		color-stop(0.32, rgba(255,255,255,.5)),
		color-stop(0.32, transparent));

To animate this, I was using a key-frame animation that moved the x axis of the background gradient across the element from 0 to 100% in a loop:

@-webkit-keyframes progressBarAnim {
	0% { background-position-x:  0%; }
	100% { background-position-x: 100%; }
}

If you ran my previous example of the progress bar, it animates as you would expect, except one problem. The topmost gradient layer is the part that should be on the bottom. Yet every time I positioned it to where I wanted it, it wouldn’t animate. In my mind I was thinking that the key frame animation defined above would be animating all the background images. Actually, it doesn’t. It only animates the topmost image background, which is why I had to have the part I wanted to animate on top. Unfortunately I didn’t figure this out until recently. After a lot of fiddling and digging into what was going on with animation of multiple background images, I finally sorted it all out. When defining animations you have to start from the top and work you way down. You don’t have to include an animation for every background image, only down to the layer you need to. But you do have to include all the layers above the animated one up to the topmost one. So here’s my new stacking order for the CSS the way I actually wanted it:

background-color: rgb(56,138,213);
background-image:
	-webkit-gradient(linear, 0 0, 0 100%,
		color-stop(0, rgba(255,255,255,.8)),
		color-stop(0.45, rgba(255,255,255,.05)),
		color-stop(0.55, rgba(0,0,0,.05)),
		color-stop(0.85, rgba(0,0,0,.2)),
		color-stop(0.98, rgba(0,0,0,.5))),
	-webkit-gradient(linear, 0 0, 0 100%,
		color-stop(0.20, transparent),
		color-stop(0.20, rgba(255,255,255,.5)),
		color-stop(0.32, rgba(255,255,255,.5)),
		color-stop(0.32, transparent)),
	-webkit-gradient(linear, 18 0, 0 10,
		color-stop(0.23, rgba(255,255,255,0)),
		color-stop(0.3, rgba(255,255,255,0.8)),
		color-stop(0.3, rgba(255,255,255,1)),
		color-stop(0.7, rgba(255,255,255,1)),
		color-stop(0.7, rgba(255,255,255,0.8)),
		color-stop(0.77, rgba(255,255,255,0)));

And here’s the key frame animation, notice the extra animations for the upper layers:

@-webkit-keyframes progressBarAnim {
	0% { background-position-x:  0%, 0%, 0%; }
	100% { background-position-x: 0%, 0%, 100%; }
}

So remember, in the above key frame animation the first value if for the topmost layer and the last value is for the bottom most layer.

To show the difference in the stacking order, I changed the white stripe that goes horizontally across the progress bar to black. In the wrong stacking order version you can see that its actually behind the white stripes. The corrected version with multiple background animations has it correctly on top:

progress bar with incorrect stacking order

progress bar with incorrect stacking order



progress bar with correct stacking order

progress bar with correct stacking order

Of course, the final product would not be a black streak, it would be white. This was just to show how the stacking order was previously wrong.

CSS Gradients for IE9

This works with Desktop IE9, Desktop Firefox, Desktop Chrome, Desktop Safari, Desktop Opera, iOS, and Android.

Attention! IE9 will not destroy the world, kill babies, or take away your home or job.

Simply put, IE9 is the best browser Microsoft has ever released. Has it caught up to Chrome, Firefox and Safari? No. But that doesn’t matter. It’s still light years ahead of any other version of IE. All of us should be praying every day for IE users to upgrade to it as soon as possible.

Shortly after the initial launch of the beta of IE9, I began testing to see what kind of support it had for all the rich and exciting features CSS3 offers for Web layout and interaction. The earlier beta’s didn’t have much, but with each release it has gotten better. If you’re already using advanced CSS3 for Web development and never bothered supporting IE before, you’ll want to know what it supports and what it doesn’t. Here’s what it supports at present right from the horse’s mouth. In particular, it supports real CSS opacity, multiple background images, box shadows, border radius, background-clip, background-size, background-position, WOFF for Web fonts, RGBA and HSLA color, box sizing, as well as the full suite of CSS3 selectors. The above post also talks about support for CSS3 2d transforms, however, even with the -ms- vender prefix I am unable to get it to work with the present beta (7).
Update: Transforms are working in Platform Preview 6, which is different from the present public beta. Microsoft is taking a two track approach to releasing this: the public beta for general users to test and a platform preview where features are introduced but not necessary finalized.

So what didn’t make it into IE9? First up, the flexible box model. Once you’ve used the flexible box model for layout, it’s as painful as eating glass to go back to using floats and positioning for layout. No text shadow, which is a strange omission considering they have box shadow. No border images. No CSS transitions. The single-threaded nature of JavaScript makes it inefficient for complex animations. Offloading style animations to the browser’s CSS rendering engine frees up JavaScript and allows the browser to use threads and hardware acceleration for better optimization. In my opinion, CSS3 transitions are more important than CSS3 transforms. Since Firefox, Opera and Webkit all support CSS3 transitions to some degree, it’s a odd omission for IE9. No 2d or 3d transforms. As I mentioned before, transforms do not appear to be implemented in the current beta. (Someone correct me if I’m wrong on this.) The thing I love about CSS3 transitions and transforms is that they allow you to create user interactions that make a Web application feel like a native one, blurring the difference between desktop and Web. No CSS3 keyframe animation. If you thought CSS3 transitions were awesome, you be blown away by CSS keyframe animations.

When I look at IE9’s support for CSS3, it appears they decided to pick the low hanging fruit: border radius, drop shadow, multiple backgrounds, etc. But the flexible box model, gradients, transitions, transforms and keyframe animation are the things in CSS3 that really turn your head.

I have no experience working with Adobe Flash. I do have extensive experience working with Microsoft’s Silverlight platform. I love how it enables you to create rich, interactive user interfaces where you can customize every aspect of a control’s look and feel. Chrome, Firefox and Safari’s support for CSS3 enables a similar high level of possibilities for the creation of Web user interfaces. IE9 is attempting to achieve feature parity with the other browsers and is making good progress. But if you want to use the CSS3 features that IE9 doesn’t support, you’ll need to find workarounds.

Presently my main area of focus is the mobile Web on Android, Blackberry 6, iOS and WebOS. That’s a world ruled by Webkit. But I usually make efforts to ensure that my solutions can also work with modern desktop browsers: Chrome, Firefox and Safari. That involves a lot of vender prefixes: -moz, -webkit. And then you need to future proof it by supplying the same property without the vendor prefix. This technique allows browsers that understand the properties, like IE9, to also render them without any extra effort.

I’m going to take one example of an HTML/CSS3 implementation of iOS’s popup dialog box which I originally created for use on iOS devices and show how I got it to render equally in Chrome, Firefox, IE9, Opera and Safari. At the end of this post you’ll find links to try it out online or download it. One thing, I’m not using any image pieces, just CSS3 properties. Here’s the initial state of the page with the popup in Safari and Firefox:

popup Initial state

Here’s the page with the popup in view in Safari and Firefox:

Here’s the same markup in IE9. Notice how it understands border radius, box shadow and RGBA background color, but cannot render the flexible box model layout nor the CSS3 gradients.

ie9 initial state no styleie9 final state no style

IE9’s lack of support for the flexible box model can be resolved by using old-school layout techniques (floats/positioning). But there is no way to fake CSS3 gradients with pngs. When you stretch them they exhibit banding. Since I make extensive use of CSS3 gradients all the time, I felt pressed to find a solution for IE9. After spending some time experimenting with SVG in IE9, I hit on an idea. Using an IE9 specific stylesheet, I would try setting SVG gradients as background images on the element’s that use CSS3 gradients. The technique works quite well. Here’s IE9 with its custom CSS:

ie9 initial state fixedie9 final state fixed

First, here’s a CSS3 gradient used by Chrome, Firefox and Safari:

header {
	width: 100%;
	display: -webkit-box;
	display: -moz-box;
	display: box;
	-webkit-box-orient: horizontal;
	-webkit-box-pack:justify;
	-webkit-box-align: center;
	-webkit-box-sizing: border-box;
	-moz-box-orient: horizontal;
	-moz-box-align: center;
	-moz-box-pack:justify;
	-moz-box-sizing: border-box;
	box-orient: horizontal;
	box-align: center;
	box-pack:justify;
	box-sizing: border-box;
	height: 45px;
	margin: 0;
	padding: 0 10px;
	background-image: 
		-webkit-gradient(linear, left top, left bottom, 
			from(#b2bbca), 
			color-stop(0.25, #a7b0c3),
			color-stop(0.5, #909cb3), 
			color-stop(0.5, #8593ac), 
			color-stop(0.75, #7c8ba5),
			to(#73839f)); 
	background-image: 
		-moz-linear-gradient(top,
			#b2bbca, 
			#a7b0c3 25%,
			#909cb3 50%, 
			#8593ac 50%, 
			#7c8ba5 75%,
			#73839f); 
	border-top: 1px solid #cdd5df;
	border-bottom: 1px solid #2d3642; 
}

As you can see in the above code, we’re defining background images as gradients with a number of color stops. That all a CSS3 background gradient is. As a matter of fact, it’s rendered by the browser as a canvas background image. Since IE9 supports SVG, including as background images, I’ve come up with a way to use SVG gradient images as background gradients. Because SVG is vector-based, the gradients scale without banding. SVG is an XML markup language for describing vector graphics. The HTML5 parsing engine allows SVG to be directly embedded in HTML. But I want background images. By defining the height of the SVG document as 100%, I have an image that will scale to whatever the element is, just like the CSS3 gradient. Here’s the markup that I used to create the gradient for the header. Notice that the SVG gradient has color-stops and offsets like the CSS gradients. They aren’t that different.

<?xml version="1.0" ?>
<svg xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="none" version="1.0" width="100%" 
   height="100%" 
     xmlns:xlink="http://www.w3.org/1999/xlink">

  <defs>
    <linearGradient id="myLinearGradient1"
                    x1="0%" y1="0%"
                    x2="0%" y2="100%"
                    spreadMethod="pad">
      <stop offset="0%"   stop-color="#b2bbca" stop-opacity="1"/>
      <stop offset="50%"   stop-color="#909cb3" stop-opacity="1"/>
      <stop offset="50%"   stop-color="#8593ac" stop-opacity="1"/>
      <stop offset="100%" stop-color="#73839f" stop-opacity="1"/>
    </linearGradient>
  </defs>

  <rect width="100%" height="100%"
     style="fill:url(#myLinearGradient1);" />
</svg>

The document has a height and width of 100%, the gradient is set to expand to 100% and the rectangle is defined with a height and width of 100%. It is possible to turn this SVG image into a datauri and put it directly in the CSS, using use any of the many resources available for datauri conversion. However, the SVG files are just simple text files. If you convert them to datauris, you will not be able to make any changes to them. While putting this demo together I had to constantly tweak the values in the SVG gradients to get them exact. Keeping the SVG files allows you to go back and modify the gradients at any time. Here’s how you use this for IE9:

header {
  background-image: url("svg-gradient.svg");
}

That’s it. IE9 will display the above SVG graphic in a manner indistinguishable from native CSS3 gradients.

For the repeating striped background gradient on the body tag, I’m using a CSS3 gradient with background sizing and letting it repeat across the page. For IE9 I do the same thing, using background sizing on the SVG equivalent to get the same effect.

Like IE9, Opera also does not support the flexible box model nor CSS3 gradients. Notice how Opera renders the demo basically the same as IE9:

Opera initial state no styleOpera final state no style

After creating the SVG workaround for IE9 to mimic CSS3 gradients, I started thinking about Opera’s lack of support for CSS3 gradients. Opera has the best support for SVG out of all the browsers. I therefore tried giving Opera the same CSS that I gave IE9. It worked as well as it did for IE9. You can see the results below:

Opera inital state fixedOpera final state fixed

There is very minimal browser sniffing required to make this work across modern browsers. One stylesheet for Chrome, Firefox and Safari, a conditional comment for IE9 and a browser agent sniff for Opera:

<!--[if IE 9]>
	 <link rel="stylesheet" type="text/css" href="popup-svg.css">
<![endif]-->

<script type="text/javascript">
    var Opera = /opera/i.test(navigator.userAgent);
    if (Opera) {
        var link = document.createElement("link");
        link.setAttribute("rel", "stylesheet");
        link.setAttribute("href", "popup-svg.css");
        document.getElementsByTagName("head")[0].appendChild(link);
}
</script>

Please Note: If you’re going to use this technique in a production environment you should use feature detection because at some point Opera will support CSS gradients. There are a number of ways to accomplish feature detection. Perhaps the easiest is to use Modernizr.

You can try out this demo online or download the source code. Feel free to use the included SVG files as templates for your own gradients.

Oh, and one last thing. I’m using the ChocolateChip mobile JavaScript framework for this demo. Originally I created it to work on mobile devices using Webkit browsers. I therefore provided no support for the JScript quirks of IE. But since IE9 has a completely rewritten JavaScript engine and uses the standard event model and DOM interfaces like the other browsers, ChocolateChip works fine on it without modification. That definitely put a smile on my face.