In a fast and furious fifteen minutes, Mark Dalgleish demystifies Web Components by highlighting how, despite its complex appearance, it's actually made up of a suite of technologies providing features we're already familiar with. Once you understand what web components bring to the table, you'll wonder how we ever lived without them. Make sure you also check out the accompanying blog post for full details.

In the past, validating forms in the client has typically required doing some heavy lifting with JavaScript. But you may not know HTML5 changes all that. Browsers now check that the content of an input match its type (and we've got new types like email, url and number to make that even more useful). But, what you might not know about is the pattern attribute, which lets us use regular expressions directly in HTML to specify what format the user's input should have.

In this session, Chris Lienert looks at some of the common regex patterns you can use to validate user input, coupled with some of the many tricks he's learned to help users complete those forms we all love to hate.

Right now creating high quality user experiences in HTML5 is very hard, and to get to where we are today we need a huge bundle of hacks and extreme techniques, many of which Andrew Betts covers in the session.

generally refers to a male with a certain combination of obnoxious characteristics related to attitude, social ineptitude, public behavior, or outward presentation.
Though the common douchebag thinks he is accepted by the people around him, most of his peers dislike him. He has an inflated sense of self-worth, compounded by a lack of social grace and self-awareness. He behaves inappropriately in public, yet is completely ignorant to how pathetic he appears to others.

I think this is a bit harsh for poor AppCache. To stay with the metapohor, Appcache is doing his best, it's just that he does exactly what you ask him to. Even when no one could possibly mean what you said! In this way, AppCache reminds me of one of my favourite ever comics, Mr Logic, from Viz Magazine (probably NSFW due to its extreme puerility).
Mr. Logic's defining characteristic is that he takes everything literally. And as a consequence, he is "a complete pain in the #$%^". He doesn't mean to annoy you, he just doesn't understand nuance, and has no "common sense" (which as my nanna always loved to say is sadly far from common).
This is AppCache to a tee. Ask him to cache the manifest file for your site, so that your site is now preserved in digital amber, never to be updated again, no problem. Why would anyone ever want to do this? Who knows, but he'll do it for you.
Removed the manifest attribute from a cached HTML document? Well, AppCache doesn't check changed documents until you change the manifest file, so 'til then, the old cached version of the HTML file, with its link to the manifest still in place will be used. All very logical. But in many ways counter-intuitive.
I guess what I'm saying, is the fault, dear reader, lies not in AppCache, but in ourselves. Actually, the fault really lies in the rules that have been taught to AppCache. Some of these are just downright infuriating. And perhaps the most infuriating of these is the following.
It starts with the following entirely logical, but deeply unintuitive way in which caching works.

A user visits say webdirections.org, and the browser builds an applicationCache using the cache manifest, caching the index.html file, images, CSS files, and JavaScript files

Subsequently, we change some of the HTML and CSS at webdirections.org, and update a changed manifest file

The user returns to webdirections.org, and their browser immediately uses the cached resources from the previous visit to display the page.

The browser only then checks the manifest file to see if it has changed, and as it has, the browser then downloads the changed resources.

It makes perfect sense! We get the cached version immediately, leaving out any network traffic. Super fast page load FTW. Stale page load not so good.
But, you say, why don't we not cache the HTML file, but cache all the rest.
Well. AppCache has a concept of "master entries". A master entry is an HTML file that includes a manifest attribute in the html element that points to a manifest file (which is the only way to create an HTML5 appcache BTW). Any such HTML file is automatically added to the cache. This makes sense a lot of the time, but not always. In particular, when an HTML document changes frequently, we won't want it cached (as a stale version of the page will most likely be served to the user as we just saw).
Is there no way to over-ride this? Well, AppCache has the idea of a NETWORK whitelist, which instructs the appcache to always use the online version of a file. What if we add HTML files we don't want cached to this? Sorry, no dice. HTML files in a master entry stay cached, even when included in the NETWORK whitelist. See what I mean. Poor AppCache didn't make these rules. He's just following them literally. He's not a douchebag, he's a pain in the %^&*, a total "jobs-worth".
So we are be stuck. We seem to be able to

either add a manifest attribute to the html element of the document, and have the page cached too

or have no appcaching at all for that page.

Where we have the front page of a site that changes frequently, we either have the situation that the page will likely be out of date for users who return (because the most recently cached version will always be used), but we get the ability to cache images, CSS, JavaScript and other resources which don't change frequently. Or we can't cache those resources at all.

Updated

The following needs updating, because it is in fact sadly wrong. While no-store foes have an influence on caching, in the case of master entries, rather than simply not caching a master entry, but caching all the other resources in the manifest, we get an error and no resources are cached at all. So, I'm going to turn my technique into a proposal for how AppCache could be made a little less painful. What I suggest below I think is what should happen when the appCache encounters a master entry served with Cache-control: no-store

Original

But, there is a (little known) solution to this. It's in the HTML5 specification, but currently, it's only supported in Internet Explorer (10+, the first version to support AppCache) and Firefox. Hopefully other browsers and devices will start supporting it, because it's a game changer when it comes to AppCache I think.
You probably know that (but may not know the details of how) browsers have long used HTTP response headers to decide on how to cache content. The server can also send instruction about whether a resource is cacheable or not.
In a nutshell, when a browser requests a resource, the server sends both the content of the resource (for example, a HTML document), and a response header. One of the fields of a response header is Cache-control, which can contain a number of directives, including no-cache, and no-store.

no-cache doesn't in fact instruct the browser not to cache the resource, it instructs the browser to always check with the server before using a cached version of the resource (see, it's not just AppCache who can be a pain)

