Currently my better half Kasia is working on a JavaScript training course and wanted to explain the concepts of JavaScript with a game. So we sat down and did a simple game example whilst she was fretting over the structure of the course. As she wanted to explain how to interact with the DOM in JavaScript rather than using Canvas we had some fun using CSS animation in conjunction with simple keyboard controls. More on the game in due time, but here is a quick thing we found to be extremely useful and not really used enough in the wild – the interplay of data attributes, CSS and changing states.

Defining a player element

We wanted to make the game hackable, people playing with HTML could change it. That was more a request by me as Mozilla has the Webmaker project and there will be a lot of game hacking at Mozfest in November.

In order to define a player element the semantic fan in me would do something like this:

<div id="player">
	<ul>
		<li class="name">Joe</li>
		<li class="score">100</li>
	</ul>
</div>

This makes sense in terms of HTML, and is accessible, too. However, in terms of accessing this in JavaScript, it is quite annoying as you need three element matches. Also in terms of maintenance it means three elements. In JS you’d need to do something like:

var player = document.querySelector('#player'),
    name   = document.querySelector('#player .name'),
    score  = document.querySelector('#player .score');

In order to change the score value, you’d need to change the innerHTML of the score reference.

score.innerHTML = 10;

Aside: yes I know there are lots of HTML templating solutions and I am sure dozens of jQuery solutions for that, but let’s stick to vanilla JS as this was about teaching that.

A HTML5 player element

Instead of going through these pains, we found it to be much easier to go with data attributes:

<div id="dataplayer" data-name="Joe" data-score="100">
</div>

The clever thing here is that HTML5 already gives us an API to change this data:

var player = document.querySelector('#dataplayer');
 
// read
alert('Score:' + player.dataset.score);
alert('Name:' + player.dataset.name);
 
// write
player.dataset.score = 10;
 
// read again
alert('Score:' + player.dataset.score);

Re-using attribute values

Another benefit of using data attributes is that CSS gets them. Say for example you want to show the colour of the score value in red when it reaches 10. In the first HTML using a list you’d need to do the testing in JavaScript and add a class to have a different display. You could of course also change the colour directly with the style collection but that is awful in terms of maintenance. It can cause reflows in your rendering and also means another thing to explain to maintainers.

function changescore(newscore) {
	if (newscore === 10) {
		score.classList.add('low');
	} else {
		score.classList.remove('low');
	}
}

#player .low {
	color: #c00;
}

Aside: jQuery has contains(‘foo’) to match elements with the text in their node content in the selector engine, but it has been deprecated as a CSS standard, so that is not the way to go.

When using data attributes you don’t need that – all you need is an attribute selector in CSS:

#dataplayer[data-score='10'] {
	color: #c00;
}

To display the scores you can use generated content in CSS:

#dataplayer::after {
	content: attr(data-name);
	position: absolute; 
	left: -50px;
}
#dataplayer::before {
	opacity: 0;
	content: attr(data-score);
	position: absolute; 
	left: 100px;
}

Check out the following fiddle to see all in action: http://jsfiddle.net/codepo8/BMY6H/

The only downside I can think of is that only Firefox allows for transitions and animations on generated content. All in all we found data attributes incredibly useful though.

Comments? Here are the threads on Google+ or Facebook.

Last week the fifth annual Fronteers conference lured a few hundred developers, designers and managers to Amsterdam, The Netherlands to hear about what’s hot and new in web development. This year I did not speak, but played the MC and interviewer instead.

I have a very soft spot for Fronteers as a conference. I spoke at every one of them and I am always amazed by how much the audience knows. You speak to a group of experts and as such speakers are expected and do deliver sensible, useful talks with lots of technical detail.

Having an audience in the know also makes for a buzzing back channel at a conference and in the past this one was ruthless – shooting down speakers who held back or didn’t know 100% what they were talking about in flames.

In order to turn this into a more productive environment I proposed to the organisers last year that I’d volunteer to introduce the speakers and instead of a traditional Q&A do a sit-down interview with them directly after the talk. I’ve done this before at Highland Fling and found it to be a much more efficient way to handle questions.

