Posts Tagged ‘HTML 5’

Three Advantages to the Freelance Web Designer Skill Set

7/14/2011 2:54 PM By

The web is an ever-evolving world, and no one understands this better than web designers. Those who have been in the industry since the beginning have seen web pages move from static text-only content to multi-media rich sites to robust web applications.

For freelance developers and designers that have managed to remain relevant in this industry for a long time, much of their success can be attributed to the fact that they are willing to change and learn new skills. Younger web coders need to follow this example if they too want continued employment throughout their career.

Three skills that a designer at any level or stage in their career should seriously consider learning are user experience design, HTML5 and CSS3.

User experience design is nothing new. Web pioneers like Jakob Nielsen have long been preaching the need for designers and developers to create websites that consider human factors, not just technologies. In addition to making a website more friendly to visitors, good UX design also reduces technical problems, avoids unnecessary design elements and expedites development because less time and resources are spent on things that don’t matter to business (and website) goals. Despite the benefits of UX design practices, many designers and developers ignore them.

HTML5 is the latest version of HTML standard, and while it is still in its early stages of adoption there will be a time in the near future when designers will have to move to it entirely. There are some radical changes between HTML4 and HTML5 that effect the way websites are built, so freelance web designers need to be prepared.

CSS3 release has been broken down into modules, unlike its predecessors, where the entire specification was released at once. Web designers and developers can begin to familiarize themselves with the added capabilities and features in modules that are considered stable and expand their skill set as newer ones are released.

Tags: , , , , ,
Posted in Career Resources, Design Resources | Comments Off

Offline Awesomesauce

6/11/2010 12:00 AM By

This set of features is tied into creating web apps and can give your site great staying power, especially with mobile devices like iPhone, iPad, and iPod Touch. The idea is this: Your home page points to a list of files your site needs, and the browser downloads this list of files, keeps them cached, and updates them when possible. If the network becomes unavailable, it switches to the offline version. This one falls squarely under the heading of a web developer, so to those with web designer careers: if you’re looking to spread your wings and broaden your freelance resume, here’s some nitty-gritty you can dig into once you’re feeling up to it.

As far as actually detecting whether you’re online or offline, there’s a flag in the DOM that changes to indicate the site’s current state, but otherwise, everything is up to you. What you do with regards to any data that’s created by your app (if it happens to do so) is entirely left up to you. But first, let’s get things offline.

So, that file referred to above, the one that lists all the things your site needs to be stored offline? That’s called the cache manifest. You point it out like so:

<!DOCTYPE HTML>
<html manifest="/cache.manifest">
<body>
…

However, it must be served with the content type text/cache-manifest. This is pretty easy to adjust in Apache—all you need is this in the .htaccess file at the root level of your site:

AddType text/cache-manifest .manifest

If you’re on lighttpd or nginx, you’ll need to discover how to do that, but most are running Apache, so I won’t get into that. And if your web app spans multiple pages, every page needs to point to said manifest. Now let’s get to crafting this manifest.

First, you need this at the top:

CACHE MANIFEST

After that, you list all of the files of your app. The manifest can have three sections: an “explicit” section, a “fallback” section, and an “online whitelist.” However, if you don’t denote these with their section headers, then the entire list is assumed to be the “explicit” section. Here’s a valid manifest with just an “explicit” list:

CACHE MANIFEST
/style.css
/script.js
/mugshot.jpg

Resources in the “explicit” section are cached locally and used in place of their online versions whenever the network connection is lost. In other words, you could visit your page, your browser would cache these, and then you could disconnect from the network and reload the page, and everything would appear without issue. Now, if your site spans multiple pages, you’ll want to include your HTML documents in that list as well, but if it’s just a single page, it’s assumed to be part of the “explicit” list, since you’re loading everything based on its markup.

Now, what if you have a file that you don’t want cached locally, because it’s only valuable/useful if it’s loaded from the server? A tracking script would be an example. Here we go:

CACHE MANIFEST
NETWORK:
/tracking.js
CACHE:
/style.css
/script.js
/mugshot.jpg

This NETWORK: header denotes the “online whitelist,” which specifies files that must always be loaded from the server and not cached locally. The CACHE: section denotes the “explicit” section, which behaves as described above. The third section, the “fallback” section, defines a page or file that should substitute for something that, for whatever reason, could not be cached. The spec itself provides a rather interesting example for this:

CACHE MANIFEST
FALLBACK:
/ /offline.html
NETWORK:
*

What’s happening here? This piece of text would create a “lazy” application caching mechanism, caching any file you look at. If you’ve never visited the site, your browser sets up a new application cache; if it has, it just adds this page to the cache. As for the FALLBACK: section itself, it’s two filepaths: the file you’re aiming for and the file to substitute it with. So instead of an error message stating that you’re unable to connect, you’re shown /offline.html, in this case, which would have been cached the last time you successfully visited this site. As for the NETWORK: section of this example, it’s using the “*” character, which, as it often does, is functioning as a wildcard for the “online whitelist,” allowing things to be downloaded from the network whenever possible. In other words, that allows for things to act normally.

