Category Archives: HTML

IE doesn’t have an emulation feature

“I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.”

Document Modes in Internet Explorer are probably one of the most misunderstood features of the browser itself. The cause of the confusion doesn’t lie exclusively on the end-user either, Microsoft has shipped a Document Mode switcher in the F12 Developer Tools under an Emulation tab for a while now. As a result, it’s not uncommon for people to think that Internet Explorer 11 can emulate Internet Explorer 8 for the purposes of testing simply by switching the Document Mode.

“I have a very bad feeling about this.”

So what the heck is this feature? Why does it exist, and what should we call it if not “emulation”? I recently discussed this on twitter with a friend, and my frustration over the matter drove me to really sit and think about a proper way to illustrate the purpose of this feature. After some thought, I arrived at a comparison with an A99 Aquata Breather. You know what that is, right? No? Let me explain.

The A99 Aquata Breather (seen in Star Wars, episodes I and III) allowed Jedi to survive for up to 2 hours in an otherwise hositle environment. For instance, on their long-swim to the underwater city on Naboo Qui-Gon Jinn and Obi-Wan Kenobi used Aquata Breathers to stay alive long enough to enter the Hydrostatic Bubbles of Otoh Gunga (I really hope this is making sense…).

Lets bring this back to Internet Explorer and Document Modes. Just like Qui-Gon and Obi-Wan weren’t able to breathe under water (unassisted, that is), a site constructed in/for Internet Explorer 8 may not necessarily work in Internet Explorer 11 unassisted. So to ensure a more enjoyable experience, and avoid certain death, Jedi swim with an assisted-breathing device, and web developers send x-ua-compatible headers with their HTTP responses (or a meta-tag, if that’s your thing).

“That’s no moon. It’s a space station!”

So that Document Mode switcher in Internet Explorer’s F12 Developer Tools is not for seeing how well your modern site will work in a legacy browser, but rather how your legacy site will work in a modern browser.

Suppose a developer built an intranet application for her client in late 2009, when the client was running Internet Explorer 8 internally on a thousand machines. Several years later, the client calls the developer and informs her that they are planning on moving to Windows 8.1, and Internet Explorer 11. At this point, the developer can open Internet Explorer, navigate to the application, and see how well it will work for her client in a modern version of IE. Should she encounter differences in layout or scripting, she could switch the Document Mode to that of Internet Explorer 8 and see if this resolves the problem. (See also Enterprise Mode for IE)

Note the directionality — Document Modes are for making older sites work in modern browsers by creating (to some degree) environmental configurations the site relies on. This doesn’t turn the browser into an older version of itself; it merely satisfies a few expectations for the sake of the application.

“This is some rescue! You came in here, but didn’t you have a plan for getting out?”

Like the A99 Aquata Breather, a Jedi developer should only be expected to rely on a legacy document mode for a short period of time. The x-ua-compatible approach should be seen as a splint to keep your broken leg together until you can get some serious medical attention for it. It’s meant to keep you upright with the intent that you should be able to soon stand alone, unassisted. Don’t use a breather unless you’re swimming to a place that has air to breathe, and don’t use x-ua-comptabile headers or meta-tags without intending to fix whatever breaks your site in a modern browser.

If you develop in a modern version of Internet Explorer and do need to see how your site will render in an older version of IE, your best option is to download a free virtual machine from, get an account on, or do your testing the next time you visit Grandma’s for dinner.

Emulation Accuracy in Internet Explorer

Early preview versions of Internet Explorer 11 lacked Emulation features that we saw in Internet Explorer 9 and 10. When Windows 8.1 shipped, Internet Explorer 11 was found to have the Emulation features shipped with it. These tools are helpful, though they can be misleading at times.

My general workflow in the past when using these tools goes like this: A user reports an issue in Internet Explorer x. I instruct the latest version of Internet Explorer to emulate the reported version. If I encounter the same issue, I can debug using the modern version of Internet Explorer. If emulation does not reveal the same issue, I need to load up a virtual machine, or use a service like BrowserStack.

The problem with these tools is that it’s not entirely clear where the line of reliability resides. To what degree this emulation replicates the native experience is unknown (to me, at least). Due to this, I’ve decided to do a deep dive into Emulation and see just how reliable it is, and in which areas.

Computed Styles