And that’s what we did. As Fronteers has a working wireless it was simple to convey to the audience the procedure:

• I introduce the speaker
• The speaker gives his presentation during which the audience can tweet questions they have using the #fqa hashtag (Fronteers Q&A)
• I sit down with the speaker on the side of the stage and conduct an interview using the questions during which the next speaker can set up

All in all this is an incredible effective way of running the conference as you use the time normally wasted in between speakers and you get much more questions answered. There is no waiting for roaming microphones and there is no “can you repeat, I can’t understand you”. Having a 120 character limit also means that people think of their questions much more.

Here are all the talks with a quick note by me and links to the collected tweets. I will try to contact all the speakers to grab them and answer them on their own blogs which I will link from here should that happen:

Fronteers Day 1

Mark Boulton, Adapting to Responsive Design

I’ve just seen Mark talk at Smashingconf and at Reasons to be Creative and still I am not bored of him. Good insights and a very “story telling” approach to speaking.

Addy Osmani, The New And Improved Developer Toolbelt

Addy works tirelessly to collect great information and build and connect tools to make our lives easier. This talk covered the need for tooling and build processes and ended introducing Yeoman. All in all this was a good talk, but to my taste it had far too much content. At times Addy read out his slides with a sentence per bullet to the audience and I found myself basically wanting the deck as I was overwhelmed with the offerings.

Peter-Paul Koch, A Pixel is not a Pixel

PPK did a great job explaining why viewports and pixel densities are not an easy matter and showed a lot of examples how hard it is to build a consistent experience across various browsers just on one device. A good advertisement for PPK’s research into the matter and why we need it.

Alex Graul, Using JS to build bigger, better datavis to enlighten and elate

Alex gave me the first slight heart attack of the event as he had a mix-up with his slides, spoke far too fast and hard to understand if you are not used to speaking to Britishers, and finished after 15 minutes or so. This is where I came in to cover 35 minutes of Q&A until the catering staff was ready for the feeding of the hordes. It was incredible to see though how Alex caught himself and calmed down a lot when in an interview situation rather than a “where are my slides, what is this” one. I think all in all I got much more out of Alex than he’d have covered in his talk this way and as the topic was incredibly interesting it was easy to chat for a bit.

Mathias Bynens, Ten things I didn’t know about HTML

Mathias is dangerous. He is very intelligent, charming and does a lot of research into the ins and outs of markup and browser rendering. Based on that he shows us just how much code is not needed to write for a browser to show a page. That this code is necessary for people to understand what you do is something Mathias believes a lot himself, I just hope that when he says it people still listen rather than just going for the quick “oh, good, I need no closing tag”. Talent like Mathias makes me confident about the future of the web, when I will be sitting on my porch, chasing ducks with my cane and grumbling about darn kids eating my cherries.

Stephen Hay, Style guides are the new Photoshop

Stephen, the only other speaker apart from me who spoke at every Fronteers, is an institution and rightfully so. In this talk, which he also gave at Smashingconf he showed how to automatically generate style guides from mockups, thus making our workflow much shorter. A designer who likes the CLI and uses VIM. What more do you want?

Antoine Hegeman, Bor Verkroost, Bram Duvigneau & Chris Heilmann, Accessibility panel

OK, this was the moment in the conference where I was – as one says – shitting bricks. I know my a11y and I have seen live demos of a11y technology fail spectacularly on stage over and over again. It shows just how professional and pragmatic the panelists were that nothing went wrong at all, and I’d say that this was one of the most informative a11y sessions at a conference I’ve ever seen.

Lea Verou, More CSS secrets: Another 10 things you may not know about CSS

Lea once again dazzled with amazing CSS tricks, once shown before at Smashingconf and coded live on stage. Great stuff, but she was quite over time sadly enough. That said, play with what she showed here, lots to learn.

Fronteers Day 2

Marcin Wichary, The biggest devils in the smallest details