So, that sets things up to be cached, but there’s more to it than that. We need to handle the flow of events for the DOM; specifically the window.applicationCache object in the DOM tree. This gets a bit more complicated:

  1. Your browser sees the manifest on your <html> element, and fires a checking event.
  2. If it has never seen this cache manifest:
    • It fires a downloading event & begins grabbing the resources specified.
    • While downloading, the browser periodically sets off progress events detailing how far along through the list of files in the manifest it has gotten.
    • Then, after all the files are collected, the browsers sends a final event, cached.
  3. If, however, this page/site has been cached (i.e. the cache manifest in question has been seen before) then things are compared.
    • If nothing has changed, then the browser fires a noupdate event and that’s that.
    • If things have changed, then a downloading event is fired, progress events are periodically set off, and after all the resources are re-downloaded, an updateready event is fired. However, the new version is not yet in use. The user can either reload the page, or you can “hot-swap” by calling the window.applicationCache.swapCache() function via JavaScript.

Now, as always, things can go wrong, but we’re growing rather long-winded here, so we’ll wrap up with a quick discussion on how to test your app. The browser is going to cache things based on HTTP headers, so you’ll need to disable caching on your cache manifest, otherwise your caching will be cached, and then we’ll have gotten a bit too meta. With Apache, you can add these to your .htaccess:

ExpiresActive On
ExpiresDefault "access"

This will disable caching for everything, so for production, you’ll either want to qualify this with a <Files> bit, or have this .htaccess live in a subfolder with just your cache manifest. You’ll also want to change your cache manifest in some way every time you update another file you’re working on. Adding some sort of “version” or “revision” comment to the file, and incrementing it on changes, should do the trick, like so:

CACHE MANIFEST
# ver 10
/style.css
/script.js
/mugshot.jpg

There’s a great deal more, but this is the start of something huge! If you’d like to explore some excellent offline apps, Gmail would be one, but there’s an excellent iPhone app called Glyphboard. You can read more about it on Neven Mrgan’s tumblelog. Happy trails, freelance designers and developers!

Tags: ,
Posted in Design Resources | 3 Comments »

Microdata Madness

6/11/2010 12:00 AM By

So, what are microdata? Well, it’s another way to increase the machine-readability of your markup. It annotates elements in the DOM with name/value pairs, based on a vocabulary you point to. Let’s break this down some more.

The whole idea here is that HTML still isn’t quite providing enough information for what you want to accomplish, and you feel that additional definition to your markup will grant the usability you’re seeking.

Time for an example! You have a list of people, marked up very nicely into multiple <section> elements, with their names in a header element like <hgroup> or <h1>, like so:

<section>
    <h1>Jimmy Crack Corn</h1>
    <p><img src="http://www.example.com/photo.jpg" alt="[me smiling]"></p>
    <p><a href="http://example.com/">weblog</a></p>
</section>

Marvelous. Let’s get some microdata going on. First, we need a namespace, which is really just a URL (it doesn’t even have to be to a page, just a URL all on its own). Then let’s take on properties for each thing we want marked up with microdata. Here we go:

<section itemscope itemtype="http://www.data-vocabulary.org/Person">
    <h1 itemprop="name">Jimmy Crack Corn</h1>
    <p><img itemprop="photo" src="http://www.example.com/photo.jpg" alt="[me smiling]"></p>
    <p><a itemprop="url" href="http://example.com/">weblog</a></p>
</section>

Well, that was easy. What’s happening here, in plain English? Each one says, “Here is the x property of the http://example.com/vocabulary/Person vocabulary, and the value of said property is y.”

Now, I didn’t just make up that particular namespace, it’s real. In fact, if you navigate to http://www.data-vocabulary.org/Person, you can see a list of all the properties defined in that vocabulary. Excellent! The whole idea here is for fellow developers to be using microdata that’s defined the same, and then applications we create can utilize this additional semantic information to improve our experiences on the web.

So, let’s use a more fleshed-out example:

