Archive for the ‘HTML5’ Category

File Under: HTML, HTML5, Web Standards
Jul
23
2012

Two HTML Standards Diverge in a Wood

By

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.

Tags: , , ,
File Under: HTML5, JavaScript, Multimedia
Jun
19
2012

JavaScript Decoder Brings High-Quality Audio to the Web

By

Image: Webmonkey

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.

That’s exactly what the developers at Official.fm Labs have been hard at work doing. The latest impressive release is FLAC.js, a FLAC audio decoder written in pure JavaScript. FLAC.js joins the group’s earlier efforts, which include decoders for MP3, AAC and ALAC.

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.

Tags: , ,
File Under: HTML5, Multimedia, Web Standards
May
23
2012

I’m Feeling Moogy: Google Taps Native Web Audio for Awesome Moog Tribute

By

The Web Audio API in action. Image: Screenshot/Webmonkey

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.

Behind the scenes the Moog doodle also uses Closure libraries and some CSS 3 for the design and custom fonts. Developers interested in how the Moog doodle works can check out the archived doodle page and peruse the Moog.js JavaScript file for full details (as with all Google scripts, this one has been optimized for file size; you’ll want to run it through JSBeautifier or similar before you try to read it).

Tags: , ,
File Under: HTML, HTML5, Web Standards
May
22
2012

Browsers at Odds With Web Developers Over ‘Adaptive Images’

By

So many screens, so few images (testing responsive sites with Adobe Shadow). Photo: Adobe

The web design community continues to debate the merits and drawbacks of the WHATWG’s proposed adaptive images solution.

As we reported last week, a new srcset attribute has been added to the <img> element in the WHATWG’s HTML specification. The new attribute will allow developers to specify different sized images based on the user’s screen size.

The idea is to find a way to serve smaller images to devices that don’t need large images — saving precious bandwidth — while serving high-resolution images to screens that warrant them. And the WHATWG’s srcset attribute does solve some of the problems surrounding adaptive images, but it’s far from ideal.

Now developer Jason Grigsby argues that not only will the srcset solution not completely solve the problem, but the goal of adaptive images is fundamentally at odds with how web browsers currently handle images. In other words, there currently is no way to solve the problem.

Adaptive images are at odds with how browsers handle images thanks to what’s known as a “lookahead pre-parser.” Browsers use lookahead pre-parsers to start downloading images as soon as possible (to speed page-load times), which means images are parsed and downloads started before the browser has determined the full page layout.

However, a truly useful adaptive image solution needs the browser to first determine the page layout and then determine which images to use.

Grigsby rightly calls it a chicken and egg dilemma. “How do we reconcile a pre-parser that wants to know which size image to download ahead of time with an image technique that wants to respond to its environment once the page layout has been calculated?”

Grigsby argues that the smart thing to do might be for browsers to eliminate pre-fetching:

For existing web content, the lookahead pre-parser is undoubtedly the fastest way to render the page. But if web development moves towards responsive images as standard practice, then delaying the download of images until the proper size of the image in the layout can be determined may actually be faster than using the lookahead pre-parser. The difference in size between a retina image for iPad and an image used on a low resolution mobile phone is significant.

That’s going to be a tough sell to browser makers right now. Browser makers are understandably loath to do anything that might slow down page-load times — even if that slow-down is temporary.

Other possible solutions Grigsby covers include progressive image formats (which suffer from similar chicken-and-egg dilemmas) and of course the <picture> element. The whole article is well worth a read since it gets into more details about why all of these solutions are ultimately less than ideal.

Tags: ,
File Under: HTML, HTML5, Web Standards
May
17
2012

Ready or Not, Adaptive-Image Solution Is Now Part of HTML

By

So many screens, so few images (testing responsive sites with Adobe Shadow). Photo: Adobe.

The web needs a more intelligent way to serve images.

No one wants to waste bandwidth sending large images over limited mobile pipes, but everyone wants images to look good on the myriad screens connecting to today’s web. Currently web authors use a variety of hacks to (incompletely) work around this problem, but to really solve it the web likely needs new tools.

Unfortunately, thanks to miscommunication between standards bodies, web developers and browser makers, instead of a solution to the image problem what developers got this week feels more like a slap in the face. Eventually an adaptive image solution will likely emerge, but the real lesson for many developers will be about how the standards process works and how they fit into it, if at all.

Webmonkey has previously looked at some proposed solutions to the adaptive image problem. Some very smart web developers came up with the idea of a <picture> element that works much like the current HTML <video> element. These developers thought they had the attention of the Web Hypertext Application Technology Working Group, better known as the WHATWG. Then, earlier this week, Edward O’Connor, Apple’s WHATWG representative, proposed another method of solving the problem, using a new srcset attribute on the <img> element. See our earlier coverage of the srcset attribute for a more detailed look at how it works and compares to the <picture> proposal.

What has web developers up in arms is that Ian Hickson, editor of the WHATWG spec (and better known as Hixie) has already added the srcset attribute to the WHATWG’s HTML draft spec, seemingly ignoring the months of effort that went into <picture>. Worse, members of the WHATWG apparently weren’t even aware that developers were putting forth the effort to come up with a solution via the Responsive Images community group. Nor were concerns about the srcset syntax given much consideration. Hickson does address some objections to srcset in his message to the WHATWG, but ends up dismissing most of them.

That doesn’t match up with how most people envision the web standards process. But as web developer and standards advocate Jeremy Keith writes, “this is exactly how the WHATWG is supposed to work. Use-cases are evaluated and whatever Hixie thinks is the best solution gets put in the spec, regardless of how popular or unpopular it is.”

In fact, think of the WHATWG as the source for initial, rapid development of new features. The group was started by browser makers because the W3C’s HTML Working Group (HTMLWG) moved too slowly. But if the WHATWG is the source of rapid development, the W3C is an effective check on that speed, ensuring that even those of us who don’t make web browsers still have a voice in the future of HTML. (see our earlier overview for more on the history and differences between the HTML WG and the WHATWG.)

While the HTML WG is also chaired by Hickson (a position he will soon step down from), it offers a much more democratic (and consequently slower) process and has overridden the WHATWG’s rash decisions in the past. For example the W3C added the time element back after Hickson removed it from the WHATWG spec.

Confused yet? It gets worse. The WHATWG is working on an ever-evolving standard, what it calls a “living standard,” which is different from — and may well diverge from — the snapshot-based standards issued by the W3C, like HTML5. In a comment on longtime web standards champion Jeffery Zeldman’s post on the matter, Jeremy Keith writes, “I don’t mind if the srcset attribute is in the WHATWG HTML spec but not in the W3C HTML5 spec. If it works, it’ll end up in a future W3C version number.”

Implicit in Keith’s statement is that if the srcset attribute doesn’t end up working out it won’t be in HTML5.x and would likely just fade away like the blink tag, the applet tag and other HTML ideas tried and later discarded.

Which is another way of saying developers need not panic. Perhaps web developers don’t have a voice in the WHATWG simply because we’ve been using the wrong channels (W3C community groups don’t seem to be an effective means of communicating with standards bodies, in fact they seem more like this.). If you’ve got ideas and would like a voice in the future of the web join the WHATWG mailing list and login to the IRC channel. Introduce yourself, learn the rules and contribute.

Tags: ,
« OLDER POSTS