Thats the same thing as saying “You know that iPhone app won’t work in IE.” It’s a completely obvious statement.

The web is a platform just like iOS and Android are both platforms (obviously). I (and many others) consider the modern web to be a subset platform to the web.

It makes sense that if you’re creating a web app for the web then you need to support IE which is a major player on that platform. However if you are creating a web app for the modern web then you don’t even need to consider that platform because IE9 is still not a serious player and won’t be for quite some time.

Developers who create native applications for iOS and Android are not bound by what IE can support. They are able and expected to use the latest and greatest apis available. If you want your web application to compete with modern native apps then you must write modern web apps which means not even caring how it works in IE.

CAVEAT: You probably work for someone who isn’t as forward leaning as you and can’t make the complete leap of faith. That’s completely understandable. This message is more directed at personal projects that you want to see have explosive growth.

The engaged masses who will swarm your server like locusts from the cloud and push your app over the tipping point are not using IE—they are using a modern web browser. So meet them half way by building ridiculously kick ass web apps with modern apis.

No tags

On the mysteries of HTML5 <audio>

In attempting to fully grok the potential of HTML5 audio I decided to further explore the API and document the behavior as much as possible. This series of posts will be that documentation. This post relates only to Chrome. I hope it serves you in some way.

I’ve already done a couple projects using the actual audio element but hadn’t actually spent any time messing around with the HTML5 audio API. The API is surprisingly robust and I look forward to hacking it.

Starting at the very beginning you can instantiate an audio object by calling the Audio(); constructor function.

var audioObject = new Audio();
console.log(audioObject);

Open your developer console and see an example here.

You’ll notice at this point the audio object doesn’t have a source. Kinda useless I know. We can fix that with one of two ways.

First we can access the audio object’s src property and change the value to be a path to an audio resource. Like so:

audioObject.src = "music/grace.mp3";
console.log(audioObject);

Open your developer console and see an example here.

Or we can accomplish this by passing in a path to an audio resource at the moment of instantiation. Like so:

var audioObject = new Audio('music.grace.mp3');
console.log(audioObject);

Open your developer console and see an example here.

There it is! If you look in the console you’ll see a pretty complex object. There is quite a bit going on there but right now we’ll just cover a certain property/value pair. Namely the networkState property.

The HTML5 spec describes the networkState as follows: As media elements interact with the network, their current network activity is represented by the networkState attribute. On getting, it must return the current network state of the element, which must be one of the following values:

NETWORK_EMPTY(numeric value 0)
The element has not yet been initialized. All attributes are in their initial states.
NETWORK_IDLE (numeric value 1)
The element's resource selection algorithm is active and has selected a resource, 
but it is not actually using the network at this time.
NETWORK_LOADING (numeric value 2)
The user agent is actively trying to download data.
NETWORK_NO_SOURCE (numeric value 3)
The element's resource selection algorithm is active, but it has not yet found a resource to use.

To start out I’d like to just explore this property a bit. To do that I created some code that creates a new audio object with no source and runs through a couple of the html5 audio api methods to check network state. Let’s explore this in detail.

window.onload = function() {
  // Create a new audio object with no source
  var audioObject = new Audio();
  console.log(audioObject);
  // Check the object's networkstate
  var audioInfo = audioObject.networkState;
  console.log("networkState with no src: " + audioInfo);
  // Give the object a source and again check it's network state
  audioObject.src = "music/grace.mp3";
  console.log("networkState with src: " + audioInfo);
  // Call the object's play method and again check it's network state
  audioObject.play();
  console.log("networkState playing: " + audioInfo);
  // Call the object's pause method and again check it's network state
  audioObject.pause();
  console.log("networkState after pause: " + audioInfo);
  // Get the button and give is a click event listener that logs the object's
  // network state to the console when clicked.
  var networkStateButton = document.getElementById("networkStateButton");
  networkStateButton.addEventListener("click",
          function() { console.log("networkState playing: " + audioInfo); }, 
          false);
}