The first dive wasinto Computed Styles. Does Internet Explorer generate the same computed styles as IE10 and IE9 when it is emulating those versions? Surprisingly, yes. Granted, I’m running instances of IE10 and IE9 in a Virtual Machine (compliments of, so that should be considered. Also other important thing to note is that this pass-through assumes Standards Mode.

The comparison tables are being maintained in a Google Docs spreadsheet. Click the preview below for the full view.


Window Object

My next focus was on cycling over enumerable properties on the window object and laying those out for comparison. A cursory glance of this next table will reveal that Internet Explorer 11 emulates the window object from IE9 and IE10 very well. Granted, there are some very clear examples of where it brought along a couple extra methods and properties.


It’s worth noting that this particular table had to be done a couple of times. Some of these members don’t attach themselves to the window object until certain actions are performed. For instance, this table is front-loaded with a bunch of BROWSERTOOLS members that are pushed onto the window object when various portions of the developer tools are opened. Other members, such as $0, don’t exist until you perform an action like selecting an element in the DOM Explorer.

More on GIFs and Painting in Internet Explorer

About a week ago I wrote a post demonstrating the use of UI Responsiveness functionality in Internet Explorer 11 to determine how the browser handles animated GIFs in various states. This post was a fairly well-received so I wanted to expand a bit more upon it and cover a few more scenarios.

For the most recent round of testing, I setup a simple interval to change the className of the body element every few seconds. This, in turn, affects the placement and layout of a single image element within the document.

(function () {

  "use strict";

  var states = ["", "opacity", "visibility", "offscreen", "perpendicular"],
      container  = document.body,
      cycles = 0,

  function advanceState () {
    // Advance to next array index, or return to start
    nextState = states[++cycles % states.length];
    // Indicate a new performance mark in our developer tools
    performance.mark(nextState ? "Starting " + nextState : "Restarting");
    // Update the body class to affect rendering of image
    container.className = nextState;

  setInterval(advanceState, 3000);


I used the performance.mark method to add my own indicators in the performance graphs to help me identify when the demo was transitioning into a new state. These performance marks are represented in Internet Explorer by small upside-down orange triangles.


Let’s walk through each of these triangles left to right, discussing the state they represent.

GIF Untouched

This state is represented by all activity to the left of the first performance mark. Not much needs to be said – Internet Explorer continued to paint the GIF as it sat animated on the screen.


Setting GIF Opacity

This step is represented by all activity between the first and second performance marks. In this step, the image element has its opacity property set to 0. Even though the image is no longer visible, the browser continued repainting the region occupied by the image element.


Setting GIF Visibility

This step is represented by all activity between the second and third performance marks. In this step, the image element has its visibility property set to hidden. Once the visibility property was set to hidden, the browser made one final repaint (presumably to hide the element) and no further paint events took place during the duration of this state.

Of relevance here is that the hidden attribute on the image itself has the same effect. When this attribute is present on the element, Internet Explorer will cease to repaint that elements occupied region.


Setting GIF Outside of View

This step is represented by all activity between the third and fourth performance marks. In this step, the image element is positioned absolutely at top -100% left -100%. In spite of the fact the element is positioned outside of the viewport itself, the browser continued to run paint cycles.


Setting GIF Orientation Perpendicular to Viewport

This step is represented by all activity between the fourth and fifth performance marks (the fifth mark is the ‘Restarting’ mark). In this step, the image is rotated using the transform property so as to set it at a right angle to the viewport, effectively hiding its content from the viewer. This orientation did not affect the browser paint cycle, and Internet Explorer continued repainting the region occupied by the image element.



As a general rule, it appears Internet Explorer will run paint cycles for every animated GIF in the document, unless that element has its visibility property set to hidden. This is fairly reasonable, since setting visibility to hidden is the only explicit way to tell the browser not to render the element. Keep this in mind when performance is of key importance.

After running through and investigating this further I was curious what the same test would reveal in Chrome. I was pleased to see that Chrome would cease to paint for the opacity, visibility, and offscreen configurations. No performance marks are revealed in Chrome’s developer tools, but you can identify the timer functions by the presence of a small orange mark.

Tracking GIF Repaints with UI Responsiveness

I recently came across Paul Lewis’ article Avoiding Unnecessary Paints: Animated GIF Edition on HTML5 Rocks and wanted to contribute a bit to the message. If you aren’t a regular reader or HTML5 Rocks I would definitely encourage you to visit often.

The summary of Lewis’ post is that animated GIFs can cause repaints even when obscured by other elements. So even though you may not see the GIF, the browser may continue to repaint every frame of it.

As far as browsers go, Lewis shared with us the “Show paint rectangles” feature in Chrome. When enabled, this feature will visually outline regions that are being repainted. This obviously makes it very easy to determine whether paints are happening on obscured elements. Chrome, Safari, and Opera all repaint. Firefox does not.

In his discussion of various browsers, Lewis calls Internet Explorer 11 a “black box,” suggesting it gives “no indication whether repaints are happening or not.” As a result, no statement was made speculating whether Internet Explorer was in the camp of Chrome, Safari, and Opera, or Firefox.

I quickly did a scan of the comments to see if anybody addressed these words regarding Internet Explorer, but at the time nobody had. I saw this as a great opportunity to introduce my friends to the new UI Responsiveness tool in Internet Explorer 11.

The UI Responsiveness tool in Internet Explorer’s Developer Tools will actually give us pretty granular information about frame-rates, script timing, styling changes, rendering, and even repaints. Given the novelty of this feature in Internet Explorer, I felt it would be good to provide a quick example of how Internet Explorer 11 can indeed tell you whether obscured GIFs cause repaints or not.

A Single Visible GIF

My first experiment consisted of nothing more than a single GIF in the body of my document. By profiling the page for a few seconds I could see that there was constant repainting. This was expected of course, after all there’s a GIF on my screen spinning.

Below is one second of activity. As you can see, constant repainting.


Toggling Visibility of a Single GIF

Next up, toggle the visibility of the GIF by way of its display property. I setup a interval to flip the visibility every second. The results were also as expected. For roughly one second, we had constant repainting. Following this we saw a set style event, followed by a single repaint (to hide the element). At this point, it was silence for a second before the element became visible again, and thus began causing additional repaints.


Routinely Obscuring a Single GIF

The last experiment was to add another element, a div with a solid background-color in this case, and obscure the animated GIF on an interval. This was done by positioning both the div and the image absolutely within the body, and giving the div a higher z-index.

As can be seen in the image below, repainting did not cease even when the layout was adjusted every second. This demonstrates that when obscured, animated GIFs will continue to cause repaints in Internet Explorer 11. Whether this will be the case for future versions of Internet Explorer remains to be seen.



So as we can see in these examples above, Internet Explorer 11 is capable of sharing vital information about costly repaints. Additionally, IE falls into the Chrome, Safari, and Opera camp. It sure would be nice if all browsers followed Firefox’s lead here and stopped repaints on obscured GIFs, but perhaps there is a good reason they haven’t, who knows.

I hope you can see the enormous value the UI Responsiveness panel in Internet Explorer 11’s Developer Tools brings to the debugging experience and use it to make your projects more responsive and performant in the future. The team behind Internet Explorer really have been doing amazing work lately, and the UI Responsiveness functionality is but one example of this.

UPDATE: More on GIFs and Painting in Internet Explorer

Milestone Hangout 0.2.0 Reached

For months I’ve been doing weekly Hangouts where I walk through the HTML Specification, and most recently the CSS 2.1 Specification. This has served as a means by which I can help others get a better understanding of the core technologies behind solid web development, as well as an opportunity for myself to retrace some of the forgotten roots of these ubiquitous languages.

Recently I wrapped up episode 20, or 0.2.0, which covered Counters, Automatic Numbering, Lists, and Backgrounds in CSS. It was a great episode since I had never actually used counters in CSS to begin with. This was one of the benefits of retracing those old roots – there is a surprisingly amount of stuff that isn’t common enough that I ever learned about it in the past.

After roughly 21 hours of live hangouts I am about to start a series of JavaScript hangouts. These will take place at the same standard time, Thursday evenings at 7:30pm Eastern. If you’re new to web development, or don’t feel all that confident with JavaScript, please feel free to attend. You can login with your Twitter handle and ask questions in realtime.

If you want to drop through some of the older hangouts, they’re organized in two playlists:

Display: Grid – The Future of Responsive Grid Layouts

Brief History

The history of front-end design strategies is a wild thing to study. We started with linear page-outlines, largely consisting of a wall of text and hyperlinks. We later got clever and began co-opting <table> to give us more control over page layouts. We should have all been smacked for doing it, but it was the convention at the time.

When tables began to be more of a nuisance than a solution the community started leveraging floats, and working to define their design requirements in terms of laterally-shifted elements that sat next to one another. Of course that too presented a new set of problems – we had to perform an embarrassing amount of CSS acrobatics to clear our floats, or achieve something as simple as the Holy Grail of layouts (which was trivial with <table>).

Things got better; tried and true conventions and approaches were packaged up into wildly popular frameworks like Nathan Smith’s 960 Grid System, and appeared to have solved all of our problems for a short while. But the fact remained that while we had comfort, it came at the cost of meaningless additional markup, and cryptic classnames. The DOM was getting noisy.

Introducing Grid Layouts

Browser vendors and standards bodies took it upon themselves to start working on alternative, more reliable solutions. With the release of Internet Explorer 10 we saw the first major browser implement a CSS-based Grid System.

For the first time, we are able to author our content as it ought to be, without nesting it in arbitrary ad-hoc divs to give ourselves a little advantage in CSS. We can now turn simple markup into easily-manipulated sophisticated layouts.

No more absolutely positioned elements, pointless margins or padding, etc. CSS Grids completely liberate you – the designer – from having to wrestle with the layout engine to get the effect you want without forcing you to compromise on your markup or CSS.

Defining Columns and Rows

The CSS is remarkably very simple to grok; and if you’ve ever spent any time in the past wiggling through tables, you’ll find much of the code very familiar-sounding. We start by setting an element up as our grid container. In the code above, I used the body element:

body {
  display: -ms-grid;

Because this technology is still experimental, you can only access it by using the -ms- prefix. Once we have set our display mode to -ms-grid, we have to define our columns and rows. This too is very straightforward:

body {
  display: -ms-grid;
  -ms-grid-rows: 100px 200px 1fr;
  -ms-grid-columns: 1fr 150px;

This results in a grid that has three rows, and two columns. Think of a table that has three table rows, and two table cells in each row. Our first row is 100px tall. Our second is 200px tall. Lastly, our third row is the full remaining fractional value; so whatever is left over after 300px is taken away, that will be the height of our third row.

We took a similar approach for our columns. Our first column takes the remainder of the horizontal space left over after 150 pixels have been given to our second column. At this point, your design will be mangled beyond recognition. Until you specify where each element ought to reside, they will all be tossed into row one, column one – do you even grid, bro?

Placing and Sizing Grid Items

Once you have your rows and columns defined, it’s trivial to move your elements around from any column or row to another. For instance, suppose we wanted to move our <h1> element into the first row, and have it span both columns:

h1 {
  -ms-grid-row: 1;
  -ms-grid-column: 1;
  -ms-grid-column-span: 2;

It’s so straightforward that it requires no explanation.

Not only can we specify which column and row our element resides in, we can also instruct our element to span additional columns and rows to better align our grid contents as we see fit.

Your main bag of tools consists of the following properties:

Property Description
-ms-grid-row target row
-ms-grid-row-align horizontal alignment
-ms-grid-row-span number of rows to span
-ms-grid-column Target column
-ms-grid-column-align Vertical alignment
-ms-grid-column-span Number of columns to span

The alignment properties accept values such as start, end, center, and stretch. In a left-to-right layout, start will align the element to the left while end will align it to the right. Stretch will cause the element to consume all available space in the grid location. By default grid items are stretch, so don’t freak out if an image initially looks wonky.

Responsive Grids

With this much control over the layout in our CSS, you can imagine the amount of flexibility we have when we add media queries into the mix. All of a sudden, we can rearrange everything when in portrait mode as opposed to landscape, or desktop as opposed to mobile.

Below I created a simple example that shifts the layout around above and below the 400 pixel mark. In the left image we have more of a “mobile” experience, and in the right we’ve rearranged the elements (without touching the markup, woot) to present a wider experience.


Here are the two media queries. Note the small amount of changes needed to completely restructure things.

body {
  -ms-grid-columns: 50% 50%;
  -ms-grid-rows: auto auto 1fr;

@media screen and (max-width: 400px) {
  nav  {
    -ms-grid-row: 2;
    -ms-grid-column: 1;
    -ms-grid-row-align: center;
    -ms-grid-column-align: center;
  h1 {
    -ms-grid-row: 1;
    -ms-grid-column: 1;
    -ms-grid-column-span: 2;
    -ms-grid-row-align: center;
    -ms-grid-column-align: center;
  img {
    -ms-grid-row: 2;
    -ms-grid-column: 2;
  article {
    -ms-grid-row: 3;
    -ms-grid-column: 1;
    -ms-grid-column-span: 2;

@media screen and (min-width: 400px) {
  nav  {
    -ms-grid-row: 3;
    -ms-grid-column: 2;
  h1 {
    -ms-grid-row: 2;
    -ms-grid-column: 2;
  img {
    -ms-grid-row: 1;
    -ms-grid-column: 2;
  article {
    -ms-grid-row: 1;
    -ms-grid-column: 1;
    -ms-grid-row-span: 3;

I have purposefully kept the examples here relatively simple, but only because I don’t feel this requires a great deal of explanation to get my point across – grids are freaking amazing.

In this short introduction we’ve seen how to create a grid container, assign arbitrary numbers of columns and rows with various dimensions. We placed elements, moved them around, and dynamically updated their properties to completely reconfigure our layout.
In the midst of all this excitement, there is a bit of bad news (isn’t there always?).

The Caveat

As of writing this the only browser to currently support CSS Grids is Internet Explorer 10. This means all of the code from above will have no effect in Chrome, Firefox, Opera, or any of the other major browsers. Check for most recent changes.

If you are interested in developing Windows Store Applications with HTML, CSS, and JavaScript, you can definitely put this feature into your bag of tricks to ensure your app looks and feels the way you expect.

Although you can’t put it to much use on the open web, it is still good to begin developing a familiarity with the technology as the W3C Grid Layout spec is in the works and will hopefully find its way to Candidate Recommendation in the future.

Need More Direction?

If you’re looking for some assistance with any of the above content, or even with IE’s implementation of CSS Grids, you have a few places you can go to get assistance. Stack Overflow is almost always my first suggestion, though it currently doesn’t have much content around IE’s CSS Grids implementation (likely to change in the near future).

Another great place to look would be the @IEDevChat account on twitter. Additionally, if you want to get the attention of the User Agents (of you can tag your tweet with #IEUserAgents. This notifies a developer experienced in Internet Explorer to come and assist you. Sweet deal, right?

On a Mac? Don’t have Internet Explorer 10? You’re not out of luck – you can test all of these features using Additionally, you can download a free virtual machine with IE10 from I happen to be working on this demo in a virtual machine, and the performance is stellar on my MacBook Air in Parallels.

That’s it. Go be awesome.

Taming the Lawless Web with Feature Detection

The Lawless Web

Over the past 15 years or so that I’ve been developing websites, I’ve seen various conventions come and go. Common practices arise, thrive for a while, and die. I, myself, spent a great portion of my past hammering out lines of tabular markup (and teaching classrooms to do the same) when working on my layout.

When I wasn’t building complicated table-based layouts littered with colspans, I was double-wrapping elements to iron out the differences between browser-interpretations of the box-model.

Fortunately, these practices have died, and others like them continue to die every day.

The Web Hasn’t Been Completely Tamed

While atrocities like table-based layouts are quickly becoming a thing of the past, other old habits have chosen not to go as peacefully. One that has managed to stick around for some time is user-agent sniffing; the practice of inferring a browser’s abilities by reading an identification token.

var browser = {
     vendor: navigator.userAgent.match(/Chrome|Mozilla|Opera|MSIE/),
    version: navigator.userAgent.match(/\d+/)

if ( browser.vendor == “Mozilla” && browser.version == 5 ) {
    // This matched Chrome, Internet Explorer, and a Playstation!
    // Nailed it.

Since shortly after the dawn of the epoch, developers have been scanning the browser’s navigator.userAgent string for bits and pieces of data. They then couple this with a knowledge of which browsers support which features, and in conclusion make judgements against the user’s browser and machine. Sometimes their conclusions are correct, but the ends don’t justify the means.

Don’t Gamble With Bad Practices

Sniffing a browser’s user agent string is a bit like playing Russian Roulette. Sure, you may have avoided the loaded chamber this time, but if you keep playing the game you will inevitably increase your chances of making a rather nasty mistake.

The navigator.userAgent string is not, and has never been, immutable. It changes. It gets modified. As browsers are released, as new versions are distributed, as browsers are installed on different operating systems, as software is installed in parallel to the browser, and as add-ons are installed within the browser, this string gets modified. So what you sniff today, is not what you will sniff tomorrow.

Have a quick look at a handful of examples for Chrome, Firefox, Opera, and Internet Explorer. Bottom line is that you can’t be sure what you’ll get when you approach the user agent string buffet. As is immediately clear, the above approach would not even match version 12 of Opera consistently with its variations.

So, have I thoroughly convinced you that sniffing is bad? And have you sworn it off as long as you shall live? Let me give you something to replace it; something reliable that will nearly never let you down – feature detection.

Go With What’s Reliable

Feature detection is the practice of giving the browser a test, directly related to the feature you need, and seeing whether it passes or fails. For instance, we can see if the browser supports the <video> tag by quizzing it on whether it places the correct properties on a freshly-created instance of the element. If the browser fails to add the .canPlayType method to the element, we can assume support isn’t there, or isn’t sufficient to be relied upon.

This approach doesn’t require us to make any assumptions. We don’t couple poorly-scavenged data with naive assumptions about which browsers support which feature. Rather, we invite the browser out onto our stage, and we demand it do tricks. If it succeeds, we reward it. If it fails, we ditch it and take another approach.

What Does “Reliable” Look Like?

So how exactly do we quiz the browser? Feature-detections come in all shapes and sizes; some very small and concise, while others can be somewhat lengthy and verbose – it all depends on what feature you’re trying to test for. Working off of our example of checking for <video> support, we could do the following:

if ( document.createElement(“video”).canPlayType ) {
    // Your browser supports the video element
} else {
    // Aw, man. Gotta load Flash.

This approach creates a brand new video element for testing. We then check for the presence of the .canPlayType method. If this property exists, and points to a function, the expression will be truthy and our test will pass. If the browser doesn’t understand what a video element is, there won’t be a .canPlayType method, and this property will instead be undefined – which is falsy.

The Work Has Been Done For You

You could be rightly freaked out about now, thinking about all of the tests you would have to write. You might want to see if localStorage is supported, gradients, video, audio, or geolocation. Who on Earth has time to write all of those tests? Let alone learn the various technologies intimately enough to do so? This is where the community has saved the day.

Modernizr is an open-source library packed full of feature-detection tests authored by dozens of talented developers, and all bundled up in an easy to use solution that you can drop into any new project. You build your custom download of Modernizr, drop it into your project, and then conditionally deliver the best possible experience to all visitors.

Modernizr exposes a global Modernizr object with various properties. You can test for the support of certain features simply by calling properties on the Modernizr object.

if ( ) {
    // Browser supports the video element

Additionally, it can optionally add classes to your <html> element so your CSS can get in on the action too! This allows you to make conditional adjustments to your document based upon feature support. {
    /* Woot! Video support. */
} #custom-video-controls {
    /* Bummer. No video support. */
    display: none;

Building A Better Web

By using feature-detection, and forever turning your back on user agent sniffing, you create a more reliable web that more people on more devices and browsers can enjoy. No longer are you bound to hundreds upon hundreds of user agent strings, or naive assumptions that will come back and bite you in the end. Feature-detection liberates you so that no babysitting of the browser landscape is necessary.

Code for features and APIs. Don’t code for specific browsers. Don’t get caught writing “Best viewed in WebKit” code – build something for everybody. When you focus on features, rather than ever-changing strings that don’t give you much insight, you help make the Internet better for us all. Do it for the children ;)

You’re Not Alone

When you set out to do things the right way, you will undoubtedly run into obstacles and complications. Let’s face it, quality work often times requires more of an investment than the slop that is so often slung out onto the web. The great news though is that you’re not alone – the web is more open than ever before, full of those willing to help you along the way.

Drop in to Stack Overflow to catch up on the various feature detection questions being asked there. Or if you’re trying to get Chrome and Internet Explorer to play nice with one another, post a question on Twitter using the #IEUserAgents hashtag. This notifies an “agent” to come to your aid.

Just be sure to pay it forward. As you learn, and grow, help others to do so as well. Maybe even write a few feature-tests and contribute them back into Modernizr along the way.

HTML Hangout Concludes after 16 Hours

For months I have been doing a weekly HTML Hangout where I work, slowly, through the W3C Specification for HTML5. I’m pleased to say that after 15 videos, and 16 hours, we’ve gotten to the point where we can progress on to bigger and better things.

HTML is now taken care of, and we will now move on to making this a weekly CSS Hangout. If you’d like to watch the HTML5 lessons, you can do so by viewing this playlist of YouTube:

If you’d like to join us in the future, simply show up to on Thursdays at 7:30PM Eastern. Broadcast usually starts about 10 minutes early, and we open up the last 10-15 minutes for questions and answers.