<section itemscope itemtype="http://data-vocabulary.org/Person">
    <img itemprop="photo" class="me" width="457" height="400"
             src="http://images.jeffbyrnes.net/avatars/jeff.jpg"
             alt="[Jeff, circa 2007]">

    <h1>Contact Information</h1>
    <dl>
        <dt>Name</dt>
        <dd itemprop="name">Jeff</dd>

        <dt>Position</dt>
        <dd><span itemprop="title">Web Developer</span> for
            <span itemprop="affiliation">Nobody in particular</span></dd>

        <dt>Mailing address</dt>
        <dd itemprop="address" itemscope
                itemtype="http://data-vocabulary.org/Address">
            <span itemprop="street-address">100 Main Street</span><br>
            <span itemprop="locality">Anytown</span>,
            <span itemprop="region">PA</span>
            <span itemprop="postal-code">19999</span><br>
            <span itemprop="country-name">USA</span>
        </dd>
    </dl>
    <h1>Links</h1>
    <ul>
        <li><a href="http://www.example.com/" itemprop="url">weblog</a></li>
    </ul>
</section>

Looking through this, you can see we’re actually using the http://data-vocabulary.org/Person on the <section>, then applying the http://data-vocabulary.org/Address namespace to the <dd> for the mailing address. So you can nest microdata, in fact!

Lastly, let’s examine some current utilizations of this microdata, because, while adding semantics just for the sake of it is fun, we can all agree we’ve got better things to do with our time. For the moment, none of the browsers have built-in support for microdata, but you can take a look at the currently implemented microformats system, which has plug-in implementations for Firefox (most notably, the Operator extension) that allow you to easily strip out the micro-stuff. This can be very useful to us as users, but for the machines, it’s very useful!

There are a number of other microdata vocabularies already out there, so explore them so you’ll be prepared for all kinds of development and web design jobs. In some ways, they compete with the microformats specifications, but may the best micro-stuff win!

Tags: ,
Posted in Design Resources | Comments Off

Form of… HTML5!

6/9/2010 12:00 AM By

If you caught the Wonder Twins reference in the title, pat yourself on the back. Now, on to examine all the delights that HTML5 can offer us freelance designers and developers when it comes to forms. So, let’s take a look at a basic HTML form:

<form>
    <input name="q">
    <input type="submit" value="Search">
</form>

Beautiful, we’ve got ourselves a search form. Now, let’s jazz it up a bit. How about some placeholder text?

<form>
    <input name="q" placeholder="Enter your query here">
    <input type="submit" value="Search">
</form>

Look ma, no JavaScript! If you don’t see any placeholder text in the form above, then your browser doesn’t support this property yet. Check out Firefox or Safari, though—they rock the house.

Next up, there’s the autofocus property. Traditionally, this is handled via JavaScript, but that’s obtrusive to anyone who doesn’t like this behavior, or finds that it detracts from usability.

<form>
    <input name="q" autofocus>
    <input type="submit" value="Search">
</form>

Now, if you want to ensure the behavior is consistent, you can detect for whether the browser supports autofocus or not, and only run some autofocusing JavaScript if there’s no native support. Here’s an example with JavaScript fallback:

<form name="autofocus-fallback">
    <input id="q" autofocus>
    <script>
        if (!("autofocus" in document.createElement("input"))) {
            document.getElementById("q").focus();
        }
    </script>
    <input type="submit" value="Go">
</form>

Ok, so now we’ve jazzed up our basic text input fields. Now on to some of the “specialized” new input types. Any browser that doesn’t know about these new input types falls back to treating them like plain-Jane text inputs, which is just fine. First up is the email input type:

<form>
    <input type="email">
    <input type="submit" value="Go">
</form>

Now, for browsers that support the new type fully, we get whatever features the browser maker offers: Opera adds a little email icon, Safari and Chrome do nothing, and the iPhone, well, it gives us that email-optimized keyboard instead of the stock one. You know, the one with the “@” symbol in the middle, with the period next to it? Pretty awesome. This is one of those little things that will make your more observant users smile a little and thank you for being so inconspicuously awesome.

Next up, we’ve got <input type="url">. Like the email input type, this one doesn’t really do anything special in desktop browsers, but on the iPhone, again we get an optimized keyboard. This time, it’s the one with the forward slash in the bottom center, instead of the “@” symbol, and the “.com” button instead of just the period.

An aside: On the iPhone, if you hold your finger down on certain “keys,” you get a pop-up menu of extra characters. In the case of the period key on the email-optimized keyboard and the “.com” key on the URL-optimized keyboard, you get a pop-up menu of alternate top-level domains like .org, .edu, etc. Very cool, and quite a time-saver! Try it out on all different keys and enjoy some fancier text.

Now, how about another common form control, like a time- or date-picker? HTML5 has that. Sadly, only Opera has implemented support for it, but this is one of those things that hopefully will catch on soon. We’ve got all of these marvelous options:

  • <input type="date">
  • <input type="datetime">
  • <input type="month">
  • <input type="time"

And a few others as well. For now, since Opera is the only offering this kind of HTML 5 support at the moment, you’ll like want to utilize a JavaScript-based fallback, like so:

<form>
    <input type="date">