no-store means don't cache the resource, and always use the online version.

If you're familiar with AppCache, no-store is the equivalent to the NETWORK section of a cache manifest. Now, how do HTTP headers and AppCache work together? What the HTML5 AppCache spec says about HTTP headers is that they should be ignored for the purposes of AppCache, exceptno-store. Which means (in theory), we can send an HTML file with the directive Cache-control: no-store, and it won't be cached in the AppCache! Could it be we have a solution to what has been one of AppCaches most infuriating "features".
With bated breath I created a test case. On Safari and Chrome, no luck. The HTML file served with no-store is still added to the AppCache. But, with Firefox, and IE10, like Daft Punk, we got lucky. These browsers honour no-store. If I change the HTML document, the next time the page loads, all the cached resources are used from the cache, but the new HTML page displays.
So close, and yet so far, I hear you thinking. Because it's not supported across all browsers yet, what good does it do me? Here we'll have to dive a little bit more into AppCache. In browsers that support AppCache, there's a new property, applicationCache, of the window object. This receives various events, including updateReady when the cache has been changed and is now ready to be used. So, we can update a cached master entry as follows.

add an event listener for updateReady

this calls applicationCache.swapCache, which swaps the now stale cache for the fresh one

our event handler now calls window.reload(true) to force a refresh of the page

What's great about our no-store trick is, the cache doesn't need updating, so in browsers which support it, updateReady doesn't fire! So we have a bullet-proof way of making sure frequently changing HTML pages aren't added as master entries to the appcache in browsers which honour no-store, as well as auto-refreshing these pages to ensure the browser uses the most up-to-date version in browsers which don't (yet) honour the no-store directive.
Which hopefully makes the AppCache just a little bit less of a pain in the #$%^ to deal with!
Again note, sadly this is not what actually happens
Here's what does happen when a master entry is served as no-store

Chrome and Safari ignore no-store, and build the cache including the master entry

Firefox from what I can tell silently fails, and doesn't build a cache at all

Internet Explorer (10) fires an error, and doesn't build a cache.

Moral of the story: don't serve HTML with no-store if you want appcache to work!

Last week we looked at one of HTML5's syntax quirks, the fact that you don't need to quote attribute values (unless the values contain a space or as is less well known one of a number of other characters). This time, some more about some of the subtle side effects of HTML5's laxer syntax rules.

Let's start with a quiz. Are both of these valid HTML5 documents (that's right, complete documents, not just fragments)? Neither? Only one? Which one? Why?

<!doctype html>
<title></title>

<!doctype html>
<html>
<head></head>
<body></body>
</html>

And the answer is that the first is valid, the second not. Which is very counter-intuitive. Unless you know the rules of HTML5 inside out, it's something you're unlikely to guess. In HTML5 there is precisely one required element. It's not html or head or body. It's title.

That's Google's 404 page. No head or body elements. (also no pesky closing tag on those ps). I guess if you're serving this millions of times a day, a few bytes count (though I wonder why then use up 22 precious bytes for those two ins) elements?

But in and of itself this isn't all that interesting. What is interesting is this question. If in the style element we had

body p{
color: red
}

Would the paragraphs have red text? The (again counter-intuitive) answer is yes! How so? How can the paragraphs be descended from a body element if we didn't include a body in our markup? Well, that's where HTML5's storied parsing algorithm comes in. Where html or body or head are missing, the parser inserts them into the DOM. Let's take a look at this in action in the Firefox Developer tools

The parser inserts missing elements into the DOM

Yes, HTML5's parser can make sense of almost any way we as web developers can mangle our markup. But unless you really know what you are doing, and really really need to save a few bytes, why not stick to the slightly more verbose, but far better understood approach.

One of the benefits often touted for HTML5 over XHTML is what I once heard Paul Irish describe as its "loosey goosey" approach to syntax. No longer the strict taskmaster that XHTML was, we can now do all kinds of cool stuff like leave off closing li and p tags, and of course, we no longer need to quote attribute values. Think of the bytes saved! The billions of developer hours saved no longer having to type " or '.

Except.

You can't always leave off quotes from attribute values. Think about an element with two class attribute values.

<p class=important warning>

