Canvas is Growing Up

Canvas is Growing Up

Hey, have you ever heard of canvas? No? Well, if you’re paying attention to web trends, you’re about to. Canvas is an HTML tag like any other, but it serves a specific purpose: it is a “drawable region,” basically the code equivalent to a blank painter’s canvas. Developers can use JavaScript to draw colors, shapes, and images to a canvas. In many ways it’s similar to Flash, but unlike Flash, canvas is built into the browser, which means no third-party plugins are needed.

Canvas was first introduced in 2004, but adoption by developers was slow over the first few years of its life: browser support wasn’t great in the beginning and everyone already had the Flash plugin installed, so there was no real reason to move to a new technology. But things have changed. Currently 94% of all browsers worldwide have support for canvas — including mobile browsers (yes, even the iPhone!). Canvas is moving into prime time, and you’re going to start seeing it more and more often. The three industries below are already embracing this new trend.

Gaming

Image Credit: Epic Games

Image Credit: Epic Games

If you played a game on the web 10 years ago, there’s something like a 99.99% chance that game was written in Flash. Today, more and more web-game shops are moving to canvas as their platform of choice.

Many popular game making software packages already have an export-to-canvas option. In fact, Epic Games (developers of the Unreal engine that powers AAA titles like Batman: Arkham Origins) recently announced that their latest Unreal 4 game engine exports directly to canvas. What does that mean? In another year or two, you’ll be playing games as pretty as Borderlands 2 or Mass Effect directly in your browser.

Advertising

Advertisers love their Flash banner ads. And it’s hard to argue with success: animated ads simply work better on average than their static counterparts. Of course, Flash has its downsides: for starters, most mobile phones don’t support Flash, and with mobile accounting for a huge and increasing proportion of pageviews, Flash ads miss a lot of eyeballs.

Enter canvas. It works across the board: desktop, tablet, mobile phone. Google has recently started encouraging the move away from Flash-based advertising by automatically converting ads from Flash to canvas. Soon most animated ads will simply be written in canvas to skip this conversion step.

Mobile

And speaking of mobile, canvas has become a great tool for developing native mobile apps. Not only does canvas work in mobile browsers, but there are lots of tools that convert canvas applications to honest-to-goodness native applications that can be sold in app stores and installed on phones.

Take CocoonJS, for example. Developers can build their game/application/whatever in canvas, in a regular browser window (so it will already run in all modern browsers). Then when they’re ready to take the next step, the developer can simply use CocoonJS to creative true native application versions for iPhone, Android, Kindle Fire and many others.

cocoonjs_cloud

Flash-to-Canvas

If all that isn’t enough to demonstrate that canvas is the medium of the modern web, check this out: even Flash is jumping on board. Flash Professional now has an “export to canvas” option. This allows Flash developers to continue working with a tool they’ve spent years mastering, while still producing canvas applications that run in modern browsers.

5 Tools That Make IE8 Development Suck Less

5 Tools That Make IE8 Development Suck Less

ie-eating-glue

I get excited when I’m given a new website design to build. My mind starts spinning, parsing the various components and figuring out what exciting, cutting edge techniques I can use to make this beautiful design a reality. It’s going to be mobile-first, responsive, clean…

And then the project manager tells me the client wants the site to look great in IE8. And a little part of me dies inside. It was a beautiful dream while it lasted.

Internet Explorer 8 was released in March of 2009, making it 5 years old in human years, 35 years old in dog years, and about 50 years old in technology years. And it wasn’t even a cutting edge browser at the time: both Firefox and Chrome (fresh out of beta) had better JavaScript rendering speed and web standards support before IE8 launched.

When I have to appease IE8, my goal is simple: don’t sacrifice. I’m not willing to build my modern website around old browsers. Instead, I do what I can to make IE8 behave more like a modern browser. The following five tools make that a whole lot easier.

html5shiv

HTML5 introduced a lot of new tags: header, footer, article, aside, and so on. Browsers released prior to the HTML5 spec don’t understand these tags. The html5shiv (or html5shim… the only difference is that one letter) lets the browser know how to handle the tags.