</form>
…
<script>
    var i = document.createElement("input");
    i.setAttribute("type", "date");
    if (i.type == "text") {
        // No native date picker support
        // Use Dojo/jQueryUI/YUI/Closure to create one,
        // then dynamically replace that <input> element.
    }
</script>

There are a few other things offered in HTML5’s form offerings, but one last, excellent bit that’s only supported in Opera for the moment (those guys really love forms!) is automatic input validation, within the browser. If you set the type attribute to "email" or "url," Opera runs these through a validator and prevents the form’s submission if the inputed text isn’t valid. Hopefully, Opera won’t be the only HTML 5 browser to support this feature for long.

If you’d like to examine the entirely of what’s now available with input, head on over to the HTML5 spec.

Tags: ,
Posted in Design Resources | Comments Off

It’s All Just Semantic(s)

6/9/2010 12:00 AM By

Now that we’ve settled on how to handle the <head>, let’s touch on some of the new semantic elements in HTML5. First, a caveat: Many of these are not natively recognized by even the most cutting-edge browsers; however, because browsers are designed to deal with unknown elements, they do still render, with the exception of IE, which just falls over when you hand it an unknown element. It will render them, but it doesn’t handle things correctly at all. Thankfully, there’s a rather excellent workaround for IE’s failings that you should add to your arsenal of web design tools.

Rather than explain the long way to do it (feel free to look it up) and reinvent the wheel, we can take advantage of the html5shiv, which enables all of the new HTML5 elements in IE without any fuss. You can even hotlink to the Google-hosted version, and save on bandwidth—freelance designers, rejoice!

So now, we’ve got some great, very cool elements we can use. Here’s the list:

  • <section> – Exactly what it sounds like. The idea here is to grow beyond <div>. Things within a <section> have a thematic grouping, usually with some sort of heading. E.g. A tabbed dialog box, contact information, news items, etc.
  • <nav> – Exactly what it sounds like: a section with navigation links. It should be mentioned, however, that it’s suggested this only be used for the major/main navigation.
  • <article> – A self-contained item that is meant to be consumed not only within the context of your site, but also independently. A blog entry, newspaper article, etc.
  • <aside> – Meant for content that is tangentially related to the content near or around the aside. Pullquotes, sidebars, advertising, etc.
  • <hgroup> – This one has some serious possibility: it allows for h1–h6 elements to be grouped together in a more cohesive fashion. Currently, those elements are part of a single “tree” or outline for each of your pages.
  • <header> – Meant for a group of intro or navigational items, such as a headline (h1–h6 or hgroup), but can also be used for a table of contents or some other introductory element.
  • <footer> – Sibling to the header, this is meant to cap off a section, and can be a very simply set of metadata (a footer to a blog entry, for example), or, in the case of a site’s global footer, contain copyright information, a colophon, etc.
  • <time> – Finally, an element devoted to displaying time! Meant to show the time on a 24 hour clock, or a precise date with the option of the time and a time-zone offset.
  • <mark> – This element is meant to be used as a marking or highlighting element for a short piece of text. Think of it like the web’s highlighter.

So, let’s take a look at some more example HTML. We’re starting off with what we learned last time, adding in the html5shiv:

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="utf-8" />
    <meta name="robots" content="noindex" />
    <title>My Weblog</title>
    <link rel="stylesheet" href="style.css" />
    <link rel="alternate" type="application/atom+xml" title="My Weblog feed" href="/feed/" />
    <link rel="shortcut icon" href="/favicon.ico" />
    <!--[if lt IE 9]>
    <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
    <![endif]-->
</head>

Now let’s take a peek at this:

<div id="header">
    <h1>My Weblog</h1>
    <p class="tagline">Here's my brilliant blog.</p>
</div>

…

<div class="entry">
    <h2>Look at me, Bloggity McBloggerstein</h2>
</div>

Great markup, works marvelously, but we can get more semantic, rather than leaning on the id and class attributes to supply semantic that only humans can perceive. So let’s do this:

<header>
    <h1>My Weblog</h1>
    <p class="tagline">Here's my brilliant blog.</p>
</header>

Better, since now it clearly says it’s a header, to (wo)man and machine alike. But that tagline is still adrift as a <p>, which really doesn’t offer any semantic value. So why don’t we do this:

<header>
    <hgroup>
        <h1>My Weblog</h1>
        <h2>Here's my brilliant blog.</h2>
    </hgroup>
    …
</header>

Now we’ve got some structure! We’ve given our document a far more useful outline/header structure using the hgroup tag. Let’s move on now to one of those entries.

<div class="entry">
    <p class="post-date">May 13, 2010</p>
    <h2>
        <a href="#"
            rel="bookmark"
            title="link to this post">
            Look at me, Bloggity McBloggerstein
        </a>
    </h2>
    …
</div>