But before we get there I’d like to point out the first oddity of the evening. If you’ve followed along you might have noticed that if you create the audio object and log it to the console outside of the anonymous function that is being assigned to window.onload then you will see the full object in the console.

If you create the audio object within the window.onload anonymous function and log it to the console you will only see the markup for the actual node. Why is this happening?

Moving on—if we remove the audio object constructor outside of the window.onload and run the script we notice that the first line in the console is:

<audio preload="auto" src="music/grace.mp3"></audio>

How did the console know what the source was when this console.log comes from line 4 and the audio objects source wasn’t assigned until line 9? The expected behavior is that at line 2 there isn’t a source so the element shouldn’t have a src attribute. Much less the actual file path as a value.

To make matters stranger we get the expected behavior if we go to the scripts tab and put breakpoints on lines 4, 7, 10, 13, 15. By the time you press the button to go past the last break point and then look at the console the first line DOES NOT show a src attribute and value. Strange.

Ok, remove those breakpoints and let’s get back to exploring the networkState property.

If you try the above code without passing in a source argument you’ll see that each time it logs to the console a network state code 0. This is telling us “The element has not yet been initialized. All attributes are in their initial states.”

Yet if you look at the audio object in the console you’ll notice that it’s network state code is reading 1. Another oddity.

We can however get our network state console logs to match the audio objects thankfully. When we pass in a source argument at object instantiation time it logs the correct network state code to the console—which is 1. YAY!

If we instantiate the object from within the window.onload anonymous funtion then it logs to the console a series of network state code 3s. It also changes the audio object that it logs out to just the markup of the node which prevents us from being able to check the actual audio object to see it’s network state property.

More soon.

audio

Similar to the iPhone, the iPad has both a portrait and landscape mode. Portrait mode is when the device is taller than it is wider. Landscape mode is when it is wider than it is taller.

Conveniently enough the iPad supports <link rel=”stylesheet” media=”all and (orientation:portrait)” href=”css/portrait.css”> & <link rel=”stylesheet” media=”all and (orientation:landscape)” href=”css/landscape.css”>

With these two simple tags you can serve the ipad appropriate style tweaks for whichever orientation the user happens to be looking at your site or app in.

To understand what I mean check out this example of the iPad portrait and landscape orientation. If you have an ipod hold it in portrait and then landscape mode and you will see what looks like two different web pages.

In portrait orientation the website looks like this:

In landscape orientation the website looks like this:

The HTML code looks like this:

<!DOCTYPE html>

<html>

<head>

<meta charset="utf-8"/>

<title>iPad Portrait and Landscape CSS tutorial</title>

<style>

#container{

width:55%;

margin:0 auto;

}

width:33%;

margin:0 auto;

}

</style><link rel="stylesheet" media="all and (orientation:portrait)" href="css/portrait.css">

<link rel="stylesheet" media="all and (orientation:landscape)" href="css/landscape.css">

</head>

<body>

<div id="container">

<div id="header">

<h1 class="portrait">

Portrait

</h1>

<h1 class="landscape">

Landscape

</h1>

</div><!--end of header div-->

<div id="image">

<img class="landscape" src="images/landscape.jpg" alt="landscape">

<img class="portrait" src="images/portrait.jpg" alt="portrait">

</div><!--end of image div-->

</div><!--end of container div-->

</body>

</html>

The landscape.css file looks like the following:

.portrait{
display:none;
}
html{
background-color:#f6cf74;
}

And the portrait.css file looks like this:

.landscape{

 display:none;

 }

html{

 background-color:#a06346;

 }

If you don’t have an iPad and want to see this work you can simply shrink the size of your browser until it is either wider than taller or vice versa.

more information:

http://mislav.uniqpath.com/2010/04/targeted-css/

http://www.cloudfour.com/ipad-orientation-css/

