This release is notable for a number of changes including a snazzy new website, cleaned up and reorganized code and the beginnings of a high-resolution-screen @media query. This release is also notable for what it lacks, namely the trademark pink text highlight color which has been ditched in favor of a more neutral blue.
Version 4 of Boilerplate also updates the various code libraries that Boilerplate relies on, including jQuery, Modernizer and the very awesome Normalize.css.
The four new editors include two Microsoft employees, Travis Leithead and Erika Doyle Navara, Apple’s Ted O’Conner and Silvia Pfeiffer of Ginger Technologies, a company specializing in HTML video.
“The Chairs received a large number of applications for the position of HTML5 editor,” writes Cotton. “After evaluating all the applications, we chose the above HTML5 editorial team based on the individual qualifications of the new editors as well as the combination of the individual appointee’s qualifications.”
The heavy representation of Microsoft is interesting given that Microsoft is not currently a member of the Web Hypertext Application Technology Working Group (WHATWG), the other standards body that oversees HTML. It would seem that Microsoft is doubling down on the W3C version of HTML.
The editor change is part of the recent split that sees the two standards bodies jointly responsible for developing the HTML specification, moving in different directions.
The W3C and the WHATWG have long acted as separate bodies, but previously shared an editor, Ian Hickson, who helped ensure that the two specs remained in sync. Then last year the WHATWG announced it was dropping the “5″ version number and would work on HTML as a “living standard” sans version numbers. The W3C continued to focus on HTML “snapshots” like HTML5.
“The WHATWG effort is focused on developing the canonical description of HTML,” wrote when he stepped down as W3C editor last week. “The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process.”
The two standards bodies that are jointly responsible for developing the HTML specification have cut the final tie that was binding them together.
The World Wide Web Consortium (W3C) and the Web Hypertext Application Technology Working Group (WHATWG) began to move apart last year when the WHATWG announced it would drop the version number and work on a “living standard” sans version numbers. The W3C continued to focus on HTML “snapshots” like HTML5.
However, despite that split the two shared an editor, Ian Hickson, who oversees both specs. Or did. In an e-mail to the WHATWG mailing list, Hickson announced that he is no longer the editor of the W3C HTML WG spec. The change isn’t unexpected; in fact Hickson announced it would happen over a year ago, but it does emphasize the growing distance between the two standards.
“The WHATWG effort is focused on developing the canonical description of HTML,” writes Hickson on the mailing list. “The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process.”
With different goals for each version of the spec Hickson says that “the chairs of the W3C HTML working group and myself decid[ed] to split the work into two, with a different person responsible for editing the W3C HTML5, canvas, and microdata specifications than is editing the WHATWG specification.”
Now, more than ever before there seems to be two versions of HTML. The question for developers is, what does this mean for the future of HTML? In the short term, very little.
The W3C will continue to develop its fixed-in-time snapshot of HTML5 and the WHATWG will keep going with the “living standard” approach. What some developers fear is that down the road the two specs will diverge in significant ways and HTML will become a messy set of forked standards and varying browser support that lands us back in the bad old days of IE 6.
Anything is possible, but we remain hopeful that that won’t happen, at least in part because the W3C standard is more of a branch than a fork.
If all goes well the process will remain essentially as it has been for the last few years: a browser adds some shiny new feature, the WHATWG documents it and other browsers implement their own versions. There’s an awkward, sometimes frustrating period for web developers while browsers tweak and refine their support, but eventually the dust settles and a new standard is added to the W3C’s version. It may not be a completely ideal process, but it is what’s managed to bring us this far.
HTML5′s native audio and video tools promise to eventually make it possible to create sophisticated audio and video editing apps that run in the browser. Unfortunately much of that promise has thus far been marred by a battle over audio and video codecs. Right now what works in one browser on one operating system will not necessarily work on another.
Until the codec battle plays itself out, developers looking to build native HTML audio apps are in a bit of a bind. One way around the problem is to bypass the browser and provide your own decoder.
Used in conjunction with the nascent Web Audio API, the new FLAC decoder means you could serve up high-quality, lossless audio to browsers that support HTML5 audio. But beyond just playback the Web Audio API opens the door to a whole new range of audio applications in the browser — think GarageBand on the web or DJ applications.
To that end Official.fm Labs has been working a framework it calls Aurora.js (CoffeeScript) to help make it easier to build audio applications for the web.
If you’d like to experiment with Aurora.js or check out the new FLAC decoder, head on over to Official.fm’s GitHub account where you’ll find all the code available under an MIT license.
Google is celebrating electronic music pioneer Robert Moog’s 78th birthday with a Google doodle of the iconic Moog synthesizer. Like many past doodles today’s doodle doesn’t just look cool, thanks to the Web Audio API, it’s also a working synthesizer complete with a reel-to-reel tape machine for recording.
The Moog Google Doodle uses the nascent Web Audio API to create a mini Moog and power a mock reel-to-reel recorder. At the moment browser support for the Web Audio API is limited, but the doodle will work in most browsers since it falls back to Flash where the Audio API isn’t supported (the doodle does not work in Internet Explorer).
To play the Moog, just click any of the keys so that it gains focus and then you can play using your keyboard. All the nobs are fully functional as well, just click and drag to change the settings. Hit the record button and you can save your songs and share them with others.