The <a> tag is formatted in that fashion to avoid any issues with the code display here and grant easier readability; you’re welcome to put it all on one line, as is the usual custom. Now, just as before, this is totally valid. But what if we did this:

<article>
    <header>
        <time datetime="2010-05-13" pubdate>May 13, 2010</time>
        <h1>
            <a href="#"
                rel="bookmark"
                title="link to this post">
                Look at me, Bloggity McBloggerstein
            </a>
        </h1>
    </header>
    <p>Lorem ipsum dolor sit amet…</p>
</article>

Whoa! Big changes here. Let’s break it down. First, we switched out <div> for the more semantic <article>. Then we added in a <header> element to denote that this is the header of this particular article and changed the completely non-semantic <p> (which, while semantic to you or I by way of its class, isn’t really a paragraph, as the <p> tag is meant to be) to a <time> tag. The pubdate attribute in there states that this is the publication date of this particular section (i.e. <article>); a <time> element without one is merely showing a time/date, and not providing any further information.

Lastly, we’ve converted the <h2> for the article’s title into an <h1>. But wait?! Isn’t that a big no-no? Well, no, because we’ve wrapped it inside a <header> and an <article>. This creates a particular node on the DOM tree, and thus, any h1-h6 tags inside of these will be sorted correctly. To make sure you’re doing things well, make heavy use of the HTML5 outliner to check your page structure. And definitely, if you’re planning on going this route with your headers, don’t leave any naked h1–h6 tags lying about, or things could get a bit crazy.

Now, how about that navigation. Here’s a pretty blog-standard one, in yesterday’s semantic:

<div id="nav">
    <ul>
        <li><a href="#">home</a></li>
        <li><a href="#">blog</a></li>
        <li><a href="#">gallery</a></li>
        <li><a href="#">about</a></li>
    </ul>
</div>

But nothing about this clearly states (besides that id which, again, only a human can read) that this is the site’s navigation. Now, if you look at it rendered, you can tell immediately that it’s part of the site’s navigation, but what if you were disabled? You might use a software mechanism to automatically find (or skip) the site’s navigation. So making your site easily readable to machines as well as people is important. So, let’s make one small change, and then be on our way:

<nav>
    <ul>
        <li><a href="#">home</a></li>
        <li><a href="#">blog</a></li>
        <li><a href="#">gallery</a></li>
        <li><a href="#">about</a></li>
    </ul>
</nav>

As Staples might say: “That was easy.” Onward to the footer! Here’s what we’ve got:

<div id="footer">
    <p>§</p>
    <p>© 2001–10 <a href="#">Bloggity McBloggerstein</a></p>
</div>

Like the navigation, let us just simply do this:

<footer>
    <p>§</p>
    <p>© 2001–10 <a href="#">Bloggity McBloggerstein</a></p>
</footer>

Now that you’ve got your very first HTML5 page, let’s validate this sucker. Here’s the whole enchilada:

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="utf-8" />
    <meta name="robots" content="noindex" />
    <title>My Weblog</title>
    <link rel="stylesheet" href="style.css" />
    <link rel="alternate" type="application/atom+xml" title="My Weblog feed" href="/feed/" />
    <link rel="shortcut icon" href="/favicon.ico" />
    <!--[if lt IE 9]>
    <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
    <![endif]-->
</head>
<body>
    <header>
        <hgroup>
            <h1>My Weblog</h1>
            <h2>Here's my brilliant blog.</h2>
        </hgroup>
        <nav>
            <ul>
                <li><a href="#">home</a></li>
                <li><a href="#">blog</a></li>
                <li><a href="#">gallery</a></li>
                <li><a href="#">about</a></li>
            </ul>
        </nav>
    </header>
    <article>
        <header>
            <time datetime="2010-05-13" pubdate>May 13, 2010</time>
            <h1>
                <a href="#"
                    rel="bookmark"
                    title="link to this post">
                    Look at me, Bloggity McBloggerstein
                </a>
            </h1>
        </header>
        <p>Lorem ipsum dolor sit amet…</p>
    </article>
    <footer>
        <p>§</p>
        <p>© 2001–10 <a href="#">Bloggity McBloggerstein</a></p>
    </footer>
</body>
</html>

Looks great. Next up, we’ll tackle the delights of forms. Fear not, things have improved dramatically with HTML5.

Tags: ,
Posted in Design Resources | Comments Off

Where’s Your <head> At?

6/7/2010 12:00 AM By

The following examines some of the less exciting, but crucial, foundation bits that change in HTML5. In this case, the <head> element, all that it contains, and the few things that precede it.

So, from the top, here’s our example HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<meta name="robots" content="noindex" />
	<title>My Weblog</title>
	<link rel="stylesheet" type="text/css" href="style.css" />
	<link rel="alternate" type="application/atom+xml" title="My Weblog feed" href="/feed/" />
	<link rel="shortcut icon" href="/favicon.ico" />
	<script src="jquery.min.js" type="text/javascript"></script>