Here the browser actually see two attributes, class=important and a boolean attribute warning (which it doesn't understand, but that's not a problem, making up your own attribute names is what all the kids are doing these days (I'm looking at you Angular!))

So, we need to quote attributes values when they include spaces. But that's not all. Unquoted attribute values must also not contain any of these characters:

", ', =, >, <, or `. Sure, you can have %, or # or £, but no backticks please!

If it does, then quote you must. Think about all sorts of URLs for APIs, or into CMS content, or to blog posts. A = is very likely to crop up in these URLs. So, why not simply quote all attribute values? One basic rule that will never get you into trouble, and cost you maybe a few dozen bytes a page at most.

BTW, the same rule applies to CSS values that take urls. We only need to use quotes around the URL value when it includes one of the same characters. But why not always again use quotes? Simple pattern, always works. And, the same applies to the value of attribute selectors. a[attr="attrvalue"] will always be correct. a[attr=attrvalue] won't be if attrvalue contains spaces or one of our magic characters.

You could try to remember all these rules - go for it! But sometimes it just pays to be strict.

A couple of weeks ago we started a series on how you might implement some of the more notable design effects in iOS 7 using purely web technologies. In the meantime, it's been noted elsewhere that this may be difficult and perhaps impossible to do. I'm here today to tell you otherwise! Well, at the least the impossible part.

Today we are going to look at one of the features that got some attention, the use of parallax on the homescreen to create a sense of depth This is one of the words that Apple used to describe their new, supposedly "flat" design.

If you've not seen this in action, Gizmodo took Apple's video and made an animated GIF version, which you can see below.

We've all seen parallax effects before. They're a staple of 2D, and "2.5D" games, to add the perception of distance between objects. For the last couple of years we've also seen the use, and abuse, of parallax and scrolling in web page design.

So, what is going on to create what appears at a glance to be a 3rd dimension? Well I'll let you in on a little secret that anyone who has installed the iOS 7 beta will have already noticed. The effect is particularly impressive when viewing a 2D rendering (such as a video) of the effect. When you see the same effect on a device, and then watch a video of the effect on the device, I think you'll find the video more compelling.

What is parallax?

Look out the window. Objects at different distances move at different relative speeds. The closer an object, the more quickly it appears to be moving, and the further away it is, the more slowly it appears to be moving.

Documentary film makers, who often have only photographs or paintings to use as their primary visual material, commonly make use of this to trick our eyes into seeing a 3rd dimension. It's called "the Kid Stays in the Picture" effect. It tricks our brain that we are looking at a 3D scene, by using different relative motions.

In the iOS 7 homescreen situation, we have two levels of depth. The surface of the screen, and the background image. If you pay attention to the animated version, you'll see that the icons don't move relative to the surface of the screen. The effect is created purely by moving the background image relative to the icons. Notice how as we tilt the phone from right to left (on the screen) the background image moves toward the right, and as the phone tilts from left to right, the image moves back to the left. Why does this create a sense of depth? For the moment, to keep things simple let's just worry about rotation around a line running from the top to the bottom of the screen through its middle as the device is facing toward us. That is, when we tilte the phone left and right.

Imagine we were looking down on the scene from above

looking down on the scene

The vertical arrow is the line of sight. Now, let's rotate the phone to the left

looking down on the scene, having rotated the phone to the left

I cheated a bit here, to make the maths a little bit simpler, but the idea is more or less the same. Instead of the device rotating, I've moved the observer, but their line of site is still the same - directly between the two icons in the middle of the screen. So, the icons don't appear to move relative to the screen, but the background figures do. But just how far are the figures apparently shifted?

the original and new lines of sight make a right triangle

I'm making the observation that the original, and adjusted lines of sight of the viewer make a right-angled triangle. Which is excellent, because the trigonometry (don't be put off!) of right-angled triangle is simpler than arbitrary triangles.

the trigonometry of the triangle created by the two lines of sight

OK, so if your high school maths is a little rusty (don't worry, I have a degree in mathematics and I had to look this up!) here's what we have.

We have the original line of sight (we've labelled that a, which you might remember as being the adjacent side.

We have our new line of sight, labelled h for hypotenuse

we have the angle between the old and new lines of sight, θ (pronounced theta, for some reason, angles are usually labelled using Greek letters).

We have the distance at right angles from the hypotenuse to the adjacent side, labelled o for opposite (because it is the side opposite the angle we know, θ)

And we have enough information to calculate o, should we know the length of a, using our high school trig

o = a*tan(θ)

We know θ, it's the angle we've rotated the screen (and we'll see in a moment how we'll use the deviceOrientation event to get this angle as it changes). But how do we know a? Well, here's the cool part, we just make it up. The larger the value of a, the further 'away' the background figures will appear to be (so the larger o will be.) In particular what this means is the relative movement of the background figures behind the icons is not linear, but goes something like this, where the background is 50px away

degrees

apparent movement (px)

0

0

5

4

10

9

15

13

20

18

25

23

30

29

35

35

40

42

45

50

50

60

55

71

60

87

65

107

70

137

75

187

80

284

85

572

90

∞

Note how the movement left or right increases dramatically as we get closer to θ = 90 degrees. Of course it can never be 90 degrees.

In short, the more we rotate the device, the more the background image appears to move.

Creating the effect

So, now we have a basic model for how parallax works, how can we use this to emulate the parallax effect? Here's my idea

we'll have an element that emulates the homescreen of the device

the homescreen element contains the application icons

we'll have a background image for that element, like the one in Apple's animated example.

Now we have our basic content

when the device rotates to the right, we calculate how far to the left our background image should move, which will change depending on how far "away" we want the background to be

when the device rotates to the left, we calculate how far to the right the background should move

we then use background-position to move the background image relative to the element.

There are other ways we could do this, with their own advantages. We could have the background as a separate img element, then use CSS3 translate3D to move this element to the left and right. This would have the advantage of enabling the device's GPU to take care of moving the background. But we'll stick to background-position, as it's the simplest approach.

Yes, not particularly interesting, yet. Now let's think about moving the background image.

By default, a background image is positioned with its top left hand corner in the element's top left hand corner. But this isn't what we'll want, because as soon as we rotate to the left, the image moves to the right, and so we'll see "through" the element on the left of the background image like so.

the homescreen with image moved to right

So we'll need to make sure that our image is wider than our element, and positioned not in the top left hand corner. We could use the CSS3 property background-size to achieve the first, but we need to be careful. Suppose we decided to make the width of any background image 150% the width of the element. We'd use background-size: 150% to do this, but this then scales the height of the element to maintain the image's proportions. For an image that is inherently narrower than the element's current size, then the height will increase. But if the image is inherently wider than 150% of the width of the element in pixels, then the height of the image will decrease, and we may end up with this situation.

the background image is scaled to 150% of the width of the element, but as it is wider than this inherently, the height is reduced.

Better to have an image that will in all likelihood be taller and wider than the element's width and height (yes, in a responsive world, this will present its own challenges).

The second part is a bit more straightforward. Surely, we'll just use background-position: center? Sadly, not quite so simple. Because we'll be changing the background-position to achieve the effect. So, what we do is position the background image using JavaScript and the DOM, so that its top is half the difference between its intrinsic height and the current height of the homescreen element above the top of the element, and similarly, its left is half the difference between its width height and the current width of the homescreen element to the left of the element. Essentially, the center of the image will be in the center of the element.

Positioning the background image.

We'll do this by adjusting the background-position of the element once the page has loaded (as is often the case, this is the most complicated part of the process, even though it's only peripheral.)

function setupBackgroundImage(element) {
//set up the background image for the element
//call this when the page loads
var imgURL = window.getComputedStyle(element).backgroundImage
//get the current background-image URL
//bg image format is url(' + url + ') so we strip the url() part
imgURL = imgURL.replace(/"/g,"").replace(/url\(|\)$/ig, "");
//now we make a new image element and set this as its source
var theImage = new Image();
theImage.src = imgURL;
//we'll set an onload listener, so that when the image loads, we position the background image of the element
theImage.onload = function() {
positionBackgroundImage(element, this.width, this.height)
}
}
function positionBackgroundImage(element, imageWidth, imageHeight) {
//this is called when a backgroundImage loads
var elRect = element.getBoundingClientRect();
xOffset = -1 * (imageWidth - elRect.width)/2
yOffset = -1 * (imageHeight - elRect.height)/2
//these are global variables as we want to remember the offsets for later
//ideally we'd not use global vars, but done like this for simplicity
element.style.backgroundPosition = xOffset + "px " + yOffset + "px"
}

Now we've set up our elements, our homescreen background image, and we've worked out our algorithm, we're ready to go.

Adjusting the background image

OK, at this point, we'll pretend we already know the current rotation of the device (we'll cover how we get that next). Let's assume that each time the device changes its orientation we get an event. Which in fact is exactly what happens. We'll create an event handler for this event. As we're responding to a change in the orientation, we'll call this 'orientationChanged'. Here's what this will need to do (again we'll concentrate on just the rotation around the Y axis of the device to keep things simple)

calculate the tan of the rotation around the Y axis (in radians, not degrees) (this was θ in our earlier discussion). More on radians in the notes

calculate the relative movement of the background image (a*tan(θ))

adjust for the xOffset we calculated earlier based on the width of the background image and the element

set the background-position of the element to this value

And here's that in JavaScript

function orientationChanged (xOrientation, yOrientation) {
var rotYTan = Math.tan(yOrientation*(Math.PI/180))
//calculate the tan of the rotation around the Y axis
//Math.tan takes radians, not degrees as the argument
var backgroundDistance = 50
//set the distance of the background from the foreground
//the smaller, the 'closer' an object appears
var xImagePosition = (-1 * rotYTan * backgroundDistance) + xOffset + "px"
//calculate the distance to shift the background image horizontally
//the X and Y seem swapped, but X in device rotation terms is around a line through the middle of of the screen from left to right, so its correct
homescreen.style.backgroundPosition = xImagePosition + " " + 0;
//set the backgroundimage position to xImagePosition
}

So, now we are moving the background image left or right depending on the rotation of the device. But how well does this work? Well, you can test it out yourself. Here's an emulation, which uses CSS 3D transforms, as well as a version you can run directly in a device. What do you think? In the emulated version, you might think the 3D effect is simply coming from the use of CSS 3D, but if you set the distance to zero, and then rotate the device, you'll see that there is no parallax effect. The greater the distance you set, the more pronounced the effect.

The main event

But so far, we've not discussed how we actually get this mystical orientation information. As we mentioned briefly we'll be using the deviceOrientation event widely supported in mobile devices in particular.

alpha is the rotation around the z-axis (an imaginary line coming directly out of the screen). Positive alpha is rotated to the left, negative alpha is rotate to the right. This seems counter intuitive, but our frame of reference is looking upwards, so to the left is clockwise in this frame of reference, and clockwise is positive, anti-clockwise negative.

beta is rotation around the x-axis, a line left to right across the device when it is laid flat on its back. Positive beta is when the device is tilted away from you, from 0 degrees to 180 degrees (screen facing downwards). Negative alpha is when the device is tilted toward you (again, from 0 degress to -180 degrees, which is facing downward)

gamma is rotation around the y-axis, a line through the middle of the device away from the user. Positive (from 0 to 180 degrees) is tilted to the left. Negative, 0 to -180 degrees, is tilted to right

What the X?

Ok, so there's a reason we've still only worried about movement left to right. When you look at a screen, the neutral position in terms of rotation around the y axis (that is, tilted to left or right) is clearly with the screen perpendicular to the user's line of sight. But, what's the neutral position for the tilt forward and backwards? Lying on its back? Probably not. Perpendicular to the surface of the earth? Also probably not. When you hold a phone or tablet, it's likely to be somewhere between these two. In fact, right now, you're holding your device at an angle of

To simplify matters, let's say that the user will typically hold a device at around 45 degrees. So, we'll make this our "neutral" position for the parallax effect. Which means, we'll subtract 45 degrees from the current rotation when calculating the position of the background image up and down.

Dis-orientation

What's also interesting is that if we change the orientation of the screen, from landscape to portrait, the beta and gamma values from the orientation event are still relative to the device. So, we need to now take into account whether the screen has been flipped (maybe even upside down) before doing our calculations.

First, we need to know what the current screen orientation is. We do this with the screenOrientation property of the window. This is the current rotation of the screen, where 90 degrees is rotated to the right, 180 degrees is turned upside down, and -90 degrees is rotated to the left.

When turned upside down (screenOrientation === 180), we'll reverse the beta and gamma values, by multiplying them by -1. Effectively, we're treating up as down, and down as up, left as right, and right as left.

When rotated left, screenOrientation === -90, we'll swap gamma for beta, and the reverse of beta (-1 * beta) for gamma. Essentially, swapping left and right for forward and back, back for right, and forward for left.

Then we continue as before, and now regardless of the screen's orientation, we still have our parallax effect. We've actually gone one step further than the real iOS homescreen, at least on the iPhone, as on the iPhone device rotations don't affect the orientation of the homescreen.

Technologies covered in this post

Browser Support via Can I Use

Notes

In school, you most likely did trigonometry and geometry with angles in degrees. Grown up math is typically done in radians, where 2π radians is 360 degrees. Since device orientation gives us rotation in degrees, we covert to radians by multiplying the number of degrees we have by π and then dividing by 180.

a development environment based on WebKit technologies, supporting application development on the Wii U system using HTML5, JavaScript, and CSS. It also supports the Wii U GamePad controller, Wii Remote controllers, and JavaScript extensions such as video playback. With the Nintendo Web Framework, development times will be reduced and Wii U applications can be easily developed using common Web technologies

We can only hope that games built with the framework will also be able to be run (legally and technically) on other platforms, at least within reason.
Regardless, developing games for this once exclusive platform promises to become a whole lot easier, and more democratic. And if you think games built with HTML5 aren't a reality, the entire UI for SimCity is built with web technologies

the whole UI is done in javascript running a custom version of webkit. :D

People mentioned in this post

Companies mentioned in this post

"
["post_title"]=>
string(20) "Wii Games with HTML5"
["post_excerpt"]=>
string(0) ""
["post_status"]=>
string(7) "publish"
["comment_status"]=>
string(4) "open"
["ping_status"]=>
string(4) "open"
["post_password"]=>
string(0) ""
["post_name"]=>
string(20) "wii-games-with-html5"
["to_ping"]=>
string(0) ""
["pinged"]=>
string(0) ""
["post_modified"]=>
string(19) "2013-06-14 11:40:38"
["post_modified_gmt"]=>
string(19) "2013-06-14 01:40:38"
["post_content_filtered"]=>
string(0) ""
["post_parent"]=>
int(0)
["guid"]=>
string(36) "http://www.webdirections.org/?p=4745"
["menu_order"]=>
int(0)
["post_type"]=>
string(4) "post"
["post_mime_type"]=>
string(0) ""
["comment_count"]=>
string(1) "0"
["filter"]=>
string(3) "raw"
["post_category"]=>
string(1) "0"
}
[12]=>
object(WP_Post)#1014 (25) {
["ID"]=>
int(4739)
["post_author"]=>
string(1) "3"
["post_date"]=>
string(19) "2013-06-13 14:02:23"
["post_date_gmt"]=>
string(19) "2013-06-13 04:02:23"
["post_content"]=>
string(4869) "Remember the X in XML, and XHTML? It of course stands for extensible, the idea that these languages allow for their users to build upon them, rather than waiting for some standards organisation to add new features.
With HTML5, extensibility of the markup language pretty much went out the window, despite the criticisms of many (including it must be said, me).
But extensibility is deeper than simply new language elements. As the web platform becomes increasingly sophisticated and powerful, it has also increasingly been seen as a competitor to "native" platforms such as iOS and Android. And where these platforms iterate quickly, with major new versions in the timeframe of each year or even more frequently, the web is seen to iterate far less quickly. We as developers need to wait not just for new browser versions (which in the case of desktop versions of Chrome and Firefox at least, is in the order of weeks), but whole new features of the DOM, CSS, and HTML, which typically is in the order of years.
Many have been frustrated with this pace of change, anxious that it puts the web at a disadvantage over the commercial platforms with far faster evolution. But the suggestions as to what might be done about it (for example, that the web should have "a single source repository and a good owner to drive it") have not been on the whole realistic, or even really solutions to the challenge at all.
Now Yehuda Katz, Alex Russell, and numerous other high profile web developers, browser developers and specification authors have suggested a new way forward, summarised in The Extensible Web Manifesto.
In essence, the goal is to have new browser features implemented at a lower level, as DOM APIs, accessible through JavaScript (these might also be described as "imperative" features), as opposed to more high level, declarative features accessible at the level of the markup language.
Katz describes the situation of offline web apps, and how the approach to building a high level, "magical", declarative feature, AppCache, went wrong, and how developing this functionality at a lower level might have avoided the problem, by empowering developers to build the solution they needed for their use cases.

