The Haystack.

Learn You a Flexbox for Great Good!

Stephen — Wed, 04 Jan 2012 21:48:59 +0000

Yet Another Note (2012-05-13): It might be obvious that the flexbox spec is changing often, but a kind commenter suggested I add a note here regarding the fact that in the spec, the flex() function has been replaced by the `flex` property, which makes plenty of stuff in this article obsolete. Also, expect more to change. I will most likely leave this article as is. I will write an update as soon as I see an implementation in at least one more browser. As of this note’s date, Chrome still supports the version described below. —Stephen

Note (2012-05-12): I have added -moz-, -ms- and -o- vendor prefixes to all code examples and the demo. Here’s why. The spec is—at the time of this note—still in flux, so I intentionally left out the non-prefixed properties/values.

So you want to learn Flexbox? Perhaps you’ve heard about it. Perhaps you’ve read a tutorial or two about it. Perhaps you’ve even played around with it already.

If you’ve never heard of Flexbox, or if it’s been awhile since you’ve used it, forget what you know. We’re starting over! The spec has been rewritten; the last version at the time of this writing is dated 29 November 2011!

What you’ll need

~~Currently~~At the time of this writing, ~~Chrome Canary~~ Google Chrome has a partial implementation of the spec. If you’d like to follow along, you’ll need nothing more than ~~Chrome Canary~~ Google Chrome and your favorite text editor.

~~Chrome Canary: http://tools.google.com/dlpage/chromesxs;~~
Google Chrome: https://www.google.com/chrome
Your favorite text editor: http://www.vim.org/ (Relax, relax)

Ready? Let’s get to it!

What is Flexbox?

Flexbox is a nickname for CSS Flexible Box Layout Module. It’s one of a few CSS Working Drafts having to do with visual layout. Flexbox offers us a new box model which has been optimized for laying out user interfaces. In short: the children of a “box” can be ordered either vertically or horizontally within their parent, and we can control what happens to any remaining space. It is possible to nest these boxes, allowing for very complex layouts.

Caution!

There are other CSS layout modules in development which, in my opinion, are much more suited to general page layout than Flexbox. Flexbox is fairly straightforward, but can become unruly when used for complex layouts. In any case it is not the best solution for all types of layout. But for UI-components like buttons, forms, toolbars or rows and columns of content/media blocks for which you’d normally use floats, Flexbox makes code simpler and is a huge time-saver. Flexbox is designed to play nicely with existing CSS properties. Thus, you are still free to use floats or other types of positioning on non-Flexbox elements.

Three Little Boxes

If you’re feeling a bit lazy, you’re welcome to simply download and edit the demo page Otherwise…

Open your editor, create a simple HTML document with a single box. In this case, we’ll use a div:

Great, But it would be nice to see something, so we’ll have to add some style:

Now we’ll put three boxes into our div. These are, of course, the first div‘s children:

Let’s style those as well:


    div>div {
        width: 100px;
        height: 100px;
        background-color: pink;
    }

Now look at this page in ~~Canary~~the browser. Nothing unusual here, just three block-level elements one under another, as block-level elements are known to do. But we’ll put a stop to that. We’ve created our own Flexbox playground, so let’s play.

Defining a flexbox

We would like to apply the magic of Flexbox to the children of our parent div. We do so with the display property. By applying display: flexbox; to our parent div, we tell it to use the Flexbox box model. If we wanted our parent div to be inline instead of block-level, we’d use display: inline-flexbox;.


    body>div {
        display: -webkit-flexbox; /* We need the prefixes for now, unfortunately. */
        display: -moz-flexbox;
        display: -ms-flexbox;
        display: -o-flexbox;
        height: 500px;
        padding: 1em;
        background-color: gray;
    }

Our three child divs, which we’ll call flexbox items from now on, now live according to the Flexbox box model. Beware: there are rules that determine what a flexbox item is. For example, if we were to use position: absolute; on one of the three boxes, it would no longer be a flexbox item since we’ve applied a different positioning model. Read more about flexbox items in the spec.

Back to our little exercise. Take a look at the page in your browser. The flexbox items look a bit as if we had applied inline, inline-block or float to them. This is because the Flexbox default is to position flexbox items horizontally. The main difference so far is that we have only added a rule to the parent and not to the items themselves.