IE8 doesn’t understand HTML5 tags. When it encounters them, it simply removes them, leaving any content within orphaned. That’s the quickest possible way to mess up a nice design. The html5shiv will prevent that from happening. Use it.

Selectivizr

Internet Explorer 8 shipped without support for a lot of pseudo-selectors and pseudo-classes that we take for granted on the modern web. Which of the following rules will work on IE8?

li:nth-child(3n+1) {}
input:checked {}
.thumbnail:hover {}

Out of these three, only the :hover rule will work in IE8. And that’s only if you set a proper DOCTYPE… otherwise, even that one fails.

Selectivizr gets these pseudo-bits working properly in IE8. It does require a JavaScript library (like jQuery, Dojo or MooTools) to work, but most modern websites will already be using one of those anyway.

Respond.js

Media queries are the lifeblood of any modern responsive website. Unfortunately, the term “Responsive Web Design” wasn’t even coined until a full year after IE8 shipped. The result? Internet Explorer doesn’t support the most fundamental tool in the responsive toolkit. This means if you build a site mobile-first as modern practice proscribes, IE8 gets the mobile CSS. And if your client is still using IE8, I can pretty much promise they’re not okay with that. (Of course, my personal opinion is if they’re still using IE8 they must be used to disappointment!)

Respond.js is a polyfill that adds media query support to IE8. This is pretty magic stuff: suddenly, your responsive website works on a 5 year old browser! It relies on JS to detect and trigger CSS switches, and IE8’s JS engine isn’t particularly robust, so the switch isn’t going to be as smooth as it might be in the latest version of Chrome. The good news is, only web geeks like us switch back and forth between breakpoints, so the average user won’t ever notice.

Modernizr

Modernizr runs at page load and adds a bunch of classes to your site’s html tag describing its abilities (or inabilities). You can put together a custom build on Modernizr’s website to test only the features you need, so it can load and run wicked fast. You can also build Modernizr to automatically include html5shiv, which saves you an asset.

When the other tools listed above aren’t quite enough to get the job done, Modernizr helps you clean up the mess by giving you feature-specific classes to code against. Your buttons don’t stand out in IE8 because they lost their drop shadow? Just add a rule like this:

/* Will only apply to browsers that don't support box-shadow */
.no-boxshadow .button {}

Modern.ie

No matter how many plugins and polyfills you throw at your code, eventually you’re going to need to test the site in IE8. And unless you’ve got a 10 year old Packard Bell collecting dust in a corner somewhere, it can be tough to find a copy of IE8 running outside your client’s office.

Enter modern.ie. It’s a website run by Microsoft that offers (among a few other cool things) downloads of Virtual Machines running old copies of Internet Explorer. Just download something to run virtual machines (I use Oracle’s free VirtualBox), a copy of the IE8 virtual machine from modern.ie, and you’ll be up and testing.

What Else?

Do you know of a tool I haven’t mentioned that makes working with IE8 easier? Let me know in the comments.

How to Organize Your Sass

How to Organize Your Sass

If you know what CSS preprocessors are, chances are better than even that you think they’re pretty great – at least when compared with vanilla CSS (and if you don’t know what they are, head over here first).

I started using CSS preprocessors a couple of years ago, and in that time, the way I’ve organized my stylesheets has evolved. And while it might not seem to be a minor point, the way you organize your styles can have an impact on readability, maintainability, workflow and final file size.

My evolution in organization went something like this:

Following the DOM

One of the key selling points of preprocessors like Sass and LESS is the ability to nest CSS rules. So instead of writing this:

.container {
padding: 10px;
}
.container p {
margin: 10px;
color: red;
}

You can write this instead:

.container {
padding: 10px;
p {
margin: 10px;
color: red;
}
}

If you’re familiar with just about any programming language, the nesting helps make it clear at a glance that the rules on the paragraph apply only to paragraphs inside a container.

So, like many before me, I started nesting everything to make things easier to read. However, our increased readability came at the cost of increased complexity, specificity, and code size. When Sass compiled my CSS, it wasn’t unusual for it to contain a thousand rules like this:

.homepage #wrap section#well article p a { text-decoration: none; }
.homepage #wrap section#well article h2 a { text-decoration: none; }