Marcin is the master of Google doodles, builds his own slides using two browsers talking to each other via Node, doesn’t get phased too much when he drops his laptop on stage and in general is a total tinkerer. Great speaker. Lovely, lovely talk.

David DeSandro, Keep it Simple, Smartypants

David changed his talk in the last minute after realising how much in the know the audience is and instead of his planned session talked about trying to make money with “open source” JavaScript solutions and how it can be done. This was the most animated interview I did as there seems to be a massive misunderstanding what open source means. I will blog more about this soon.

Jeroen Wijering, The State of HTML5 Video

Jeroen is the man behind JW player, the HTML5/Flash video player in use in YouTube and seen a lot on the web. He covered the basics of HTML5 video and kept his talk very short which allowed me to dig a bit deeper into the newer unknowns in open media like streaming and DRM during the interview.

Anne van Kesteren, Building the web platform

Anne van Kesteren is scarily smart when it comes to the web, browsers and standards and in this talk he shared some of his thoughts and ideas. Sadly enough, I found the talk very confusing and lacking an overall story arc or goal. It all might become more obvious when I watch the video again, but I for one was more confused than inspired.

Phil Hawksworth, I can smell your CMS

Phil seems to be a clone of Jake Archibald who went to design school. Very funny, very quick, with beautiful slides and examples and tales from the trenches he knows how to engage and to give out good info to boot. To me one of the best talks I’ve seen lately.

Peter Nederlof, Beyond simple transitions, with a pinch of
JavaScript

Peter is a silent star. He does incredible work and participated with solutions in some of the larger breakthroughs in library code in the past without tooting his horn much. The same happened here. Peter had some great examples and code ideas but lacked the oomph needed to get people excited about it. All in all this would have been a kick-ass 15 minute lightning talk but felt stretched as it was. Nevertheless, use what he talked about, there is a lot of good in there.

Rebecca Murphey, JS Minty Fresh: Identifying and Eliminating Smells in Your Code Base

Rebecca is a trainer by heart and gave a very nice overview how to refactor and clean up stale JavaScript code that is based on laziness or “quick, get this out of the door” thinking. Good advice, but to me too much focused on jQuery. I’d like to see this at the jQuery conf as it reminded me of my talk there last year, with the main difference that Rebecca knows it inside out.

Alex Russell, What the legacy web is keeping from us

Alex is very smart indeed and delivered a talk that surprised me and made me happy. Instead of damning outdated technologies and pushing kicking and screaming into a more app-centric web based on current browser technology, Alex started with some thought experiments and built up to a great conclusion that it is up to us to free ourselves from the shackles of outdated tech. Splendid talk, go see it.

Summary

All in all Fronteers delivered again. And this was a massive surprise to me as I didn’t prepare anything and neither coached the speakers in time, nor knew some of the speakers. I also convinced the organisers in the last minute to go for the “interview Q&A” approach and scrounged chairs on the spot to make it happen. As it stands, I am damn proud having pulled it off and hope more conferences will follow the principle. For anyone who is out to do the MCing and interviewing: rest up, it is a truckload of work and quite exhausting as you need to be first there, last out and 100% concentrated on the content. Doing ad-hoc interviews with live questions coming in is not a simple feat, but when you do it, it is very much worth your while. I had a blast and I hope people got a lot out of Fronteers 2012.

Tomorrow the Core Mobile Web Platform Community Group is meeting the Mozilla space in London to discuss the future of browser benchmarking. Sadly I won’t be able to attend as I am at Create the Web London on the same day and flying to Amsterdam for Fronteers later. However, I think this is a good opportunity to mention some things I have thought about which my colleague Jet Villegas will also mention tomorrow morning for me.

Here is what I am worried about: browser benchmarks are very hot, but fail to deliver data that will help us make the web the main development platform.

Benchmarks are becoming marketing material

My main concern is that browser benchmarks as a whole are a very academic and “close to the metal” exercise. Creating and wiping an empty canvas or creating and destroying thousands of objects gives you results, but it doesn’t mean that real product needs are met by optimising for these use cases. Jet will talk about some issues that actually do bring up false positives unless you test in a real browsing and using the browser scenario.

