Announcing ChocolateChip 3.0

So, I’ve been really, really busy this last year. And then something happened. ChocolateChip-UI, and myself, got acquired by Sourcebits http://www.sourcebits.com. With a company behind me, I started preparing a major update with support for iOS 6, Android Jelly Bean and Windows Phone 8. Then something else happened. Apple held their World Wide Developers Conference and showed of iOS 7.

This was a show stopper. It was also a challenge. I was forced to rethink everything about how ChocolateChip-UI functioned. So, I decided to create a completely new version–from scratch. The result is a smaller, lighter and faster framework than before. The markup is slimmer, and the CSS and JavaScript are also much less. As a matter of face, you can change the look and feel of your app for iOS 7, Android and Windows Phone 8 but just switching the CSS file, that’s all. Your markup and JavaScript stays the same. It’s also easier to customize the CSS. Each OS theme comes with two versions: the default, and at the end, a dark version. The only difference between the two is that the dark version overrides the colors of the default theme. Using this approach, you cold copy the dark theme and change the colors to suit your branding needs.

Since ChocolateChip-UI was acquired by Sourcebits, the repository has moved to: https://github.com/sourcebitsllc/chocolatechip-ui

This new version sports the spiffy new look of iOS 7, and offers the sheet overlay that automatically blurs the underlying contents like iOS 7. This is done purely in CSS, of course. Download load it, and dig into the examples to see how they work. Look in the chui folder for the CSS and JavaScript to see how this was put together. And please visit chocolatechip-ui.com for documentation and tutorials.

About these ads

ChocolateChip-UI 2.1 for Android

ChocolateChip-UI has been updated with a theme styled after the dark Holo theme of Android 4.2 Jelly Bean. ChocolateChip-UI 2.1 allows you to choose whether you want to target iOS or Android. If you create a standard ChocolateChip-UI app for iOS without any custom style modifications, you can turn it in an Android compatible app by just switching out the ChUI files. For iOS you use chui.ios.css, chui.ios.desktop.css and chui.ios.js, and for Android you use chui.android.css, chui.android.desktop.css and chui.android.js. That’s all there is really. ChocolateChip-UI 2.1 enables you to create a custom color branded version by simply replace a half dozen colors in the three Android theme files. Visit ChocolateChip-UI.com to learn more about how to use ChocoalteChip-UI for Android. Most of the magic conversion from iOS to Android is done though CSS.

ChocolateChip-UI 2.0

ChocolateChip Version 2.0
After many months of work, I’ve just launched ChocolateChip-UI 2.0. This was a major undertaking. Everything has been re-factored. Lots of bug fixes for widgets.

The most important thing is that now there is only one version of ChocolateChip-UI for ChocolateChip.js, jQuery and Zepto. Previously I had created a separate version for each library because of their differences. This mean that, in the case of jQuery and Zepto, they didn’t have the same feature set as the original ChocolateChip.js version. And bug fixing was driving me up the walls.

To reduce the complexity and simplify things, I created an abstraction layer so that ChocolateChip-UI works exactly the same with ChocolateChip.js, jQuery and Zepto.

I’ve also done some initial work for accessibility support for screen readers, although more needs to be done.

Check out the latest version of ChocolateChip-UI. Having a unified version mean I can now dedicate some time to creating and Android theme. And after that I intend on create a right to left version for languages using Arabic and Hebrew alphabets.

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.

ChocolateChip-UI for jQuery

ChocolateChip-UI has been ported to jQuery. This means if your preferred JavaScript library is jQuery, you can now use this version of ChocolateChip-UI for creating mobile apps. It uses the latest version of jQuery for DOM traversing, manipulation and Ajax calls. It also includes jquery.tmpl.js to accommodate your tempting needs.

Because ChocolateChip.js was designed to work similar to jQuery, in most cases the port was trivial. However, jQuery’s wrapping of nodes in its object instead of returning an actual node introduced complications that I did run into in the regular version of ChocolateChip.

The end result of the port is that ChocolateChip-UI’s controls work the same as they always have. There are only some slight difference in how callbacks are handled in a couple of places. If you’ve already been using the regular version of ChocolateChip and want to switch to the jQuery version, open up and examine the provided examples to see if you need to change anything. In most cases you won’t.

ChocolateChip-UI for jQuery:
On Github: rbiggs/chocolatechip-ui-jq

To learn more about how to use ChocolateChip-UI, visit ChocolateChip-UI.com.

ChocolateChip-UI 1.0

For those of you who visit my blog looking for how to put together different widgets with HTML and CSS, I’m proud to announce the launch of ChocolateChip-UI 1.0. This is a major update with many refinements, bug fixes and new features, such as titled lists, alphabetical lists, and iPad style popovers. If you like the examples in these blog post and would like to use them, you can download an entire framework with everything in this blog and more, all ready to use. And, if you’re good with CSS, it’s fairly easy to customize the look and feel of the framework.