No tags

No tags

Now that the ipad is launching this weekend without flash video support many of the web’s top video sites are launching an HTML5 stream to make sure their sites work on this new device. This includes youtube, brightcove, NBC, ABC, TED, and many more. This is the coming of age of HTML5 and the beginning of web developers worldwide taking the plunge into the wonderful new world of multi-media that is native to the markup. This is pretty much a starting signal for web developers around the world to start using <video> instead of flash. Never again should your video not work on an iPhone or iPod! Never again will you struggle with complicated hacks to get your video to play. Now you simply add <video src=”" controls></video> and your problems are solved. Right? Hold one second. Last time I checked HTML5 wasn’t even a W3C Recommendation. Which means that there are some parts of it that are not totally complete yet. Which parts you might be asking yourself? Why, <video> of course. Yep, thats right. Even though all of these companies are launching “HTML5″ <video> streams in time for the iPad, the <video> element in HTML5 isn’t even finished. The problem comes with video encoding and licensing. Let’s start at the beginning shall we? Right now there are 2 main ways that people encode their video online. One is Ogg Theora and the other is h.264. Theora is owned by some open source types. They encourage anyone to license and use their algorithm, totally free of charge. h.264 is owned by some big scary lawyer types. They say that to use their encoding algorithm they want to get paid. How much? It varies, but it ain’t cheap. Now that money doesn’t come out of my nor your pocket. No, its companies like Google and Apple that have web browsers or big video sites that pay that licensing fee. They argue that h.264 is the most efficient algorithm to encode with and worth the price if it allows them to remain kings of the cloud. Chris DeBona of Google even said “If [youtube] were to switch to theora and maintain even a semblance of the current youtube quality it would take up most available bandwidth across the Internet.” On the other side of the web is Firefox which is based around an open source ideology. They don’t have any trouble paying the fat licensing fee but they argue that any future startup might not be able to raise that kind of money just to use the h.264 licensing fee thus preventing them from entering the web ecosphere. On that principle alone Firefox has decided to not support h.264 and has went with .ogg instead. There are debates about which encoding algorithm is better. But it appears if those debates are about to be silenced. And that is really what this post is all about. Once upon a time .ogg was the codec that was actually mentioned in the official HTML5 specification. Then on one fateful day it was dropped from the spec all together. At the current moment there is no codec that is mentioned in the specification. It is a figurative black hole at the center of all HTML5 <video>. And it is now being filled with what is becoming the defacto codec—h.264. Last year Google acquired video compression company On2 for around 100 million dollars. Since then many of us have feebly hoped that they would appropriately license their new video codec and then use their overwhelming strength on the WHATWG(Web Hypertext Application Technology Working Group) to make this the new codec in the HTML5 spec. But alas, our hopes and dreams have gone unanswered. So now we have the iPad and “HTML5 <video>” – and the fat licensing fee.

No tags

Registration for the 2010 Google Developer Conference (Google I/O) became available today. The cost is only $100 for students to attend both days! That is just too good of a deal to resist. And seeing as how I only live 45 minutes from San Fransisco….. See ya there!

From the site—”Join us for two days of deep technical content featuring Android, Google Chrome, Google APIs, GWT, App Engine, open web technologies, and more. Google I/O features 80 sessions, more than 3,000 developers, and over 100 demonstrations from developers showcasing their technologies. Talk shop with engineers building the next generation of web, mobile, and enterprise applications.”

There are breakout sessions on HTML5, Chrome, Chrome OS, Wave, and many other things Google.

Last year Google introduced and gave invitations to Wave. They also gave an android phone to everyone in attendance. My intuition is that Google will play off of the 10 in 2010 with regards to the I/O in Google I/O.

No tags

The WHATWG consists of 9 “members” from the 4 major modern browser venders (Opera, Safari, Chrome, & Firefox) and around 500 or so “contributors” (including myself).