Source-order independence

Flexible Box Layout Module gets its name from the fact that it allows us to create flexible boxes. In other words, boxes can become flexible by utilizing available space. We’ll get to that in a minute. But Flexbox offers something at least equally important to us, especially in this Age of Mobile: source-order independence. Let’s play around and see how we can change the order of flexbox items.


    body>div {
        display: -webkit-flexbox;
        display: -moz-flexbox;
        display: -ms-flexbox;
        display: -o-flexbox; 
        -webkit-flex-flow: row-reverse;
        -moz-flex-flow: row-reverse;
        -ms-flex-flow: row-reverse;
        -o-flex-flow: row-reverse;
        height: 500px;
        padding: 1em;
        background-color: gray;
    }

OMG. Our flexbox items are now right-aligned and the order is reversed! We do this with the flex-flow property, for which row is the default value. row-reverse flips this around. You might have already guessed that when you want to position flexbox items vertically, you would use column or column-reverse. At the time of this writing, ~~Canary~~Chrome does not support column-reverse, but try out column and see what happens! When you’re done playing around, set the value back to row and we’re ready for our next step.

By the way, flex-flow also takes a value for wrapping flexbox items to new rows (or columns, depending on which you’re using). The values wrap and wrap-reverse serve this purpose, as the default is a single row (or column) of flexbox items which overflows the parent. wrap and wrap-reverse still haven’t been implemented at the time of this writing (I’m saying that a lot). But let’s say, just for fun, that we could use wrap today:


    body>div {
        display: -webkit-flexbox; 
        display: -moz-flexbox;
        display: -ms-flexbox;
        display: -o-flexbox;
        -webkit-flex-flow: row wrap; /* `wrap` gives us a multi-line flexbox. */
        -moz-flex-flow: row wrap;
        -ms-flex-flow: row wrap;
        -o-flex-flow: row wrap;
        height: 500px;
        padding: 1em;
        background-color: gray;
    }

Mirror, mirror…

All the properties dealing with order, direction or alignment of flexbox items are influenced by the current writing mode. The writing mode is the original direction of the text. Many of us are used to top-to-bottom, left-to-right. But as soon as these are changed, the output of the directional Flexbox properties will also change. You’ve already seen what row-reverse does. But what if your writing mode isn’t the default (top-to-bottom, left-to-right) but top-to-bottom, right-to-left? Your flexbox items would be laid out from right-to-left in the first place, and row-reverse would flip things so they’re left-to-right.

Try it out:


    body>div {
        display: -webkit-flexbox; 
        display: -moz-flexbox;
        display: -ms-flexbox;
        display: -o-flexbox;
        direction: rtl; /* The `writing-mode` property currently has no visual effect in Chrome. The `direction` property will suffice for our example. */
        -webkit-flex-flow: row;
        -moz-flex-flow: row;
        -ms-flex-flow: row;
        -o-flex-flow: row;
        height: 500px;
        padding: 1em;
        background-color: gray;
    }

Look at the page in your browser. Now replace row with row-reverse. See what happens?

Confusing? Perhaps a little at first, but the properties all work logically based on the current writing mode. As most of us usually work with the same writing mode most of the time, it shouldn’t be much of a problem.

In order to understand the effect many Flexbox properties have on flexbox items, it is important to understand what the main axis and the cross axis are. The main axis is the axis along which the flexbox items are placed. In other words, if the flexbox items have been placed horizontally (flex-flow: row;), then the main axis is horizontal. The cross axis is perpendicular to the main axis. In our example, that would be vertical. When using flex-flow: column;, this is switched: the main axis is vertical and the cross axis is horizontal.

That’s a pain to explain well. Just to be sure we’re clear, here’s an illustration:

Remember main axis and cross axis, because we’ll need them in a bit.

Order! Order in the court!

Let’s look at another property which helps the cause for source-order independence: flex-order.