We could have built offline support as a new JavaScript capability, with the manifest feature built on top of that capability. Then, when the manifest failed Facebook (and lanyrd, and the Financial Times), they could have dropped down into JavaScript and written something that worked for them.
Instead of placing our faith in central planning, we should let the ecosystem of web developers build the features they need, on top of low-level capabilities exposed efficiently and securely by the browser.

Will this be the approach to developing new web features we see more of? With members of the W3C's Technical Architecture Group, or TAG, such as Alex Russell, Anne van Kesteren and Marcos Caceres firmly on board, along with the inventor of JavaScript, Brendan Eich, and numerous influential W3C and Browser vendor figures among others, I think it's a fair chance.
But with an approach that at least superficially seems at odds with HTML's self appointed benevolent dictator for life Ian Hickson's, where does that leave the WHATWG in all of this?

As much as they affect JavaScript, state, event handling, and default browser behaviour also impact HTML and CSS in the choices we make, optimizations we can take advantage of, and the architecture of our applications as a whole.

As a web developer, you've probably seen emerging HTML5 technologies and APIs like DeviceOrientation and WebRTC (Web Real Time Communications), and thought "wow they look cool, but they are only for hard core gaming, video conferencing, and other such stuff, not for my every day development". I'm firmly convinced that taking advantage of these capabilities is going to open up fantastic potential for developers, both for existing web sites, as well as entirely new web experiences. In this article, I want to talk about the latter.