Also, most of the sites I build these days are responsive, which meant (at the time) writing a bunch of absurdly and unnecessarily specific rules for the desktop design, overwriting those rules for the tablet design, and then overwriting those rules for mobile. This resulted in Sass files thousands of lines long – and compiled CSS files that were even longer – effectively negating any readability bonuses.

So what was the solution? Partials!

Breakpoint Partials

Sass partials are Sass files that don’t get compiled directly to CSS: instead, they get imported into other Sass files. So your file structure might look like this:

_colors.scss
_fonts.scss
styles.scss

And the first couple of lines of styles.scss would look like this:

@import “colors”;
@import “fonts”;

The ability to chunk my code seemed like a reasonable way to fix my readability woes. The media query breakpoints I had set up for my responsive design seemed like a natural way to break up my styles – I mean, they’re called “breakpoints.” So that’s the approach I took. My file structure looked something like this:

_desktop.scss
_phone.scss
_tablet.scss
styles.scss

Now instead of one 3,000-line file, I had one 3-line file and three 1,000-line partials. In other words, I had treated the symptoms, but didn’t really fix the underlying problem.

Modular Sass

Eventually, I realized that breaking my tangled Sass spaghetti into functional chunks, or “modules”, was the way to go. Each module of code would affect a specific portion of the site, and would only be as specific as it needed to be. Just because my navbar was inside of my header didn’t mean my Sass needed to reflect that. Instead of nesting like this:

body {
header {
nav.navbar {
ul {
li {
a {
text-decoration: none;
}
}
}
}
}
}

I could easily get away with this:

.navbar {
a {
text-decoration: none;
}
}

Once I started writing my code more modularly, my compiled CSS file sizes dropped dramatically. As a bonus, my shorter code was even more readable. It was much easier to find things in my three partials (desktop, tablet, mobile) as well.

Once I reached this stage, my changes became more philosophical than practical.

Modular Partials

Sass lets you include media queries anywhere in a file, even nested inside the rules they are modifying. It looks something like this:

.navbar {
width: 980px;
@media screen and (max-width: 480px) {
width: 100%;
}
}

Suddenly, having my partials based on media queries didn’t make a lot of sense anymore. I thought about my workflow: if I were going to change something on a site, would I be changing “the mobile version,” or would I be changing “the navbar” across multiple breakpoints? The latter seemed more likely, so I started organizing my partials according to what they were, not when they appeared.

Now my file structure looked more like this:

_article.scss
_footer.scss
_header.scss
_navbar.scss
_sidebar.scss
styles.scss

While this increases the overall size of my Sass a little (having dozens of media queries instead of a few), each partial itself is smaller and more readable.

Mobile-First Modular Partials

Today, I’ve started to take things a little further and thing about the order in which I apply my styles. Generally speaking, mobile designs simpler than desktop designs, and mobile hardware is less powerful than desktop hardware. So why was I writing my desktop styles first and overwriting them with mobile styles, making the least powerful devices do the most work?

So instead of writing rules like this:

.navbar {
// Desktop styles
background-image: url(‘big-fancy-image.png’);
width: 980px;
@media screen and (max-width: 980px) {
// Tablet overrides.
max-width: 760px;
}
@media screen and (max-width: 480px) {
// Mobile overrides.
background-image: none;
background-color: #36c;
max-width: 100%;
}
}

I’m now writing my Sass so that my mobile styles come first, and get overwritten for larger screen sizes, like this:

.navbar {
// Mobile styles
background-color: #36f;
max-width: 100%;
@media screen and (min-width: 768px) {
// Tablet styles.
max-width: 760px;
}
@media screen and (min-width: 980px) {
// Desktop-specific rules
background-image: url(‘big-fancy-image.png’);
width: 980px;
}
}

This way, mobile devices get the styles they need right up front, and can ignore the media queries entirely. This also helps me thing of mobile styles as my base that I can build upon, instead of thinking of desktop as my base that I “strip down” for smaller screens. This seemingly minor shift in viewpoint can have major effects on how you approach your projects.

And this is where I find myself today, though I’m sure it won’t be the final stage in my evolution of preprocessor usage. What about you, Dear Reader? Are you somewhere along this spectrum, or have you found a completely different and awesome process?