Our charter says “Software developers are increasingly using the Web to deploy their applications. User Agents serve as front ends for server-based applications, and W3C technologies — including HTML, CSS and DOM — are often used to build user interfaces to these applications. Along with ECMAScript, these technologies provide a foundation for Web applications.

However, the aforementioned technologies were not developed with Web applications in mind, and Web applications often rely on unintended features not fully described by the specifications. The next generation of Web applications will add new requirements to the development environment — requirements these technologies are not prepared to fulfill alone. New technologies being developed by the W3C and IETF can contribute to Web applications, but these are often designed to address other needs and only consider Web Applications in a peripheral way.”

With that in mind check out Web Applications 1.0

No tags

I am really glad to announce that some of my Adobe Illustrator work is now live on both the W3C & WHATWG HTML5 Specs! It is really an honor to have some of my work in the spec. There will be many many people who read this spec and I hope that my work somehow makes it just a little bit clearer.

Hixie was looking for a small screenshot for the multiple attribute and I happened to be in #whatwg at the time.

Thanks to Ian for the opportunity and please let me know if you need any more graphic work for the spec.

To see my work in the W3C HTML5 spec

Here is my work in the WHATWG Current Work Spec

No tags

2010 is finally here and HTML5 is in last call! I have decided that I will be doing a set of tutorials on HTML5 and some of it’s great new features. And to start out the New Year I thought I would show everyone how to put those great New Years Eve videos online in HTML5 with the new <video> element!

First things first, the HTML5 doctype. Many of you may be familiar with HTML4 and XHTML1′s doctypes. Respectively they are:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”> & <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

Now if you are like me then you have likely never typed that. Traditionally this was the one part of my markup that I would copy and paste. Usually I am a stickler about machine generated code, but with HTML 4 Transitional, HTML4 Strict, XHTML1 Transitional, & XHTML1 Strict, there were too many characters for my feeble mind to remember. So I would copy and paste the doctype and be done with it. But HTML5, oh sweet sweet HTML5 has done away with all that madness. Now we have the serene <!doctype html>. So clean and fresh, like a snowy field. This doctype causes all browsers to render in standards mode! Which is reason enough for you to start using it today. It is also case insensitive, so it can be <!DOCTYPE HTML>. <!doctype HTML>, or even <!dOcTyPe HtMl> if you’re feeling crazy.

Now that we have that out of the way let’s get on with the fun stuff—HTML5 video!

Traditionally if you have wanted video on your website you needed to use some type of extension— most likely flash. This is an issue because flash isn’t native to the webpage. That meant that people needed to download an extension to make your video work. Yes it’s a given that most people have flash installed. But perhaps not everyone does. Also, many mobile devices (including the 1000 pound gorilla in the room—iPhone) don’t support flash. So all of those great videos on your site are broken when you look at them on your shiny iPhone.

HTML5 fixes that issue by introducing the <video> element. Similar to the <img> tag, the <video> tag allows you to simply point to a source file and embed video natively in your markup in a couple of lines of code. And whats even better?! Mobile devices such as the iPhone/iPod touch, android devices, palm webOS devices, and even macs/pcs can watch your video. There is no better choice!

So how do we accomplish this miracle of modern technology? Hold on to your socks….

<video src=”new-years-eve.mv4″> </video>

There it is. Don’t worry, I’ll wait while you triple take…..

Yeah, it’s that easy…..with a couple caveats of course. After all, this is the web.

So how do the browsers feel about the above markup. As always that depends on which browser you are talking about. IE as always says “Bah Humbug”—so don’t even try. Chrome, Safari, & Firefox are a different story however. And this is where it gets a bit (but not much) tricky.