In your example code, make sure you’ve set flex-flow to row and have removed direction: rtl;. If things are as they should be, you’ll have three flexbox items: A, B and C, in the top left of body>div. Imagine that although our code contains these items in that order, that we want to display them in the order A-C-B. To do this, we’ll use flex-order:


    div:nth-child(2) { /* Yes, I could have used an ID or a class. But, hey, whatever. */
        -webkit-flex-order: 1;
        -moz-flex-order: 1;
        -ms-flex-order: 1;
        -o-flex-order: 1;
    }

Check things out in your browser. The order of the flexbox items should be A-C-B.

flex-order places flexbox items into ordered groups. Boxes without an explicit flex-order are in group 0 and remain in source order. In our example, the second flexbox item (B) is placed in group 1. A and C remain in group 0 and in source order (A before C). Since group 1 comes after group 0, the B comes last. If we had wanted the order B-A-C, we could have left B in group 0 and put A and C into group 1:


    div>div:first-child,
    div>div:last-child {
        -webkit-flex-order: 1;
        -moz-flex-order: 1;
        -ms-flex-order: 1;
        -o-flex-order: 1;
    }

Flexibility

One of the nicest aspects of Flexbox is the ability to create flexible elements. We can decide what to do with any remaining space in our body>div (in this example). We can divide this space up between the flexbox items, or we can make the widths or heights of one or more of these items flexible, alotting a certain amount of available space to each.

We’ll look at flexibility first and then come back to distributing available space.

Imagine that our three flexbox items are buttons in a web application which might also be used on mobile devices. Sometimes we have three, but sometimes we only have two (just nod and go along with it). We’d like to say, “No matter how many of these buttons there are, I want them all to generally be the same width, and these widths should be such that the row of buttons takes up all the available width of the parent.” We’d normally resort to JavaScript for these types of layout problems, but Flexbox might put an end to that. See what happens when we make our flexbox items flexible with the flex() function:


    div>div {
        /* width: 100px; */
        width: -webkit-flex(1 0 100px);
        width: -moz-flex(1 0 100px);
        width: -ms-flex(1 0 100px);
        width: -o-flex(1 0 100px);
        height: 100px;
        background-color: pink;
    }

The flex() function can be used as a value for width or height. flex() takes three values: positive flex, negative flex and preferred size. The last two parameters are optional; the default for negative flex is 0 and the default for preferred size is 0px. Here’s how flex() works in a nutshell:

The preferred width is applied to the flexbox items.
If there is any space left over in the parent, this space is divided up into parts and added to the widths of the flexbox items according to the positive flex value.
If the flexbox items overflow the parent (e.g. together they are wider than the parent), then the negative flex value is used for determining the widths of the items. Please note that negative flex is a positive value (e.g. 2 and not -2).

A positive flex value of 1 basically means “one equal part of the available space”. A value of two would mean something like “twice the amount of available space as the items that have flex(1)”. So it’s nothing like “two parts whiskey, one part cola”. The easiest way to learn it is to try it out. Type the following code under your rules for div>div:


    div>div:first-child,
    div>div:last-child {
        width: -webkit-flex(2);
        width: -moz-flex(2);
        width: -ms-flex(2);
        width: -o-flex(2);
        background-color: magenta; /* This allows us to see the difference clearly. Plus, it hurts your eyes. */
    }

If you check your browser, you’ll see that the first and the last flexbox items don’t each have 2 parts of the available space. Rather, they have two times as much available space as the middle box, which has flex(1). I know, I know. Just be glad you’re not a browser maker. Unless you are, in which case: have fun and please get this implemented ASAP!

Also, please note that this does not mean that the two outermost boxes are two times as wide as the center box. We’re only dealing with how the available space in the parent is being distributed.

Remove the declaration you just added. Remove one of the divs and look at the result in your browser. Once you’ve seen what happens, put the div back in again.

There’s plenty more about flex() and any other gory details you might want to know about Flexbox; these can all be found in the spec.

Alignment of flexbox items

Did you remember everything about main axis and cross axis? Excellent. Because the flex-pack property determines how flexbox items are aligned along the main axis. In our example file, the main axis is horizontal. In order to study the effect of flex-pack, remove flex() and change the width back to 100px:


    div>div {
        width: 100px;
        height: 100px;
        background-color: pink;
    }