Even worse is that the press is hungry for browser news and loves when big corporates shoot at it each other. That’s why a lot of benchmarks are flawed from the very start to give a better result for one browser or platform or another. They’ve become a marketing tool, rather than helping us building better products with the web. Above all though, they are very, very boring.

Making benchmarking fun again

Let’s wind back the clock a bit to 1997. You might not have heard of this but back then Final reality was all the rage. It was a product of the demo scene (closely related to the much acclaimed Second reality) and a very cool thing to watch back then. You can check the YouTube video to see what it looked like.

This pushed the limits of the video card, the sound system and the CPU and the amazing thing was that it was a benchmark. After the demo ran all the way through you got a report on how well your hardware did in the test. These reports were not only bragging rights amongst overclockers but also used by admins to test out if hardware works in 10 minutes that would have taken ages with conventional test methods.

So why don’t we do something similar now?

The benchmarking game

How about that instead of an automated script we’d have a game? This already happens in some games that are built by browser makers.
Bananabread – the 3D shooter that is converted from C++ to JavaScript and runs in the browser has a BananaBench which gives you data of how well the browser performed after you played:

However, this aims too high as sadly enough there is a lot of hardware out there that still chokes on WebGL and not everybody wants to play a 3D Shooter (I can’t be bothered, to be fair).

So how about this: a platformer or 2D shooter that gets incrementally more technically challenging to the platform the longer you play and offers extra levels to browsers and environments that support certain technologies and offers simpler ones to others.

Imagine a game that tests performance and reports it back after each level running on Facebook and being promoted in the Android (and Apple, yeah, a boy can dream) stores. People could play the game without being the wiser that they are actually helping us get real information from users on a large variety of devices on real (and flawed) connections and on browsers that are not 100% allocated to doing one task but have other tabs open and junk in their caches and RAM.

Why not?

Reporting everywhere

My other colleague Rob Hawkes is currently testing a lot of HTML5 games and compares the performance of different browsers on different mobile OS with these. This is great and a lot of work. I found that a lot of demos and also game demos have a developer mode that shows the FPS and the general performance. Wouldn’t it be great to have a database of this data instead of just seeing it on the screen for tweaking while we develop? There are systems like scoreloop who centralise the scores of games, why not the performance? This could be a whole new market in the HTML5 space.

Apps could of course benefit from that, too. Taking a well-used piece of software and adding performance reporting of – for example scroll-lists – would give us a lot of good information from our users rather than data built and reported in a lab environment. We could do Benchpress instead of WordPress?

Got ideas or want to contribute? Check out the thread on Google+ and on Facebook.

I had this great task to convert a PDF to JPGs, meaning a multi page PDF should become a lot of JPGs. I don’t own Adobe Acrobat Pro and I didn’t want to buy an extra piece of software for it. So I went for the thing that hardly ever lets you down – even it it speaks in tongues – the command line.

So here is how to convert a PDF to JPGs:

Install homebrew by going to the terminal and copying and pasting the following:

ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"

The script explains what it does while it runs. It is not the matrix, although it is green and full of text.

Next get Ghostscript – just go to the command line and do a:

brew install ghostscript

This can take a while, so get a cuppa on. Once you are done, here’s the command to convert a PDF to a lot of JPGs:

gs -dNOPAUSE -sDEVICE=jpeg -r144 -sOutputFile=p%03d.jpg file.pdf

The PDF is file.pdf and this will generate files called “p001.jpg” to “p004.jpg” for a 4 page document for example. You can change that with the p%03d.jpg setting above. For example plonk%04d.jpg would create plonk0001.jpg.

Once the conversion is done you are in the GS> prompt, just press Ctrl+C to get out.

Going through the Twitter feedback of my closing keynote at Smashingconf I read a lot of “this is awesome, I feel so ready to do stuff, but what can I do – I am not a known entity on the web.”.