</head>

We’ve already covered the DOCTYPE for HTML5: <!DOCTYPE html>. A tidbit about DOCTYPE: it needs to be the absolute first thing the browser sees on the page. If there’s so much as a blank line, your entire page will be rendered in “quirks” mode, as if there were no DOCTYPE at all. So if things are totally wonky, check your source as the browser is seeing it.

Next up is the root element, which, in the case of all HTML documents, is the html element. In the case of our example, it looks like this:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

Again, we can simplify this. We don’t need the xmlns attribute specifying the namespace, as HTML5 is always in this namespace. As for the two lang attributes, we really only need land="en", the xml:lang attribute can be discarded. So now we’ve got:

<!DOCTYPE html>
<html lang="en">

Much cleaner! And now on to the <head>. First off, we’ve got the very important “content-type” meta element. This is important because it informs the browser of the sorts of characters the document contains and allows the browser to properly understand higher-byte characters. You should be using UTF-8 because, well, it can handle just about anything. But we can change the current incarnation into just this:

<meta charset="utf-8" />

Continuing on, we’ll leave the other meta, the “robots” declaration, alone. That one just tells search bots not to index this page, so if this is a production page you’re working on, remove that line. The title remains the same, but then we get down to the link and script tags. In the case of the “stylesheet” link element, it’s referring to an external CSS document, and we can remove the “type” attribute to just have this:

<link rel="stylesheet" href="style.css" />

Same goes for the <script> that’s bringing in jQuery for us, shortening it to this:

<script src="jquery.min.js"></script>

The other two <link> elements refer to an RSS version of the page in question, and the “favicon” for the page. We won’t be exploring any details on those here, but feel free to look them up elsewhere. So, the final output will look like this:

<!DOCTYPE html>
<html lang="en">

<head>
	<meta charset="utf-8" />
	<meta name="robots" content="noindex" />
	<title>My Weblog</title>
	<link rel="stylesheet" href="style.css" />
	<link rel="alternate" type="application/atom+xml" title="My Weblog feed" href="/feed/" />
	<link rel="shortcut icon" href="/favicon.ico" />
	<script src="jquery.min.js"></script>
</head>

And that, my friends, is how to get your <head> on straight. HTML5 is gaining ground quickly, so any HTML5 skills will be invaluable additions to your freelance resume. Next up, we’ll examine some of the new semantic elements available in HTML5.

Tags: ,
Posted in Design Resources | Comments Off

Using the Canvas Element

6/7/2010 12:00 AM By

Right off the bat: this one’s a doozy. We’ll only be touching on the very basics in this post, so if you’d like a more in-depth examination of <canvas>, check out Mark Pilgrim’s Dive Into HTML5. According to the spec, the <canvas> element is “a resolution-dependent bitmap canvas which can be used for rendering graphs, game graphics, or other visual images on the fly.” More simply, it’s a box on your page that can take JavaScript instructions and draw whatever you’d like.

Initially, it’s empty and invisible, so let’s make life a little easier by starting with this code:

<canvas id="myCanvas" width="300" height="225"></canvas>

That gives you an id that you can add some styles to, so go ahead and add a dotted border to #myCanvas with border:1px dotted; in your CSS. Now you’d see a 300x225px rectangle with a dotted border. Marvelous. From here on out, it’s all JavaScript all the time.

So, first, we need to find our <canvas> in the DOM:

var my_canvas = document.getElementById("myCanvas");

From there, let’s draw some simple shapes. So, let’s create a rectangle using this:

function draw_rec() {
    var my_canvas = document.getElementById("myCanvas");
    var my_context = my_canvas.getContext("2d");
    my_context.fillRect(50, 25, 150, 100);
}

And then attach that function to an onclick handler:

<a href="#" onclick="draw_rec();return false">Click to draw a rectangle</a>

All together now:

<canvas id="myCanvas" width="300" height="225"></canvas>
<a href="#" onclick="draw_rec();return false">Click to draw a rectangle</a>
<script>
function draw_rec() {
    try {
        var my_canvas = document.getElementById("myCanvas");
        var my_context = my_canvas.getContext("2d");
        my_context.fillRect(50, 25, 150, 100);
    } catch(err) {}
}
</script>

Clicking the link draws the rectangle inside your <canvas>. Excellent. But what about this little tidbit:

var my_context = my_canvas.getContext("2d");

Well, every <canvas> has a context, which could be thought of as the drawing dimension. Currently, "2d" is the only option, but some vendors are experimenting with 3-D. We’ll see what the future holds.