flex-pack accepts one of four possible values: start, end, justify and center. Pretty clear. Let’s center our flexbox items. We do this on the parent:


    body>div {
        display: -webkit-flexbox;
        display: -moz-flexbox;
        display: -ms-flexbox;
        display: -o-flexbox;
        -webkit-flex-flow: row;
        -moz-flex-flow: row;
        -ms-flex-flow: row;
        -o-flex-flow: row;
        -webkit-flex-pack: center; /* <-- */
        -moz-flex-pack: center;
        -ms-flex-pack: center;
        -o-flex-pack: center;
        height: 500px;
        padding: 1em;
        background-color: gray;
    }

Go ahead and play with the other values until you like it.

Of course, there is a property for aligning flexbox items along the cross axis: flex-align. The possible values differ slightly from flex-pack. The most important thing to remember is that while flex-pack is applied to the parent of the flexbox items, flex-align is applied to the flexbox items themselves.


    div>div {
        width: 100px;
        height: 100px;
        background-color: pink;
        -webkit-flex-align: center; /* Also: start | end | baseline | stretch  <-- Try these vales as well! */
        -moz-flex-align: center;
        -ms-flex-align: center;
        -o-flex-align: center;
    }

Not all the values are supported yet, but I don’t think we’ll need to wait very long. As the spec solidifies, implementation should come fairly quickly. The browser makers are quite interested in Flexbox.

Enough! Time to play

There are a couple of other properties having to do with multi-line flexboxes, but since we can’t try those out yet, we’ll stop here for now. Hopefully we’ve handled enough material to get you started playing around with the “new” Flexbox. Try and consider practical applications. How could Flexbox help within the context of “responsive design” and mobile? What possibilities open up for form styling? Navigation?

You don’t need to be able to use this today in actual projects to learn and experiment with the possibilities. Implementation might come quicker than you think, and you’ll already have a head start.

Have fun!

Note: This article first appeared in the Dutch language for the Fronteers Advent Calendar. Payment for the article was a modest donation to ICCF Holland.

OMG A Blog Post

Stephen — Mon, 19 Dec 2011 16:18:43 +0000

When David Storey commented that I should change my company’s name from Zero Interface to Zero Blogging, I knew I had to write something very soon. The truth is, while I’ve been traversing mountains of client work, doing some speaking engagements and becoming a father (again), I actually have been doing some writing. Only not for this blog. I refer you to the November 2011 issue of .net Magazine, where I wrote an overview of the new galaxy that is Responsive Web Design. For the readers who know Dutch, I refer you to the Fronteers Advent Calendar, for which I wrote an introduction to the new, improved Flexbox spec, which due to some demand I will most likely translate to English and publish here.

See what I did there, David?

What about that new blogpost?

Stephen — Fri, 29 Apr 2011 21:28:26 +0000

Who was it that said that once I left my position as creative director and went independent, that I would have more time to write on this blog?

And what were they smoking?

It’s okay to do adaptive layout. Really.

Stephen — Tue, 22 Feb 2011 21:31:28 +0000

Vasilis wrote yesterday about how he altered the layout of the Tropenmuseum website (English homepage) to adapt to different screen sizes.

Then came the comments. Nothing really wrong with any of them, but the whole “layout is not the only thing that should concern you; performance/context/content/blah is also (maybe even more important)” thing is getting very tired. Why? Because nobody is saying those things aren’t important.

Here’s a fact: If the homepage of site [x] is 100kB, then it’s 100kB. If I make that page look decent on several devices via adaptive layout—unless I go overboard—it is still going to be 100kB. Okay, maybe 101kB. It’s either zoom hell or not. So people can complain about that, but unless they’re willing to add to the client’s budget, the extra layout flexibility is (often, not always) a relatively quick readability and usability win. Device-agnosticism should be baked into the design approach anyway. There’s absolutely no harm in it.

So no, do not ignore content strategy and performance. And if you do content strategy, then you’d do well to be thinking about design. Device-agnostic design applies here as well.

Don’t feel bad about doing adaptive layout just because these other things are also important. It’s okay. Really.

Upcoming speaking engagements

Stephen — Mon, 21 Feb 2011 19:52:57 +0000