I guess everybody has songs to listen to when need some perking up. You know, the ones that make you tap your feet or, if you are like me, bounce a bit. Friday I’m in Love by The Cure is a classic for that. One of my favourites is the Mighty Mighty Bosstones’ Everybody’s better:

The lyrics of that one have some wonderful moments:

Everybody’s better than I am
I think everybody’s better than me
And everybody’s swell I guess
They’re doing well some more or less
Everybody’s better than I am I think
You know to be king you don’t need a castle
To row back to shore can sure be a hassle
...
Why you walk around with your head low down
The true king rules without a crown
If your boat’s afloat after the typhoon
Row it safely back to the lagoon
And nevermind the green grass you won’t mow
...
Or what it is you have or don’t to show
Or what it is you can or can’t afford
The good are good without reward

I think there is a lot of truth in that – especially on the web. So if you are not a known entity on the web, so what? You are still very much invited to participate, your actions can speak for you and bit by bit you will get people thanking and encouraging you.

Lower profile = less pressure

You can get the warm fuzzy feeling without getting the pressure of having to be perfect in all you do. Once you are known on the web it can be quite annoying that something you throw out as an idea or a concept or a hack gets quoted out of context as the best thing ever and something to use immediately. As a part of the “making” web crowd you can play, get others to improve and build upon what you did and get feedback – good or bad – that is untainted.

With know web entities I find that not enough people challenge what they do and give constructive criticism. Instead there is a lot of polarisation going on – either people love your work or they try to show that you are wrong and their other heroes are right. Or people will attack you personally and disagree just to be part of the conversation and appear as someone in the know.

Everybody else is better

As mentioned in my keynote, there is quite a tendency in people to compare our behind the scenes footage with other people’s highlight reels. There is no need to go from zero to hero in a fortnight and it is not a natural thing to happen. I blame all the “talent” shows on television giving us that impression – it is the Tinseltown dream and the old from dishwasher to millionaire illusion pushed to a seemingly more achievable goal. Only seemingly, though.

Communication is a key

I don’t consider myself a web entity or a celebrity, but here is how I got where I am now: a lot of work. And not only paid work – on the contrary. Most of my connections and learnings happened outside the delivery cycle in my companies. They happened on mailing lists, IRC, forums, conference hallways, in cafés when people commented on my computer or what I did on the screen. It boils down to communication and being not afraid to ask questions and to talk to people.

It is not about a breakthrough product

One big mistake people make is thinking that quick products will get you known and a following. That can happen, but as they are quick products they are also a dime a dozen and hundreds of links on hacker news a day. I’ve made that mistake – a lot:

• A PHP templating system to allow for HTML/JavaScript documentation
• A “Learn to let go” PHP script that allows for users to define the page layout
• The “Obsoletely famous” blog to name and shame outdated web resources and re-link them to better ones
• The “CSS Toolshed”, a CSS Zen Garden but with a simulated CMS output – asking designers to come up with flexible CSS to support changing content and variable navigation item numbers
• A PHP script to allow for CSS variables by precompiling the CSS - in 2005

All of these were massive failures, and frustrated me quite a lot and ask myself what is wrong with me that nobody calls these awesome and mentions them in talks. There can be many reasons why they failed, but the main one was that I thought I’d build it and people use it. This is not how it works.

Collaborative work wins

All the products that got people known in the last few years were works of collaboration: Modernizr being probably the most shining example. So if you want to go that route, don’t go for the quick win and call it finished, throw out an idea and a stub instead and call for people to work with you.

The best way to get known and to have fun and achieve things though is to collaborate with existing projects, give feedback, write documentation and examples – in short, get yourself out there visible as a helpful person who knows their stuff. The MDN documentation is a great starting point as it is an open Wiki and needs some love in many places. And as soon as you edit your name will be under it.

So here’s to all the kings without a crown – you are doing great work, even if it doesn’t look it and the immediate success is yet to come. Have patience, share, communicate and give constructive feedback in the form of feature requests, pull requests and patches. Your work will be visible and speak for you – even if you are not yet a loud voice.

Got a comment? How about joining the thread on Google+