Finally, we’ll go through the canvas coordinate system. Think of the canvas as a piece of grid paper (you remember high school geometry, right?), except the grid is invisible. So why don’t we actually use <canvas> to visually represent this? Give this a whirl:

<canvas id="c" width=500 height=375></canvas>
<script>
var c_canvas = document.getElementById("c");
var context = c_canvas.getContext("2d");

// Draw the grid
try {
    /* vertical lines */
    for (var x = 0.5; x < 500; x += 10) {
        context.moveTo(x, 0);
        context.lineTo(x, 375);
    }
    /* horizontal lines */
    for (var y = 0.5; y < 375; y += 10) {
        context.moveTo(0, y);
        context.lineTo(500, y);
    }
    /* draw it! */
    context.strokeStyle = "#eee";
    context.stroke();
} catch(err) {}

// and now some arrows show the axes
try {
/* x-axis */
    context.beginPath();
    context.moveTo(0, 40);
    context.lineTo(240, 40);
    context.moveTo(260, 40);
    context.lineTo(500, 40);
    context.moveTo(495, 35);
    context.lineTo(500, 40);
    context.lineTo(495, 45);

    /* y-axis */
    context.moveTo(60, 0);
    context.lineTo(60, 153);
    context.moveTo(60, 173);
    context.lineTo(60, 375);
    context.moveTo(65, 370);
    context.lineTo(60, 375);
    context.lineTo(55, 370);

    /* draw it! */
    context.strokeStyle = "#000";
    context.stroke();
} catch(err) {}

// A little text to label the arrows & coordinates
try {
    context.font = "bold 12px sans-serif";
    context.fillText("x", 248, 43);
    context.fillText("y", 58, 165);
} catch(err) {}

try {
    context.textBaseline = "top";
    context.fillText("( 0 , 0 )", 8, 5);
} catch(err) {}

try {
    context.textAlign = "right";
    context.textBaseline = "bottom";
    context.fillText("( 500 , 375 )", 492, 370);
} catch(err) {}
}

// And the dots showing the minimum & maximum coordinates
try {
    context.fillRect(0, 0, 3, 3);
    context.fillRect(497, 372, 3, 3);
} catch(err) {}
</script>

Whew! You should see this:

An image of the grid the above code draws

One of the things this clearly demonstrates is how much greater the role of the web developer will be as HTML5 grows into its own and changes HTML web design and development, and just how much more integral JavaScript has become. As is the case with most web design tools, there’s much more to using <canvas>, but we’re just here to get you started. Enjoy!

Tags: ,
Posted in Design Resources | Comments Off

Video in HTML5

6/4/2010 12:00 AM By

There’s been a lot of ruckus over support for this particular HTML5 tag, but before we get into that, let’s take a look at how it works.

<video src="MyPrettyVideo.mp4" width="320" height="240" controls></video>

That’s it. This creates a container of the specified size (but it won’t stretch your video like an img tag would, it will center inside the container) and uses the browser’s default controls. You can create your own controls with HTML, CSS, and JavaScript if you’d rather.

There are two optional attributes as well: preload and autoplay. The autoplay one is self-explanatory, but preload merits a little explanation. Specifying it, like so…

<video src="MyPrettyVideo.mp4" width="320" height="240" preload></video>

…will begin loading the video immediately on page load. If, however, to preserve bandwidth you want to negate that, set it up like so:

<video src="MyPrettyVideo.mp4" width="320" height="240" preload="none"></video>

Et voilà.

Now, on to the confusing stuff. First, we need to sort out some things about what makes up a video file. When you think of “AVI files,” “MP4 files,” “Ogg files,” etc., you’re actually identifying the container format, which can actually hold many different types of audio and video tracks.

Each of these tracks has been run through a conversion process, involving a codec, into a particular encoding. Some examples of video codecs are:

  • H.264
  • Theora

And audio codecs:

  • MP3
  • AAC
  • Vorbis

Those are, in fact, the formats we’re going to concern ourselves with.

So, first off, it must be told that there is no one single solution for <video> for every browser. Here’s a quick rundown:

  • Mozilla Firefox (3.5 and later) supports Theora video and Vorbis audio in an Ogg container.
  • Opera (10.5 and later) supports Theora video and Vorbis audio in an Ogg container.
  • Google Chrome (3.0 and later) supports Theora video and Vorbis audio in an Ogg container. It also supports H.264 video (all profiles) and AAC audio (all profiles) in an MP4 container.
  • Safari on Macs and Windows PCs (3.0 and later) will support anything that QuickTime supports. This does not include Theora video, Vorbis audio, or the Ogg container. However, QuickTime DOES support H.264 video (main profile) and AAC audio in an MP4 container.
  • Mobile phones like Apple’s iPhone and Google Android phones support H.264 video (baseline profile) and AAC audio (“low complexity” profile) in an MP4 container.
  • Adobe Flash (9.0.60.184 and later) supports H.264 video (all profiles) and AAC audio (all profiles) in an MP4 container.
  • Internet Explorer has no HTML5 video support at all, but virtually all Internet Explorer users will have the Adobe Flash plugin.

