Fronteers 2011 Day 2 – more thoughts
The second day promised to match the quality and depth of the talks on the first day and it totally fulfilled that promise. Although it started off a bit rocky for me, because I arrived about 20 minutes late for the first presentation, I still managed to get the most important information out of it. So let’s go through the various talks.
Web Components and Model Driven Views – Alex Russell
At Informaat we’re building something with similar features, but that could become much easier using these innovations. Although I don’t see a use for this in a regular website, it will be much easier to build a web app. For instance, if you need a login box, you can make it into a web component and make it very easily reusable. I’m interested to hear and read more about this, but I’ll have to look at Alex’s presentation again when the video is up on the Fronteers website.
The New Developer Workflow – Divya Manian
Following up after the break was Opera’s Divya Manian, talking about the new developer workflow. She was a big fan of SASS/Compass, which are CSS preprocessors. They allow you to use mixins, variables and functions within a CSS-like syntax. This code is then run through a tool that converts it all to CSS. Another one of her points was the fact that Photoshop mockups don’t account for things like interaction, impatient users and the general complexity of the web. This makes it hard to build a site based on nothing more than a few Photoshop files.
She then moved on to the 2012 workflow for a developer:
- Get to know your developer tools, use the browser to see where you are heading.
- Make use of Version Control Systems to go through iterations of the project. Divya advised to get to know Hg or Git.
- Make design choices based on the supported feature set. The web ecosystem is much larger nowadays, when you decide to use a certain new feature, you need to figure out what to with browsers that don’t support (fully).
- Vendor prefixes are a necessary evil, you can use prefixr to generate the needed code.
- Use preprocessors. They make life much easier when working with complex CSS. Also keep in mind the lifecycle of W3C specs. Once they turn into Candidate Recommendations, the browser vendors will start to accept prefix-less properties.
- Build scripts also help to make life easier and optimize stuff for deployment.
HTML5 Forms KISS time – Robert Nyman
Mozilla’s Robert Nyman is one of my personal favourite speakers, because he comes across like a regular developer. Don’t get me wrong, he’s good at what he does, but he doesn’t make me feel like I’ve just started :). At Fronteers 2011 he spoke about HTML5 form elements and his talk basically proved that although it is possible to use them in production, you will need to explain to your client or boss that websites don’t have to look the same in every browser. The implentations for certain aspects (like error messages) vary wildly between browsers, as do the styling capabilities. It is being worked on and with the current release rate of chrome and firefox, it should improve in those browsers pretty soon.
After a short introduction, he started with a summary of the new input types. These are mostly useful for mobile browsers (read: iPhone and Android) as they support various input methods for specific fields (e.g. a date picker for an <input type=”date”> field). Next up were the various new attributes, e.g formaction, formenctype, formmethod, formnovalidate and formtarget on submit buttons. Robert showed a slide with these last attributes on an <input type=”submit”>, but they will work on the <button> element as well (source). He also mentioned the other new attributes, but that list is too long to repeat here. Check his slides for those :).
He moved on to the few new form elements in HTML5, starting with the <datalist> element. By adding the list attribute on an <input type=”text”> element and setting the value to the id of the <datalist> element, HTML5 allows us to create a combobox field; a field where you can type in text and it then shows you items from the datalist that match the typed text. At any time, you can click on an item in the list to put it in the text field. Useful stuff!
After a couple of more elements, he moved on to the built-in form validation of HTML5. Most of this stuff is already quite well documented on the web, but I noticed a few things that I hadn’t heard yet.
- First was that having a field that was hidden and required, would result in weird behaviour in various browsers. Some would show a dialog, others wouldn’t. Chrome and IE wouldn’t submit the form.
- Email validations don’t allow for international characters, e.g. röbert@html5.com wouldn’t validate, even though it’s a valid email address.
- If you use pattern matching, empty fields will validate.
- Chrome will use the title attribute in the error message for required fields. Other browsers will just show “this field is required”. Mozilla has a vendor-prefixed attribute called x-moz-errormessage that will let you specify an error message.
The final part of Robert’s presentation discussed the styling of these new form elements. There are various pseudo-classes available for styling required, valid, invalid and out-of-range fields. However, a big shortcoming of using the invalid pseudoselector is that it applies from page load. So before you’ve even had a chance to type anything, you’re already wrong. Firefox fixes this with the moz-ui-invalid and moz-ui-valid pseudoselectors, which is of course vendor specific.
CreativeJS, beauty in the browser – Seb Lee-Delisle
I’ll be honest, this was the most inspiring presentation of the entire conference. Seb Lee-Delisle makes some really nice stuff, like this digital, interactive fireworks. The first half hour of his talk, he showed us how it’s very easy to create a particle that behaves semi-realistically. The trick is to not try to emulate every little bit of physics, but just enough to convince an audience that it’s real. By uncommenting a few lines in code he had already written, he managed to show us how realistic looking smoke could trail your mouse cursor. It might not be something you’d implement on the corporate website tomorrow, but it does show the creative and beautiful side of programming. A nice change from insurance forms!
The second half was even more impressive. By using the conference wifi (which was excellent by the way!), Seb took control of our iPhones and Android phones and after several crashes of the software, he managed to sync us up and use each phone as a pixel to display something silly, like an animated pacman. I’ve never seen a presentation with live coding where the code failed so miserably at times and yet have an audience cheering with enthousiasm through the whole thing. Nerds can be so easy to please ;). Again, it’s not very useful in a corporate environment, but it’s as much fun as you can have with a couple of phones this side of Wordfeud!
jQuery and the Open Source process – John Resig
Mr. jQuery himself explained how to successfully run an open source project. Basically, it all boils down to a few key things:
- Always listen to your users. Help them through every step of the learning process by offering tutorials, advanced documentation and being there with advice when they ask for it on a forum or mailing list.
- Make your API easy to understand and use, and keep it consistent across releases.
There was more to his story, and hopefully he will release his slides soon, so I can jog my memory
In your @font-face – Jake Archibald
Jake Archibald is a presenter that always knows how to get the audience laughing. The secret is pretty easy: just throw some cocks in your presentation and talk about cool stuff in a nice northern English accent and most audiences will enjoy it. To be fair, in this presentation, he only had one cock, and it was right at the start to explain he wouldn’t use them anymore. So what did he talk about? Well, Jake did extensive research into fonts on the web. Starting off with an explanation about how it came to be that fonts even can be licensed (they’re not art, but after converting them to svg, they can be licensed as computer programs). After that history lesson, he moved on to explain how fonts moved through various DRM-riddled formats and that that’s why various browsers only support a specific font type.
He then moves on to fonts in the browser. Apparently, 17 years ago it was very easy. One <link rel=”FONTDEF”> declaration at the top, and via the <font> tag, the font could be used. Netscape supported it natively, IE needed a plugin. Happiness. Then IE4 came along with something called “embedded fonts”, which basically are TTF fonts in a DRM container. This worked with the @font-face declaration in CSS. CSS2 brought some more stuff to @font-face: the format specifier. This way, you could include various formats, supported in various browsers. And now, there’s CSS3 and we need 4 font declarations: eot, woff, truetype and svg. I agree with Jake, the world has become a better place in those 17 years.
So after arriving in the present day, he takes a look at how various browsers support the various bits of the @font-face declaration. He’s looked at what is supported and which browser downloads each font. The results are pretty bad. Several browsers download all fonts, even though they don’t use them. To make matters worse, IE<9 has a bug where it doesn’t quite get the multiple declarations so it needs a # after the .eot filename. And of course, there’s compatibility mode, which makes matters even more screwed up, because it fails to comprehend the format specifier and therefore downloads no fonts at all. If you look at one slide from this presentation, make sure it’s slide #38. That shows the progress we’ve made in 17 years :).
After having sorted that mess, Mr. Archibald moves on to more misery: how fonts are downloaded. Apparently, it’s possible to have fonts consisting of only one (or a few) characters and the browser should figure out if it needs a font to render an element. Chrome/Safari load the first font as soon as the page starts loading, and all other fonts are loaded sequentially after the HTML is done. They never get round to firing the onload event. Firefox does it slightly better, by loading the first font same as Webkit, and then loading the other fonts in parallel after the HTML is done. IE just loads everything from the start, whether it’s needed or not. So if you use a font only on certain pages but not on others on your site, make sure that the pages that don’t use it don’t have the @font-face declaration in their stylesheet. It’s also possible to make Webkit behave like Firefox by adding a unicode-range property in the @font-face declaration. This property allows you to specify the characters the font contains. Oh, and Opera really makes a mess of things…
If you use fonts, try to optimize them by removing all glyphs that you don’t use in your text. For example, if you write in English, there’s no need to have charaacters with umlauts in your font, as they’re never used in English. If you do this, most fonts should be manageable after gzipping. You could also remove hinting, but that basically screws everything up, except the file size, so don’t do it.
The last part of his presentation was about how things looked while the fonts were being downloaded. IE9/Opera first display the text in a normal font and once the font is loaded, they re-render it in the specified font. Webkit doesn’t display only text that has a standard font, all other text is not shown until the font is loaded. IE8 doesn’t show anything at all until fonts are loaded. The trick to fix IE8 is to declare font-face inline, before external CSS and before scripts, or load the font asynchronously. Google has created something called webfont loader, which allows you to have different styles for when the font isn’t loaded, when it’s loading and when it’s done.
Jake closes his presentation with a quick list of the various formats and how they came to be. He then uses a metaphor that I won’t repeat here, but let’s say we’re in a spot where we should say “stop!” If you want to know what I mean, just check out his slides.
The prestige of being a web developer – Christian Heilman
The final talk of Fronteers 2011 is always a motivational speech; something to make you leave the venue with your blood pumping with a desire to code the most awesome stuff ever. Just like last year, Chris Heilman had the honour of getting us all riled up. He’s an awesome speaker and very capable of getting 500 developers in a coding frenzy. I’m not gonna reiterate his entire speech here, because he has already posted it on his own website. However, I will add my own thoughts about his presentation.
I loved his use of Darwin’s often misquoted quote:
“It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change.”—Charles Darwin
Web technology is one of the most responsive technologies on the web. Therefore it will most likely survive and evolve to become even better. We need to figure out how to bring the cutting edge stuff into our day to day work and using it to move the web forward.
Finally, I also agree with his statement that we don’t necessary all need to be “rockstars”. We need to work together, not just on making awesomeness (as Leslie Jensen-Inman calls it), but also on making better documentation (e.g. adding some information to the Mozilla Developer Network or replying to a question on stackoverflow.com, etc.) And if you want to create an example, use something like jsfiddle.net, so others can take what you’ve made and improve upon it.
Heck, I’ll make a promise right now: once a week, I will spend time to add documentation to the MDN wiki. That should make Mr. Heilman happy