Visit ChocolateChip-UI.com.

Here’s a list of the types of widgets, controls and layout options that ChocolateChip-UI offers:

  • Toolbars
  • Navbars
  • Buttons
  • Icons
  • Navigation Lists
  • Table Views
  • Selection Lists
  • Switch Controls
  • Popups
  • Popovers
  • Expanders
  • Progress Bars
  • Activity Indicators
  • Actionsheets
  • Tab Bars
  • Segmented Controls
  • Deletion Lists
  • Sliders
  • Carouses
  • Scroll Panels
  • Paging Controls
  • Split Layout

Here’s what some of those layouts and controls look like:

This slideshow requires JavaScript.

Apple’s HTML5 Demo

OK, there’s been so much controversy about Apple’s HTML5 demo page (http://www.apple.com/html5/). Of course, you can go to the Mozilla developer site and find links to their own CSS3 examples like this: https://developer.mozilla.org/En/CSS/Using_CSS_transforms. It only works in Firefox. Hmmm… You can find similar pages on the Opera developer site. Hmmm… You can find similar ones from Google as well, oh and from Microsoft too. Do you see a pattern? Every browser vendor is putting up examples of how their browser renders whatever it is they’re trying to show off. So is it disingenuous for Apple to post their HTML5 demo? No.

All of this started with a blog post by a Mozilla evangelist, Christopher Blizzard: http://www.0xdeadbeef.com/weblog/2010/06/intellectual-honesty-and-html5/

Since Netscape Navigator 6, the Mozilla team for years lead the charge in establishing new standards for the Web. However, in June of 2005 Apple release the source code of the rendering engine for their Safari browser as and open source project known as Webkit. Even before the creation of the Webkit project, the Safari team had managed to create code to pass the Acid 2 test, the first browser to do so. Since then the Webkit team has introduced many new feats for the Web: the canvas tag, multiple backgrounds, background sizing, background clipping, rounded corners, text shadow, box shadow, text stroke, CSS gradients, CSS image masks, border images, CSS transforms, CSS transitions, CSS keyframe animation, as well as support for multi-touch events, etc. David Hyatt from the Webkit team has submitted all of these to the W3C for standardization. Many of these have already been adopted by the Mozilla team into Firefox. That’s why it’s interesting to see Mozilla’s Christopher Blizzard reacting Apple HTML5 demos as follows:

“The demos that they put up are just filled with stuff that Apple made up, aren’t part of HTML5 and are only now getting to the standards process. Part of CSS3? Kind of, sort of, but under heavy development and still in a feedback process.”

Then he goes on to say:

“The most important aspect of HTML5 isn’t the new stuff like video and canvas (which Safari and Firefox have both been shipping for years) it’s actually the honest-to-god promise of interoperability. Even stodgy old Microsoft, who has been doing their best to hold back the web for nearly a decade, understands this and you’ll see it throughout their marketing for IE9. (Their marketing phrase is “same markup” – watch for it and you’ll see it everywhere in their messaging.) The idea that the same markup, even with mistakes, will be rendered exactly the same. HTML5 represents the chance for browsers to work together and find common ground.”

OK, then why are there so many sites that use only CSS3 with -moz prefixes, including stuff on mozilla.com? If he wants one code to work everywhere always, then why have the Mozilla guys tried to persuade the W3C to use different syntax from the CSS3 features that the Webkit team introduced? We’re talking border radius, gradients, etc. If we wanted one code that worked everywhere we would still be using HTML 1.0. Progress is always painful, like a snake outgrowing its skin and shedding it. To me it seems like his biggest gripe is that most innovation on the Web today that is impacting standards seems to be coming from the Webkit team. This has meant that the Mozilla team is now in react mode trying to play catch up or minimalize the perception of Webkit’s advances over the last five years.

If i download the alpha of Firefox 3.7 right now, it’s got built-in support for the stuff that he’s complaining about in the above paragraph, stuff that is still in early recommendation status. Then there’s Mozilla’s decision to dump the HTML5 client-side database API for their own JavaScript based API for database calls. They apparently thinks developers don’t know how or don’t feel comfortable writing SQL. Hmmmm… What kind of developers are those? Sounds like sounds to me like a lot of their developers only know JavaScript so they want a JavaScript API. Check out the reaction of real developers in the comments section of the above link.

So, it seems like the Mozilla team is heading down a path to somewhere. It’s just that I don’t see myself wanting to head down that path. I want innovation that adds new capabilities and makes things simpler. But I don’t want simpler to mean I can do the hard things because simple can only do simple.

Follow

Get every new post delivered to your Inbox.

Join 44 other followers