The real issue here actually concerns patents: H.264 and AAC are patent-encumbered (it’s owned by the MPEG-LA group), Theora and Vorbis are patent-free. Firefox and Opera have opted for the patent-free solution; Apple, with Safari and MobileSafari, have gone for H.264 and AAC; and Google supports both in Chrome, but only H.264 in Android.

At the moment, the weight behind H.264 is strong, since it has hardware decoding support, which allows devices to use less CPU (i.e. less battery) when playing. That’s not as big a deal with a portable computer, but a mobile device like an iPhone? A very big deal.

For the moment, the end result is that you’ll need to encode your media twice, once as an Theora video + Vorbis audio in an Ogg container file, and again as an H.264 video + AAC audio in an MP4 container. Then toss in this HTML to seal the deal:

<video width="320" height="240" controls>
	<source src="NewOrleans2006.ogv" type='video/ogg; codecs="theora, vorbis"'>
	<source src="NewOrleans2006.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
</video>

Getting into actually encoding the video file is beyond the scope of this entry, but there are a lot of resources out there; Dive Into HTML5 offers one of the best rundowns on the whole thing, and offers much of the same information provided here.

Many of you freelance designers may be asking, why go through all this trouble when Flash takes less effort and is easier? Primarily because devices such as the iPhone, iPod Touch, iPad, and anything powered by Google Android do not support anything but HTML5 video, which means that it’s important to have on your freelance resume. So get cracking!

Tags: ,
Posted in Design Resources | Comments Off

Getting started with HTML5

6/4/2010 12:00 AM By

So, now that you’ve taken a peek at HTML5’s offerings and have an idea of the state of things browser-wise, how can you put all this great stuff to use on your web design jobs?

First, let’s set out DOCTYPE. Otherwise, every browser is going to do whatever it wants with our HTML, and IE will go into quirks mode, which is a nightmare. This couldn’t be easier:

<!DOCTYPE html>

That’s it. Yes, after the huge DOCTYPE declarations of days gone by, that’s a real pleasure. And, as a point of advice, I’d also state <meta charset="utf=8">, since that’s the best character set to use if you want to include any higher-level characters (e.g. em dashes (—), proper quotation marks(“ ” ‘ ’), ellipses (…), etc.).

So, now we’ve got an HTML5 web page. Great. But with all those crazy browsers, we need to make sure things will work the way we want them to. So let’s check for support!

Except, there’s no way to check for “HTML5 support,” since it’s not one thing, but a whole mess of individual capabilities, as you saw in the previous post. Now, we could certainly test for each individual capability on our own, but why do that ourselves when some smart people have paved that road for us? Take a peek at Modernizr, and grin a big grin. This is a fabulous open source JavaScript library that detects support for a whole slew of HTML5 and CSS3 features. So, go snag a copy of it, and then add this into your <head> area:

<script src="modernizr.min.js"></script>

Obviously, change the src to reflect where you’ve copied the library to on your server. But there’s no other JavaScript to call on—it runs automatically, creates a global object in the DOM, containing a set of Boolean properties (i.e. true/false) for each feature it can detect. As an example, if it finds support for <canvas>, then the Modernizr.canvas property will be true, and vice versa. So you could do something like this:

if (Modernizr.canvas) {
    // Yay for canvas!
} else {
    // no native canvas support. Le sad.
}

We’ll dig into some issues surrounding the <audio> and <video> tags next time.

Tags: ,
Posted in Design Resources | Comments Off

HTML 5 Cheatsheet

6/2/2010 12:00 AM By

Perhaps you’ve been hearing about this HTML5 business and are wondering what it’s all about. Or maybe it came to your attention by way of the Flash vs. HTML5 debate that’s been flying about (fueled mostly by Apple’s continued decision not to provide Flash support for MobileSafari). Regardless, if you’re in the field of freelance web design, know this: HTML5 is the way forward for the web. It’s a dramatic rewrite of the rules for HTML markup, and it offers us not only a far greater set of semantically valuable tools, but it also simplifies the way we include rich content such as audio, video, and web applications. For web apps especially, it offers local storage, offline applications, databasing, and a variety of other excellent tools. This is especially good news for folks looking to add iPhone OS support to their freelance resume.

With that in mind, here’s a favorite little tidbit: the HTML 5 pocket book. It’s a handy-dandy resource that gives you a quick rundown of the common elements of HTML5, and offers a nice “at-a-glance” resource for when referring to the whole spec itself is just too much.

Tags: ,
Posted in Design Resources | Comments Off