When I left Cinnamon last October to focus more on strategy and device-agnostic design and development, I also had another goal in mind: more speaking. I also wanted to write more; you can see how well that’s working out for me :).

I love speaking. Except for a couple of hours beforehand, when I’m so nervous I feel like throwing up. The past few years I’ve done quite a bit of speaking at conferences and events for clients, and that initial nervousness is there every single time. Fortunately the feeling subsides after the first few minutes of the talk.

I tend to talk a lot, and speaking engagements are a way to channel that into something that might inspire someone, teach them something new, or start a discussion. At web design and development conferences, it’s no secret that the speakers learn from the audience in the same way the audience might learn from the speakers. It’s also no secret that the discussions outside of the sessions are at least as interesting and valuable as the sessions themselves.

I’m very excited to be speaking at two mobile-related events this first half of the year: Breaking Development in Dallas and Mobilism in Amsterdam.

Breaking Development will be my first conference talk outside of the Netherlands (and then in the US), which is somewhat ironic, considering that I’m an American expat. I’m absolutely thrilled to speak alongside some of the smartest and most inspiring people in web design and development today at both of these conferences. Just take a look at the lists of speakers:

If you’re interested in designing and developing websites and web apps for mobile (or for anywhere), you might consider attending one of these conferences. Or both, if you really love conferences.

If you do attend, please come over and say hi. Just remember that there’s some risk in doing that right before my talk.

New HTML5 beer logo

Stephen — Tue, 18 Jan 2011 15:58:32 +0000

Update: The W3C have updated their stance on this subject.

Finally, the moment we’ve all been waiting for: drinking beer is now part of HTML5! This puts drinking beer just ahead of cooking, and right alongside CSS3 as a “technology class” of HTML5.

Obviously, this means a lot for your expense reports while traveling, as the blob that is HTML5 slowly assimilates all of your activities, allowing you to claim you were working on web stuff the whole time.

To celebrate this milestone in web development, we here at the Haystack decided to step up and use Creative Commons to its full extent by giving beer the logo it deserves. The t-shirts are in the works, so stay tuned!

Background information

The HTML5 logo (excluding the beer) is licensed by the W3C under a CC-BY license.

There is no Mobile Web

Stephen — Fri, 07 Jan 2011 15:37:18 +0000

I’m not sure who said “Never complain, never explain” (Disraeli? Ford? Google’s not helping much), but it sure does apply to me, as I never heed the advice.

Today I posted the following on Twitter without thinking much about it:

“There is no Mobile Web. There is only The Web, which we view in different ways. There is also no Desktop Web. Or Tablet Web. Thank you.”

I certainly didn’t expect the enormous amount of retweets, which hopefully means that most people understood what I meant. But some didn’t, or didn’t agree with me. Which is a good thing, but only if my point is clear. So allow me to explain.

Most sites on the web are not built with specific mobile use-cases in mind. However, millions of people access these sites every day through mobile devices. They access a “normal” (whatever that means) website through their “mobile” device. In these cases, the presentation of the content on mobile devices is potentially important. As are the intrinsic characteristics of this content on the mobile platform; take image size as an example. Manufacturers cater to the users of “non-mobile” websites on mobile devices via things like zoom, which although inconsistent across devices, makes viewing most websites on a smartphone bearable. Developers can do their part by adjusting the served content or the presentation.

That said, simply adjusting the presentation of content or pieces of content on a website does not, in my opinion, constitute a “mobile website”. It’s a website for which the developers have considered the users of mobile devices and adjusted certain things accordingly.

As the venerable Thomas Fuchs points out, there are specific mobile use cases and thus mobile-specific websites or web apps. I agree. By the same token, there are websites and web apps which were designed with solely the desktop in mind (and oftentimes with a certain browser in mind). Yet we don’t speak of the “Desktop Web” when referring to these apps. Ironically, that’s exactly what we do with mobile.

To be honest, I can think of a few, but not many use cases of web sites or apps which are or should be exclusively mobile. It seems like the Mobile Web allows us to revisit all of the talk of inclusion, progressive enhancement and accessibility from years ago.

Much of this is semantics, I’m sure. I use the word “mobile” in my own job title, which obviously borders on hypocrisy. Why? Because if people understand the term this way, it’s easier for them to understand that part of my job is to consider users of mobile devices when doing design consulting for clients. So I use the term the way they understand it. It’s just not in line with how I see the Web personally.