One of the things that is holding HTML5 up from completion is the addition of an audio and video codec from the specification.  There are a couple of choices, but there isn’t consensus. And here is why. Firefox, the bastion of open source doesn’t want to pay the outrageous royalties involved to use the h.264 codec for video and the mp3 codec for audio. They would much rather implement the “open” Ogg theora and vorbis formats for video and audio. There is some debate about whether these codecs are up to snuff for such large scale deployment by people such as Google open source program manager Chris DiBona who recently said “If [YouTube] were to switch to Theora and maintain even a semblance of the current YouTube quality it would take up most available bandwidth across the Internet.” – Ouch

So Google and Apple decided to take the route of supporting h.264 for video and mp3 for audio. My understanding is that they reason that they have already paid those royalty payments and they don’t want to expose themselves to any potential litigation from the ogg people. Sound reasoning I suppose.

But this has left the poor <video> & <audio> tag from fulfilling their grand destiny of native video/audio for all! If you encoded your video in ogg then people who access it from a webkit browser (chrome, safari, mobile safari, mobile android, and palm OS’s browser are all based on the webkit rendering engine) won’t be able to see it. But if you encode the video in H.264 then your open source brethren at Firefox won’t be able to enjoy. What to do…..

Fortunately we have the <source> element! Huh? “There is a src attribute and a <source> element?” you are asking right now. Yep, for <audio> and <video> there is a <source> element that can descend so that you can call more than one source.  Example of our updated markup:

<video controls=”"> <source src=”new-years-eve.m4v” type=‘video/mp4; codecs=”avc1.42E01E, mp4a.40.2″‘> <source src=”new-years-eve.ogv” type=‘video/ogg; codecs=”theora, vorbis”‘> </video>

A couple of things that you might have noticed that I added without telling you. The controls attribute. This is a nice little attribute that allows for a set of browser built in controls for your video or audio. This makes it very simple to add a nice play, pause, and start button. It is a boolean (true or false) value. By default it is not even present, which represents false. So if you leave it out altogether you won’t have any controls. It’s presence represents true. So you don’t need to put controls=”true”— the correct way to write it is controls=”".

Next you will see that there is our new friend the <source> element. I added two types of video here. H.264 for webkit browsers and ogg for firefox. Regarding the type attribute, from Mark Pilgrim’s great work Dive into HTML5 “

“The type attribute looks complicated — hell, it is complicated. It’s a combination of three pieces of information: the container format, the video codec, and the audio codec. For the .ogv video file, the container format is Ogg, represented here as video/ogg. (Technically speaking, that’s the MIME type for Ogg video files.) The video codec is Theora, and the audio codec is Vorbis. That’s simple enough, except the format of the attribute value is a little screwy. The value itself has to include quotation marks, which means you’ll need to use a different kind of quotation mark to surround the entire value.

  <source src="NewOrleans2006.ogv" type='video/ogg; codecs="theora, vorbis"'>

  <source src="NewOrleans2006.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>

Thanks Mark

Now that everything is cleared up. You might also want to add a height and width to you <video> tag. So the final thing looks like.

<!doctype html> <html> <head> <title>HTML5 Video </title> </head> <body> <video controls=”" width=”400″ height=”400″> <source src=”new-years-eve.m4v” type=‘video/mp4; codecs=”avc1.42E01E, mp4a.40.2″‘> <source src=”new-years-eve.ogv” type=‘video/ogg; codecs=”theora, vorbis”‘> </video> </body> </html>

And that’s it! If you check out your page in the most recent versions of firefox, safari, or chrome you will see beautiful HTML5 video!

Go to my website and check out this example of HTML5 video.

There is much more to know about HTML5 <video> and this is only a tiny primer. For a much much more exhaustive look at HTML5 <video> check out the video section in Mark Pilgrim’s amazing work Dive into HTML5 (yes I realize how many time’s I’ve linked to that in this article. It is really that good of an online book).

Or you can always check out what the HTML5 specification has to say about video.

As always I appreciate any feedback (please correct me if you see errors or omissions). Thanks for reading and stay tuned for more in this series of HTML5 tutorials.

No tags