When we first moved into the Web Directions office, we had an old iMac (I mean old) set up as a motion activated security camera. One of the guys who used to share the office with us had built a very simple app that when it detected movement (I'm assuming by analysing images) it sent a photo to a specified email address. Sadly, the Mac and app went when the guy moved out. I say sadly, because a few months back we could really have done with this to help catch whoever came by one night at 3am, smashed in our door, and took several devices.

But then it occurred to me this is something we can build in the browser. All we'd need to do was

Detect motion (with the DeviceMotion API (though it's a bit more complex than this in practice as we'll see in a moment)

Capture an image using WebRTC and the HTML5 canvas

Send the image via email (we won't cover that today, as it is really more a server side issue, but there's all kinds of ways you could do it) to ourselves.

So, let's get started. We'll begin by detecting motion.

Detecting motion

You're probably thinking, there's an HTML API for this, DeviceMotion. Which is exactly what I thought. The problem is, while well supported in mobile and tablet browsers (these devices almost universally have gyroscopes for detecting their orientation in 3D space, and accelerometers for detecting their acceleration in 3D as well) it's not supported in any desktop browser. But, there is a related API, DeviceOrientation which reports the angle at which the device is in 3 dimensions, and which is supported in Chrome, when the laptop it is running on has the sensors to provide this data (I know that the MacBook Pro, but not Air support DeviceOrientation). DeviceMotion and DeviceOrientation work similarly. They both are events sent to the window object when something changes about the device. We can provide event listeners for these events, then respond to the data they provide.

For each type of event, we make sure that the window object supports the event type, and if it does we add an event listener to the window for the type of event.

Ok, so now our Window can receive these events, let's look at what information we get from each event, and how we can detect whether the device is in motion.

As mentioned, the most logical way to do so is via DeviceMotion, but here's the complication. An ideal device for using as a security camera is an old laptop. It's powered, so the battery won't go flat, and on tablets, only Chrome for Android supports getUserMedia, for operating the device's video camera. But, we can use DeviceOrientation to detect motion as we saw on some laptops in Chrome. Let's do that first, then quickly look at how we can do the same thing for devices which support DeviceMotion events.

Because DeviceMotion and DeviceOrientation events fire many many times a second, if we were to respond to every single such event, we'd have a very warm laptop, and on battery powered devices, much shorter battery life. So, here we check the current time, and only if the time since we last responded to this event is greater than some interval we respond to the event. Checking for movement a few times every second should be more than adequate.

The event listeners receive deviceOrientation events, with data about the event, including information about the device's orientation around 3 axes—alpha, beta and gamma.

alpha is the device's rotation around the z axis, an imaginary line extending out vertically from the middle of the device when it is lying flat on its back. In theory, alpha=0 is facing east, 90 is facing south, 180 is facing west, and 270 is facing north, but due to practical reasons, alpha is really only accurate for relative motions, not absolute directions, and so for example can't be used to create a compass.

beta measures the rotation around the x axis, a line horizontally through the device from left to right. 0 is when the device is flat, positive values are the number of degrees that the device is tilted forward, and negative values, the number of degrees it's tilted backwards

gamma measures the device's rotation around the y axis, a line horizontally along the plane of the devices keyboard (or screen). Positive values at the number of degrees it's tilted to the right, and negative values, the number of degrees it's tilted to the left

The orientationData argument is our deviceOrientation event. Along with the sorts of information we'd expect from any event, it has 3 properties, alpha, beta and gamma, with no prizes for guessing what these contain.

What our function does is gets the beta and gamma values from the event, and subtracts the difference from the last time we measured these. If either of these differs by more than some threshold we've set (in this case a little under 1 degree) then we've detected a movement. We finish by storing the most recent beta and gamma values. We've not bothered with alpha values, because Chrome, at present the only browser to report these values on the desktop, doesn't report alpha values, and because moving a device only around one axis is extremely difficult, so if there's movement around beta or gamma, then that's good enough for our purposes. Essentially when the device is lying flat on its back, anyone walking in the vicinity will trigger this event.

How about doing the same thing when device motion events are supported? This time, instead of reporting the devices orientation in space, we get information about its acceleration in each of the same axes, x, y and z.

motionData.acceleration.x is the acceleration of the device, in metres per second per second (ms^2), to the right (relative to the device) (so negative values are acceleration to the left)

motionData.acceleration.y is the acceleration of the device, in metres per second per second (ms^2), forward (relative to the device) (negative values are acceleration "backwards")

motionData.acceleration.z is the acceleration of the device, in metres per second per second (ms^2), upwards (relative to the device) (negative values are downwards)

Here we take the acceleration in each axis, and if any of these is greater than a threshold amount (to ensure we don't get false positives) then we're in motion. You can see it's a little simpler than using deviceOrientation, as we don't need to calculateany change.

Taking the photo

So now we can detect when the device is moving, we want our security camera to take a photo. How are we going to do this? Well, one feature of WebRTC is the ability to capture video with a device's video camera. At present, this is supported in Firefox and Chrome on the desktop, and the Blackberry 10 Browser (which also supports devicemotion events, so your Blackberry 10 phone or Playbook can serve as a security camera if you need it!), as well as Chrome for Android (though you need to enable it with chrome://flags). WebRTC is a very powerful API, but we're only going to need a small part of it.

We'll use the getUserMedia method of the navigator object. This takes an options object, as well as a success and a failure callback function as its arguments.

Our options variable is a simple object, here we just set its property video to true (if we wanted audio we'd also set an audio property to true).

We've also passed it two callback functions, gotVideoStream, which will be called once a video stream is available, and getStreamFailed, which is called if we don't get a video stream (for example, if the user refuses the browser's request to use the video camera). getUserMedia uses callbacks, rather than returning a value, because it takes time for the user to choose whether to allow video to be enabled, and as JavaScript is single threaded, this would block our UI while the user waited.

OK, there's a bit going on here, so let's take it one step at a time. Navigator calls our callback function, passing an argument stream. This is a MediaStream object. We then use the createObjectURL method of the window's URL object to get a URL for the stream (this way we can then make this URL the value of the src attribute of a video element, then this video element will show the output of our camera in real time!).

So, we've now got a working video camera, that shows the video feed from our devices camera in a web page. No servers, no plugins! But we still don't quite have our security camera. What we need to do is take a snapshot from the video stream, when we detect movement. So, let's first take the snapshot

Taking a snapshot from the video element

Here we'll take a snapshot of the video element at a given time. Note this works regardless of what's playing in the video element (so you can do a screen grab of anything playing in an HTML5 video element like this). Ready?

we use the drawImage method of the canvas to draw the video into the canvas starting at (0, 0) (the top left of the canvas).

Yes, it really is that easy. Just as you can use canvas.drawImage with an imgelement, we can use it with a video element.

Now we've got all the pieces, let's put them together to create our security camera.

Remember this part of our motion detection functions?

if (inMotion) {
//do something because it is in motion
}

This is where we call takeSnapshot, and then the current frame in the video element will be captured to a canvas element. You could also save this in localStorage, or send it via email to someone, or otherwise do something with the image. I'll leave those parts to you.

And that's really all there is to it.

I've also got a fully working version available on github. It's a little more complicated to read through than the code here, but it's copiously commented, and the basic working code is the same. Or you can see it in action here (just make sure you use Chrome with a device that supports orientation events, and has a webcam).

Notes for those following along

Note though, to make it work from your local drive, you'll need to run it through a webserver (Chrome won't enable the camera from file:// although Firefox will). You'll also need a device that supports either device orientation or device motion events, which to my knowledge currently means only a MacBook Pro (not MacBook Air).

Links for further reading

Som more reading on the various features we used to build our security camera.

In a fast and furious fifteen minutes, Mark Dalgleish demystifies Web Components by highlighting how, despite its complex appearance, it’s actually made up of a suite of technologies providing features we’re already familiar with. Once you understand what web components bring to the table, you’ll wonder how we ever lived without them. Make sure you also check out the accompanying blog post for full details.

In the past, validating forms in the client has typically required doing some heavy lifting with JavaScript. But you may not know HTML5 changes all that. Browsers now check that the content of an input match its type (and we’ve got new types like email, url and number to make that even more useful). But, what you might not know about is the pattern attribute, which lets us use regular expressions directly in HTML to specify what format the user’s input should have.

In this session, Chris Lienert looks at some of the common regex patterns you can use to validate user input, coupled with some of the many tricks he’s learned to help users complete those forms we all love to hate.

Right now creating high quality user experiences in HTML5 is very hard, and to get to where we are today we need a huge bundle of hacks and extreme techniques, many of which Andrew Betts covers in the session.

A little while back, Jake Archibald wrote infamously (and anthropomorphically) that the HTML5 ApplicationCache is a “douchebag”[1]. Mindful that this is a word freighted with troubling significance, it is the term he used, so I’ll go with it.

Following Blackberry 10’s support for WebRTC, Chrome beta or Android now supports webRTC, as do Firefox, Opera and Chrome for desktop (and Firefox for Android though not as yet Firefox OS it would seem).

A very significant milestone for what many consider a game … Read more »

Last week we looked at one of HTML5’s syntax quirks, the fact that you don’t need to quote attribute values (unless the values contain a space or as is less well known one of a number of other characters). This time, some more about some of the subtle side … Read more »

One of the benefits often touted for HTML5 over XHTML is what I once heard Paul Irish describe as its “loosey goosey” approach to syntax. No longer the strict taskmaster that XHTML was, we can now do all … Read more »

A couple of weeks ago we started a series on how you might implement some of the more notable design effects in iOS 7 using purely web technologies. In the meantime, it’s been noted elsewhere that this may be difficult and perhaps impossible to do. I’m here today … Read more »

For most of the history of what might loosely be termed computer games, dedicated consoles (and handheld gaming devices) ruled the roost. And none loomed larger on the landscape than Nintendo, with combined sales of hundreds of millions of units.

Remember the X in XML, and XHTML? It of course stands for extensible, the idea that these languages allow for their users to build upon them, rather than waiting for some standards organisation to add new features.

With HTML5, extensibility of the markup language pretty much went out the window, despite … Read more »

As much as they affect JavaScript, state, event handling, and default browser behaviour also impact HTML and CSS in the choices we make, optimizations we can take advantage of, and the architecture of our applications as a whole.

Like what you see? Want a piece of the action next time around? Then get along to Web Directions South in Sydney October 24 and 25 2013.

As a web developer, you’ve probably seen emerging HTML5 technologies and APIs like DeviceOrientation and WebRTC (Web Real Time Communications), and thought “wow they look cool, but they are only for hard core gaming, video conferencing, and other such stuff, not for my every day development”. I’m firmly … Read more »

About

The people and thoughts behind Web Directions

Founded in Australia in 2004, by long time web industry figures John Allsopp and Maxine Sherrin, (and now run by John), Web Directions conferences bring together the web industry’s leading experts from around the world to educate and inspire our attendees.