Many developers also consider desktop browsers. And text browsers. And screen readers. And possibly print. Or e-books. Or whatever. Because the Web is about universally accessible structured content. Which data you get and use and in what form will depend on your device and your circumstances. Your context, if you are so inclined. And that will constantly be changing.

So maybe it’s a semantic distinction and I’m simply exaggerating like the American I am. But as long as there are developers selling and building completely separate mobile websites or iPhone websites or iPad websites where well-designed universal websites would suffice, it’s not only a semantic distinction.

One web.

Death to web services. Long live web services!

Stephen — Fri, 17 Dec 2010 10:38:08 +0000

Yahoo! is apparently shutting down Delicious, which has people falling all over themselves backing up their own data from the site and putting their bookmarks onto lesser-known services, which I’m sure will all exist until the end of time. These moves are sometimes underscored by many on Twitter by claiming that these other services “are better than Delicious anyway”, which they very well may be, although these comments reek of justification. No need: if you want to move your bookmarks, they’re yours. Just move them.

But that’s the thing: we’re talking about bookmarks, the loss of which will hardly leave you living out of a cardboard box. And what happens when bad things happen to Flickr? GMail? Evernote? That site you do all your finances on? Project management and invoicing? Time tracking?

You may back up all your data, which makes the downfall of any of these services less painful. Unless you just keep your original photos on your own computer, but all of your photo metadata was entered on Flickr and you have no backup of that. Poof! But we all know Flickr’s not going anywhere, right? Too many users. Actively developed. Very popular. Cough. It’s the same reason we can depend on YQL (which I still find absolutely brilliant BTW). Yahoo! will give us all at least six months notice if they decide to pull the plug on YQL, which gives us the time to change all of the client work we made utilizing it. And of course our clients will have six months to get a budget to hire us to make the necessary changes.

But what are we complaining about? It’s all free. Having to move our bookmarks is not really a huge problem, but we all seem appalled that large companies care about money. Since when is this an anomaly? Company sees something cool, hopes to make money, buys it, doesn’t make enough money, poof. Here’s a truth for you: most companies only care about your data insofar as this data can help them make money. They have this site and you fill it. You fill it.

A couple of years ago I was on the fence about this. No longer. For a while we’ve posted our data all over the internet on all types of services. These services provide APIs so we can access the data we put into them, so that we can do things with that data. Read that again.

Richard Stallman, in his usual come-out-swinging way, has commented on this before. And I believe he has a point. Our data is our own, and it’s up to us to look after it. But how?

What if we flipped this all on its head? What if we hosted our own data, and provided APIs for all these webapps so that they can use our data? I can imagine that to be a substantially cool use of RDFa/Microformats and whatever metadata/semantic web technologies you prefer. Isn’t one of the points of the semantic web to make decentralized information meaningful, retrievable and mixable?

So instead of having our own websites aggregate our own data from other people’s websites, we’ll let other people use the data from our own websites. Photos, meaningfully tagged, can be pulled in by Flickr via our own personal API, if you will. We provide the structured data, Flickr provides the functionality. The sharing. The social. Why not?

Personal publishing platforms like WordPress, Drupal, [your favorite here] could be extended to make use of microformatting, RDF, etc. and provide tools for syndication, as we now do with simple blogposts. Services don’t need to host our data. They only need to do cool things with it. So when I quit service X, or service Y falls the Way of GeoCities, I don’t need to do anything but cancel my account. Or leave it and forget about it. If I change my information, it’s automatically changed on all the services using it. Storage space is up to me. Privacy settings? Totally up to me.

Awesome, providing the host doesn’t go *poof*.

Let’s get to it.

[Disclaimer: As some services die, some of the above links will rot. Make of that what you will.]

[UPDATE: Please also read Jeremy Keith's related post from 2008.]

New Flexbox tutorial on HTML5Rocks

Stephen — Mon, 18 Oct 2010 12:57:39 +0000

A couple of weeks ago, Paul Irish posted a quick look at CSS3 Flexible Box Layout Module at HTML5Rocks.com. Some of the material was borrowed (legally and with my blessing, of course) from my own tutorial. Paul has added a few niceties. As for placement on HTML5Rocks.com, Paul sums it up nicely:

Fronteers 2010 recap

Stephen — Thu, 14 Oct 2010 18:18:46 +0000

I know, I know. It’s been a whole week. What can I say? I’m glad to have so much work.

Fronteers 2010 in Amsterdam was definitely the best Fronteers yet. I was honored to have been invited to speak for the third year in a row. As Chris Heilmann points out, the two of us share that privilege, and a privilege it is; the Fronteers team has put the conference on the map as one of the top front-end design and development conferences around today.

Aside from speaking, Fronteers was a great opportunity to see some friends again and meet new people, and to see some of my favorite web talents speak as well:

Day one

Day one kicked off with Jeremy Keith on HTML5. Jeremy is one of the best thinkers in front-end development and a *fantastic* speaker. He presented a clear overview of past, present and future HTML5. I also finally got to meet him in person after reading so much of his work through the years. And, he built Huffduffer, which you should try.

Robert Nyman. What a character. A very informative presentation peppered with images of celebrities, which misdirected the audience from the fact that Robert has cloned himself several times in order to keep up with all his work.

I’m a big fan of SVG, so I thoroughly enjoyed Brad Neuberg’s presentation, which could have easily been called “show off and make your friends jealous with SVG“. A well-rounded look at this vector graphics format.

Håkon Wium Lie shared stories and images about the beginning of the Web and the history of CSS. Especially enlightening was seeing a picture of the world’s first web server. He finished up by sharing some of his ideas about the future of the Web. Since he is CTO of Opera Software, I do of course expect him to get CSS3 Template Layout implemented soon. To this end, I had to have a little chat with him during the break.

I loved Stoyan Stefanov‘s session on performance. Lots of little tricks in this presentation and some things I didn’t know, but can apply today. Good stuff, and a super-nice guy.

I’ve admired Jina Bolton‘s work for a few years. She’s done a lot of work educating people about and promoting CSS, and it’s easy to see why. While her subject matter was tried and true, it served as a good confirmation of some best practices, especially within teams.

Jake Archibald‘s presentation on design principles for building APIs was insane. Jake’s presentation style is a flurry of insight and humor. There was plenty to learn and lots to laugh about. Absolutely awesome presentation.

Day two

I kicked off day two, basically discussing progressive enhancement all over again in light of the current obsession with media queries. The slides were minimalist, but I found using SVG quite flexible. (Some people have asked about the slides, so I will post the SVG file very soon, with an explanation of how I made the slides).

Real-world Responsive Design

Moving on…

Paul Irish… what can I say? The Web is his little plaything, and does pretty much whatever he wants it to.

Meagan Fisher‘s slides were gorgeous. She walked us through the subtle use of texture, rgba() and text-shadow and box-shadow to turn a bland, wireframe-like page into something delicious.

I didn’t get to see Nicholas Zakas’ presentation on High Performance JavaScript, as I was drafted by Andy Clarke and Dan Rubin to take part in their talkshow session which took place in a second room. It was a fun session, and should have lasted at least another half-hour, as not all questions could be answered in time. As far as Nicholas goes, I can’t wait to see the video of his presentation.

Steve Faulkner and Hans Hillen talked about HTML5 accessibility, and the message was pretty much that it’s not ready yet. But they did give some valuable tips for introducing some WAI-ARIA into your HTML. Christian and I especially loved the slides.

As a big fan of Robert Hodgin‘s work, it was great to see Cameron Adams talk about animation on the Web. Cameron’s presentation also challenged the Flash-bashers, certainly causing me—and probably many others—to stop and think about which technologies are better suited to which goals. Cameron is also a great guy to have a beer with.

As far as I’m concerned, the star of the show was Chris Heilmann, with his inspirational and hilarious presentation designed to motivate us to Go Forth and Make Cool Stuff. Being the web developer’s answer to Anthony Robbins is no easy task, and Chris pulls it off beautifully.

All in all, I had a fantastic time. My compliments go out to the Fronteers team; they really did a superb job putting this conference together. I think we can expect great things for next year!