Articles for August 2011

Mozilla would like to introduce WebAPI with the goal to provide a basic HTML5 phone experience within 3 to 6 months.

Continued…

What’s new in Firefox 6?

The most notable addition to this new release are the <progress> element, touch events, Server-Sent Events as well as the return of WebSockets.

The <progress> element

This element can be used to give a visual cue of something in progress in the page. System progress bars are being used, which means that users of MacOS and Linux will see something different than what is pictured here.

Touch events

The standard Touch events are now available on both Firefox “desktop” and mobile, enabling users to interact with web pages using their fingers on a touch screen.

Try this minimalistic touch demo.

Server Sent Events

Server Sent Events are a mean for a server-side script to generate client-side events accompanied with data.

Messages generated on the server-side with a text/event-stream mime-type and consist of a list of events data.

data: data generated by the server

data: this line will generate a second event

Have a look at the Twitter-like timeline built with server-sent events.

WebSockets are back!

WebSockets can be used to create an interactive communication channel between a browser and a server. They are already used to build “HTML5” chats, multiplayer games, and much much more.
Note that this API will be temporarily namespaced in prevision of upcoming changes to the specification.

Other changes

You can help us improve those changelogs by telling if you find the level of details appropriate.

HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.

Today we are featuring Divya Manian, Web Opener at Opera Software.

Most likely you came across Divya because of her involvement in HTML5 readiness and HTML5 Boilerplate. She is available on Twitter as @divya and is very much involved in the CSS standards working group.

As you will see in the interview, Divya is a very pragmatic person when it comes to web standards and has a big passion for educating developers instead of woo-ing them.

The video interview

You can see the video on any HTML5 enabled device here (courtesy of vid.ly).

10 Questions for Divya Manian

1) I feel that right now is a terribly exciting time to be a web developer. Would you agree? What gets you really excited about the new tech we have to play with?

Definitely. These are exciting times for a web developer. You have new tools to work with almost every other week and what your page is capable of doing has expanded significantly from just delivering static content to enabling real-time media streaming and more. We also have very strong developer tools for each browser: Opera’s Dragonfly, Chrome’s Developer Tools, IE Developer tools in addition to the original trail blazer Firebug. So, it is simultaneously easier and harder to develop for the web.

2) Back in the days we very much preached separation of concerns as the right way to build web products. HTML is for structure, CSS for look and feel and JavaScript for behaviour. It seems to me that with new technologies this strict separation is blurring a bit. We can generated content in CSS and animate and transform. Some HTML5 elements do nothing without JavaScript (canvas being the big example). Do you think we need to re-visit our best practices?

Yes, the new features do definitely make you think harder about what you put where, but they do enable a similar separation still, except there are nuances to be aware of when you do the separation.

For example, I would consider animation with JavaScript as a way around the roadblock of not being able to do natively. Browsers are in a better position to control most of the animations that we require (animations for gaming are slightly different ballgame), and doing them natively would get us better performance in the long run.

Personally, for me maintainability and writing something readable and that works well and efficiently is more important than just being driven to compartmentalise your code into HTML/CSS/JS.

And definitely we do need to revisit our best practices every so often because technologies change and our best practices need to change with them, none of them are enshrined in stone and we should keep them relevant to our current set of features/technologies.

3) In your post “This revolution needs new revolutionaries” you point out that a lot of the people who drive the web today are not the known luminaries of web design. Do you see a complacency in our advocacy of web standards?

There are two concerns for me in that post:

1. we are not hearing enough from people who have to deal with creating web applications that work in areas with poor internet connections, censorship, with content in languages that are not popular.

2. There are not enough do-ers who are talking, we are hearing from the same people again and again on similar topics.

I feel strongly about both, but more so about #2 because it impacts every web developer all over the world. There are changes that are occurring that most of them are unaware of, because word does not get out. I think we should do our best to encourage those who do actively seek to create tools, and help fellow web developers or work on interesting challenges for the web to speak and inspire rather than those who are known for their speaking abilities because ultimately we want people to use/work with what is best for the web and not just be informed of what was news 5 years ago.

4) I found lately that collaboration is getting easier and easier. Tools like github, JSBin and JSFiddle allow you to talk about code and get your readers to fix and change things with you. I did that lately with getting bullet proof 90 degrees turned headlines for example. Why do you think not that many take advantage of that opportunity?

I would be hesitant to say not many are taking advantage of these tools. They are, but it is true that not everyone is on the bandwagon yet. Github is certainly the most gentle and social introduction to version control you can get, but a lot of web developers are not programmers and have not seen enough pain and horror to know why version control systems are useful. It also requires knowing about what version control systems are, and how to use the command line (a bit), which might be scary for those who are just used to designing with IDEs or TextMate.

5) CSS seems to be moving in leaps and bounds right now. I for one am very excited about the CSS element property which allows to take screenshots of elements. Are there any lesser known extensions you are fond of and use?

I am not a big fan of vendor prefixes, and would rather see them quickly unprefixed rather than see more of the prefixes populating stylesheets more and more.

That said, I do like a lot of the new properties that we are experimenting with. We have the obscure tab-size which allows you to control the width of the ‘tab’ character in your content. Pretty useful when you are displaying code.

Opera also introduced the @viewport which will let you set the viewport from within your CSS rather than using meta tags (like <meta name=”viewport” content=”width=320″>). I think viewport belongs to CSS rather than markup, so I would love to see it gain adoption.

Some of the less known properties such as box-sizing (unprefixed in Opera, IE 8+, Safari 5.1+, Chrome, prefixed in Firefox) are also invaluable, as they let you control your box model, which is definitely a revolutionary step from the dark days of trying to work with separate box models.

6) When we had a longer chat before this interview we discussed that there seems to be a disconnect between what people show on stage at conferences and what people can use these days in their day-to-day jobs. Do you think we should remedy this? More hands-on stuff for people to use now rather than a “look what is possible” approach?

I think what gets shown on stage is partly entertainment and partly information. I think it is hard to show “real hands-on” stuff without diving deep into it and losing half the audience while doing so. We need a balance for sure.

7) When writing CSS these days I get very annoyed about having to repeat a lot of code with different browser prefixes. Animations are the worst with all keyframes having to be repeated. Do you use any preprocessors like SASS or LESS? What do you think of that approach?

Yes, I was/am an early fan of Sass. I have been using it for 2.5 years (a lot less now as I do not deal with as much CSS as I would like to). I certainly think Sass/LESS would be the way to go forward for any web developer right now. They make CSS a lot more powerful and attempt to bring in programming paradigms that CSS sorely lacks. Attempts are being made by Tab Atkins at Google to bring these in a form of a proposal to the CSS WG, and hopefully we should see some form of support in the browser.

I would definitely recommend doing it on the server side though, doing JIT compiling of such code would be such a disaster for performance.
Especially today with so many vendor-prefixed extensions, not using such preprocessors would only cause more harm than not.

8) You work for Opera, the browser that did implement the most of the HTML5 form elements. Why do you think others are reluctant to do the same? Do you think HTML5 forms are ready for prime time yet?

It is certainly not true that others are reluctant. Chrome is pretty close to Opera in terms of support, and Firefox and IE10 are have various levels of support too. Yes, HTML5 forms need to be used with polyfills as of the moment, but I cannot wait for full support to land on all browsers so we can get beyond validating forms on the server.

9) I get a feeling that there is a general fatigue of semantic matters in the HTML5 world. Showcases have no HTML at all or meaningless elements like DIVs as buttons and so on. Is it just not sexy enough when we can rotate things in 3D and make sounds?

I am tired of semantics, too, really :) I think there is more to HTML5 than discussing when to use a section or a div or an article or an aside. Semantics are good to know about and learn to use, but we have had 15 years of talk about semantics surely we can go beyond that and learn about all the new stuff that occurs in HTML5 that will allow faster/more performant way to provide better experiences for your users.

10) If you have a friend who just wants to start with web development, what would you tell them to do and go to? What is the most efficient way to get people hit the ground running these days?

I would ask them to first hit the Opera Web Curriculum which has now moved to W3C – it is a wiki now so everyone is welcome to contribute to keep it up-to-date and relevant. Then I would highly recommend they refer to explanations and tutorials at the Mozilla Developer Center!

Photo by Chris Casciano

Do you know anyone I should interview for “People of HTML5″? Tell me on Twitter: @codepo8

As we’ve hoped, there has been a lot of interest in the newly announced WebAPI effort. So I figured that I should explain in more detail some of my thinking around what we’re hoping to do and the challenges that are ahead of us.

Goal

The goal of this effort is to create APIs to expand what the Web can do. We don’t want people to end up choosing to develop for a proprietary platform just because the Web is lacking some capability.

The main effort, at least initially, is to enable access to hardware connected to the device, and data which is stored or available to the device. As for hardware, we want to make the full range of hardware that people use available to the web platform. From common hardware like cameras, to more rarely used (but no less awesome) hardware like USB-driven Nerf cannons. We also want to enable communication hardware like Bluetooth and NFC.

For data stored on the device, the most commonly discussed data today is contacts and calendar. This includes the ability to both read and write data. That is, we both want the Web platform to be able to enumerate contacts stored on the device, and read their details, as well as add and remove contacts. In short, we want it to be possible to create a Web page or Web app which lets the user manage his contact list. Same thing for calendar events and other types of data stored on devices.

Security and Privacy

One big reason these types of APIs haven’t been developed for the Web platform yet is because of their security and privacy implications. I would obviously not want every single Web page out there to be able to mess around with my contact list or my calendar. And being able to issue any commands to any USB device that I happen to have plugged in would likely result in everyone’s computer immediately being zombified.

So as we are developing these APIs, we always have to develop a security model to go along with them. In some cases simply asking the user, which is how we currently do Geolocation, might work. In others, where security implications are scarier or where describing the risk to the user is harder, we’ll have to come up with better solutions.

I really want to emphasize that we don’t yet know what the security story is going to be, but that we’re absolutely planning on having a solid security solution before we ship an API to millions of users.

Robert O’Callahan has a really great post about permissions for Web applications.

Standards

Mozilla has always had a strong commitment to Web standards. This is of course not something we’re changing! All of the APIs that we are developing will be developed with the goal of being standardized and implemented across both browsers and devices.

But it’s important to ensure that standards are good standards. This takes experimenting. Especially in areas which are as new to the Web, and as security sensitive, as these are.

Standards organizations aren’t a good place to do research. This is why we want to experiment and do research outside the standards organizations first. But always in the open, and always listening to feedback. We’re also going to clearly prefix any APIs as to indicate that they are experiments and might change once they get standardized.

Once we have a better understanding of what we think makes a good API we will create a proposal and bring to working groups like the Device API group at W3C, WAC and WHATWG.

Throughout this process we will of course be in contact with other interested parties, such as other browser vendors and web developers. This is part of the normal research and making sure that an API is a good API.

Mozilla always has and always will be a good steward of the open Web. We are not interested in creating a Mozilla-specific Web platform. We are interested in moving the open Web platform forward.

High Level vs. Low Level

One thing that often comes up with API design is whether we should do high level or low level APIs. For example, do we provide a low-level USB API, or a high-level API for cameras?

There are pros and cons with both. High level means that we can create more developer-friendly APIs. We can also provide a better security model since we can ensure that the page won’t issue any unexpected USB commands, and we can ensure that no privacy-sensitive access is made without user approval. But high level also means that developers can’t access a type of device until we’ve added support for it. So until we’ve added an API for Nerf cannons, there will be no way to talk to them.

Exposing a low-level USB API on the other hand, means that web pages can talk to any USB device in existence, with no need for us to add an explicit API for them. However it also requires developers to get their hands dirty with the details of the USB protocol and differences between devices.

The approach we’re planning on taking is to do both high-level and low-level APIs, as well as give people the proper incentives to use the one that is best for the user. But a very important point is to provide low-level APIs early to ensure that Mozilla isn’t on the critical path for innovation. Over time, we can add high-level APIs where that makes sense.

How you can join

As with all things Mozilla, we’re planning on doing all our work in the open. In fact, we’ll be relying on your help to make this successful! As to keep discussions focused, we’re going to use the a new mozilla.dev.webapi discussion forum for all communication. This means that you can participate through email, newsgroups, or the web-based google group UI.

You can subscribe to the mailing list at https://lists.mozilla.org/listinfo/dev-webapi

For other methods go to: http://www.mozilla.org/about/forums/#dev-webapi

We also use the #webapi IRC channel on irc.mozilla.org.

We’ll also be tracking progress on the wiki page https://wiki.mozilla.org/WebAPI

Looking forward to hearing from you to help build the next stage for the web platform!

Hiring developers

Edit: Forgot to mention, we are hiring several full time engineers for working on the WebAPI team! Read the job description and apply.

Adobe made quite some splash in the last days by releasing Edge, a Flash-like tool to create HTML5/CSS3/JS driven animations. There is a need for a tool like that and I for one am very happy to see that Adobe are recognising this. Other tools that try to tackle the same task are already around, with the yet to be released Animatable being shown at quite a few conferences and Radi leading the way.

I am even happier that this sparked quite a conversation amongst the developer community – there are far too many truisms thrown around about HTML5 and CSS3, so anything that makes us re-evaluate the current state is a great idea.

Edge, according to Adobe themselves has been downloaded 50,000 times in the first 24 hours and looks much like Flash used to a long time ago:

The initial feedback was very polarised, whereas fans of Adobe products heralded this as a new dawn of standards-based animations, others were less impressed as the UK based .net magazine reports. This is to be expected, as everything with the HTML5 stamp these days gets that kind of treatment.

So what is going on under the hood of Edge?

Anna Debenham was one of the first to have a go at reviewing Edge and having a play with it:

As you can see in the frame above, the animations generated with it are fixed in size (either pixels or ems) and all consist of a mix of JavaScript and CSS3 transitions. The engine behind the animations is jQuery. Looking it up in Firebug, we are faced with a lot of DIV elements with positioning and CSS transition information:

This is in stark contrast to tools that try to turn Flash into open technology solutions like the conversions done by Google’s Swiffy. Swiffy uses SVG to simulate the path-based nature of Flash; Edge doesn’t and relies on DOM animation of DIV elements instead.

A total lack of HTML5 in the output

This caused the main confusion amongst developers and sparked a longer discussion on the Adobe forums initiated by Rob Hawkes. The original problem Rob found with Edge is that it doesn’t use HTML5 technologies like Canvas or other W3C animation and painting technologies like SVG:

Why has Edge gone with div-based animation over other technologies like canvas and SVG? I was deeply saddened to see that not only were divs used in the example files that you released, but that divs are the default option for the stage and any other element that is added to it.

Adobe’s answer was that animating DOM elements simply is faster and allows for more browser compatibility, especially on mobiles:

We seriously considered Canvas, but current performance on mobile browsers (especially iOS) is very bad. We didn’t want to have the first experience produce content that couldn’t run acceptably. Note that this may be changing in iOS 5, so that’s good. Finally, SVG can be a little slow, though we do support bringing in SVG elements and animating them – just not reach into them.

The performance argument is something that keeps cropping up in discussions. A lot of the animations by Google also moved DIV elements around rather than using Canvas and/or SVG (remember the exploding balls logo?) whilst sporting the HTML5 label.

HTML5 Games developer and co-organiser of the onGameStart conference Kamil Trebunia, questioned the concerns over Canvas being too slow on mobile devices. The great news is that in a backchannel discussion on Twitter, Paul Bakaus, CTO of Zynga Germany pointed out that they are doing intensive research into the subject at the moment and that they are happy to share the outcome at a later stage. So this is something very cool to look forward to and something to complement the HTML5 games performance research by Facebook a few months ago.

Lack of semantics in the output

The other issue with Edge that puzzled developers is the HTML that gets generated. As Morena Fiore asked with her Edge demo it seems weird that Adobe doesn’t use SVG and Canvas for animating when the output of the tool doesn’t feature any semantic HTML whatsoever:

The text content, the tweens and positioning and all the other information of the animation is in JSON objects instead:

Adobe’s original answer to these concerns was that they don’t want to touch the original HTML as developers don’t like that:

Our approach is that we separate out the stuff you add from the underlying HTML *AND* we don’t try to edit the HTML in the way old-style tools did – in general a lot of people don’t like when tools muck with HTML.

That said, we will be looking at ways of trimming down the HTML that gets added to a page in the future if that’s what people want.

That sounds like a slippery slope to me. As Tobias Leingruber showed in his firmly tongue-in-cheek demo done with Edge a lack of semantics and enhancing existing markup just means that we now create Flash tunnel pages in a different technology and makes you wonder if the main use case of Edge would be interactive ads that are not blocked by Flashblockers.

This is a challenge that any tool faces: how do I not only allow people to create but also make them aware that web content is not only pretty moving pictures? The Madmaninmation demo of animatable is a great example — it is a pure animation but when you check the source code it falls back to a list with the script of the animation. This allows everybody to know what is going on and helps your product to be understood by search engines. Will every user of animatable go through that level of support for the web or simply create animations?

With Edge, Adobe has a chance to do a very cool thing for open web technologies. It will be interesting to see where it goes.

As Bruce Lawson of Opera put it:

Designers will require authoring tools that can help them turn their creativity into code, and Adobe have a great track record on making IDEs that designers find user-friendly.

So the ball is in Adobe’s court to do the right thing for the web and move Edge further along (with help from the research the discussion sparked). And they are well on the way and declared that they are actively looking for feedback:

Edge will be evolving rapidly – the product is by no means feature complete. We expect to add support for more and more of the HTML universe over time. Edge does currently support SVG graphics (you can File > Import an SVG image), but you can’t yet reach into those graphics and animate their components. The good news is that our JS runtime is capable of animations that include all sorts of HTML Elements, SVG Elements and even Canvas graphics, so we have not boxed ourselves in.

Which of these enhancements would you like to see Edge tackle first? Canvas? Embedded SVG? Ability to select HTML tags other than DIV?

I, for one am excited to see Adobe start to wave the flag of open web technologies higher than before. Their new The Expressive Web showcase site is a proof of that. It is up to us now to cry foul at what they do or work side by side to bring the best experiences to the web for our users out there.

Today we release Aurora Update 8. We’ve got even more HTML5 support, support for cross-origin textures in WebGL, support for insertAdjacentHTML() and reduced resource requirements for media elements.

Cross-origin WebGL textures

We disabled support for cross-origin textures in Firefox 5 due to security concerns. You can now use cross-origin textures in Aurora Update 8, although servers that serve the images need to use CORS headers to be sent with them.

insertAdjacentHTML()

This is a method first implemented in Internet Explorer 4 and was added to the
HTML5 standard. This function allows you to insert HTML strings inside a document, just like the innerHTML property, but is more flexible and is much faster.

We expect that JavaScript libraries will quickly adopt this because it’s faster and vastly simplifies DOM manipulation code.

Reduced memory usage

Media elements (<audio> and <video>) now use fewer threads and less memory. This is part of our efforts to reduce overall memory consumption of Firefox and it is a welcome improvement as websites switch to using native media elements.

Other changes

HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.

Today we are featuring John Allsopp, author of Developing with Web Standards and organiser of the Webdirections conferences.

As you will see in the video, John is neither mincing his words nor does he hold back in spreading good messages about the web as a whole and independent of technology. He has been around since connecting to the web meant enduring bleeping noises and has spent quite some time building software and online generators to allow people to build for the web.

He has been very outspoken about the lack of semantic improvement in HTML5 and you can count on him to speak up every time somebody claims that native apps on mobiles will always be better than web standards based apps.

The video interview

You can see the video on any HTML5 enabled device here (courtesy of vid.ly).

10 Questions for John Allsopp

1) You’ve been around this internet thing quite a while and seen a lot of things come and go. What makes you believe in HTML5?

Well, interestingly I’m probably known by some people for being the anti-HTML5 guy. I’ve been quite critical in particular of the semantics in HTML5, both about some of the specific decisions made, but more importantly the approach to extending semantics in HTML5.

My particular interest in HTML5 in the broadest sense (so, including CSS3, related extensions to the DOM, geolocation, DAP etc) is seeing the web become an increasingly powerful application platform.

Over the last 20 years or so, we’ve seen the web revolutionise publishing, journalism, and other essentially text based media. This emerging generation of technologies promise to revolutionise much more.

2) What are the things in HTML5 that still need tweaking in your book? Anything that ails you about the current state of the spec?

Well, I still think the ball has been dropped when it comes to increasing the semantic richness and expressibility of the language in any genuinely useful way. And I sadly don’t really see anything happening there.

I also think HTML needs to take a leaf from the CSS book – CSS2, a monolithic specification became increasingly bogged down in minutiae, and the failure to finalise it became a kind of running joke.
With CSS3, we saw the modularisation of the specification, with much more rapid innovation, much more experimentation. In truth, it was the experimental CSS3 features that I think ignited the excitement around what we call HTML5, far more than a new DOCTYPE and things like the header element.

The core of the HTML5 specification is really monolithic, and is suffering much the same way CSS2 did. We’re even seeing the same sort of glib jokes about how it’s going to be finished in 2020, which impacts on whether many developers will adopt something perceived (mistakenly, though somewhat understandably) as unready for commercial use. Some aspects of the initial monolithic HTML5 spec have been modularised, while related technologies like geolocation, which is widely considered to be part of HTML5 have always been their own small, independent activities.

So, if anything, I’d like to se the increasing modularisation of the HTML5 spec.

3) You seem to spend quite some time building code generators at the moment. The CSS gradient generator and the audio embed generator being just two of them. Do people use them a lot? And why the separation between Firefox and Webkit rather than generating both?

Just to clarify, all my new tools (audio, video, and some others in the pipeline), as well as the upgrades to existing ones (linear and radial gradients) are cross browser – they work in all browsers that support the technology they’re focussed on, and create code for all modern browsers (in some cases where they don’t even yet support the particular functionality – for example Opera and radial gradients).

In the past (and some of these are 2-3 years old now), I decided to focus only on those browsers which supported a particular technology. I had separate Firefox and Webkit versions of the gradient tools because they supported quite radically different models of gradients, which made a single interface to producing two separate versions of a gradient confusing, as well as essentially impossible.

It’s important to note that the primary motivation for these tools is to help people learn the concepts and syntax for these various features. I think many CSS3 features in particular are really quite complex, and learning them in the more traditional text oriented way is becoming increasingly difficult. For example, you can generate a radial or linear gradient with my tools for all modern browsers in a few seconds, even if you have no idea about how CSS gradients work. But the two articles I wrote on gradients in total come to nearly 10,000 words, and a couple of dozen or more illustrations.

Do many people use them? – they certainly generate quite a bit of traffic. They’re definitely popular – and I think as importantly, people really appreciate them – even really well known CSS experts let me know they really appreciate having them there, and I know others are using them to actually test browser implementations. So I think they are well worth doing.

The last thing I’ll say on them is I also build them to let *me* learn – I’ve been developing tools for web developers for 15 years, all the way back to the earliest days of CSS, and I find the best way to know a technology (and its and your limitations) is to build a tool to work with it.

4) You are also a conference organiser and run workshops. What are the current hot topics in those related to new, open web technology and are there things you’d like to cover more that are not yet requested?

New CSS3 features definitely get a lot of interest – animations, shiny effects like gradients and so on. And we’re definitely seeing a lot more interest across the board in the app development related technologies – offline webapps, geolocation, JavaScript more broadly. Im a sense I think a lot of more traditional web design is “done”. There are widely accepted and understood markup practices, patterns and techniques. There are page architecture patterns that we increasingly build page and site designs out of. But the area of web application development is really uncharted territory by comparison.

5) A sure-fire way to tick you off and get you to blog seems to be to say that native experiences on devices will always be better than using open web technology. If you look at it straight from an end user perspective, this seems to be the case though – things look smoother in native apps. How can we make standards-based development more interesting for developers when the lure of native apps with a money-making store is that big? How can we break the notion of open tech apps being of lesser quality?

There’s a lot going on with this question, so let me begin by stating my basic case. I call BS on the argument that native apps are intrinsically better looking, have better UX, and so on, simply because they are built with say objective-c (when people say native, they almost invariably mean apps for iOS they *think* are built with cocoa touch).

Your observation that many “native” apps are slicker, etc than web apps is a fair one. I think that it *is* somewhat easier to create a cookie cutter native app for say iOS using CocoaTouch, and the really excellent tools Apple has been working on since the NeXT days. But it’s also important to note that for many categories of applications, for example games, these apps use technologies like Unity3D, so in a sense many of the most successful, most engaging applications people use on say iOS aren’t native. I think it really comes down to the tools – and for developing apps using web technologies, these are far less sophisticated on the whole than those like Apple’s. Which to me presents an opportunity.

As to the lure of big money – it’s again one of those myths that get repeated ad nauseam. In fact it started even before there were any apps in Apple App Store! Now we’ve seen several years of activity, what have wen learned? There are doubtless a small number of big winners – but all indications are that almost no one makes any more selling apps on app stores.

There’s a whole industry in app discovery, so the supposed bon to developers that the App Store was going to provide in allowing the little guys to get their apps discovered by users really isn’t panning out.

As soon as you start looking at any sort of numbers objectively, it’s hard to see business case for building a native iOS app and selling it on Apple’s App Store, compared with simply taking that money to Las Vegas for the weekend. You’re going to waste far less of your life.

Finally, the single best way we can address the challenge web technology based apps have of being perceived of inferior quality is to continue building apps that are of superior quality. There are plenty out there – and often you don’t know it, because they are packaged up as native apps.

6) I am worried about showcases these days. The latest “Chrome experiment” (the collaboration interactive video with OK Go) didn’t even work on my Macbook Air with Chrome and let my fan do the impression of an aircraft taking off (it also, ironically, doesn’t work on my Chromebook). There seems to be a – to me – dangerous move towards experimental web sites expecting certain browsers and even hardware. Are we facing a new “best viewed with IE6 and 1024×786 resolution”?

I understand the concern, but don’t think we’re seeing, or will see a return to those bad old days. The “best viewed in” was seen on many many production sites back in the day. Experiments are just that – something at the bleeding edge, pushing the technology to the edges of its capability. So, I love seeing these experiments. We’ve been involved in some ourselves. We typically kick off our conferences with an opening title sequence (we started this a long time ago, but we’re seeing loads of folks doing it now). In the last year or so, we’ve been commissioning people to create these sequences using web technologies – and we’ve got no trouble with them targeting even a really, really specific setup – after all, it’s being designed for a very specific circumstance.

I honestly don’t think we’ll head back to the best viewed in days. Developers and browser makers have learned the lesson of just how bad that is for everyone.

7) Whilst there is a lot of uptake on cool CSS3 transitions, animations, 3D transformations, WebGL and video it seems to me that the semantics of HTML5 and the forms get a bit forgotten. Even more so, it seems like a scam to tell people that there is a need for sections, articles and time elements when no browser uses them to create an outline or syndicates them. Do you see that changing? How can we make it more real for people? Haven’t we used the “use this and that markup as it is the right thing to do” argument too often?

I tend to think the use of various new HTML5 elements as something of a cargo cult. I don’t really see any practical benefit, and there’s still legacy browser challenges (IE6 and 7) to deal with there. And I doubt there’s ever really going to be particular benefits – there’s ultimately very little additional information we’re providing by saying “this is a section”, “this is navigation”, and so on. If the semantics were richer, there would potentially be much more browser developers, search engine developers and so on could do with the richer markup, but as I’ve mentioned, I think we’ve got what we’ve got.

As for forms, now, there’s a lot more going on here of practical use today, and into the future. We can use new elements like number, email and url, and attributes like required right now (I’m doing it myself), as these fallback nicely in older browsers.

In fact, it’s one of my next big areas of focus after I finish a little project involving animations! HTML5 forms stuff is awesome!

8) Let’s talk accessibility a bit. I get the feeling that right now the accessibility world is falling immensely behind. Whilst HTML5 and jQuery tells people to “write less and achieve more” it seems that ARIA roles are ridiculously verbose and rather tough to add. A lot of the needs of mobile and touch interfaces overlap with the needs of disabilities. However, it seems to me there is not enough interest in the a11y world for new technology as it is not proven. Do you find it hard to connect the two?

I’m very far from an accessibility expert, so there’s probably not a a great deal I can add to this particular area of any real value.

ARIA roles are how I’d actually go about enriching the semantics of HTML5, rather than adding a small number of new elements as is the current state of play.
There’s two aspects to ARIA roles. First is the role attribute, initially introduced in XHTML as a means for adding additional semantic information about an element – the role that element is playing. For example, we have a common markup pattern of a div element, playing the role of the page header. We can mark this up with the role attribute like so <div role=”header”>

role is actually quite separate to ARIA. What ARIA brings to the role attribute is a vocabulary, a number of possible values for role, that we can use to add further semantic information to our pages. But you aren’t restricted to ARIAs vocabulary, and indeed can define your own. ARIAs vocabulary is actually far more extensive than HTML5′s.

I think the markup pattern, of using an attribute with a value to give additional information about an element, is really well known and widely used by developers – who doesn’t use class more or less like this?

So, I don’t see the use of role as a particular challenge for developers to adopt.
Then, role has the advantage that you can style it in every browser from IE7 up, using CSS with no JavaScript as well. For HTML5 elements, we need JavaScript for IE7 as well as IE6.

It has to be noted that he ARIA vocabulary is a generic one for rich internet applications, not specifically designed for apps developed using HTML. And sadly the ARIA vocabulary, and HTML5 semantics don’t map onto each other well.

I guess the biggest challenge for web accessibility into the future is that while making essentially text based and static content accessible is not overly challenging, and is now well understood, making applications, dynamic media, and rich interactive content accessible is a far more significant challenge.

9) To me it is high time we stop doing showcases and demos and instead start documenting what people can do themselves and build real products with open web technologies.

I love the showcases, the demos, the proofs of concept, but I agree, I also think it is time to really draw attention to the real world examples. I guess with my articles and tools, what I’m trying to do is help developers adopt these technologies today. As are many other folk as well.

9) (ctd) Sadly, when it comes to conferences though a lot of the things shown on stage were written as a demo for the talk. Are there any exceptions you found? I remember some @media had a great talk on how Blogger saved money by moving to CSS for layout. We need more hard evidence talks like that. Do you actively try to find real life showcases?

Absolutely – one of our goals is to have people who walk the walk. We actively look for folks who go beyond the opinions, and can speak with experience about projects, showcase successes, talk about the challenges they face, and the solutions to those.

10) What’s the next big challenge? Where would you like the web to go and what are the next things that browser makers should agree on?

Those of us old enough will remember when suddenly everything had an LED then LCD screen – things that were once analog, with mechanical dials and the like, things like microwave ovens, suddenly had displays, for time, temperature settings, and so on.

I think far sooner than we realise, there’ll be high resolution touchscreens everywhere, on almost every device.

Not all these devices will necessarily be connected to the web, but many of them will be. But their UIs will be essentially browser technology.
So, there’s going to be huge opportunity to develop user experiences for all kinds of devices using HTML, CSS, JavaScript and related web technologies.

Another really significant trend we’ve seen faltering steps toward, but which I think will genuinely be a paradigmatic change in technology use is “boot to web”.

Think back 3 or 4 years. The hardware, chip, motherboard, RAM speed of your laptop was a big deal. People really cared. They bragged about this stuff! Apple went through 2 incredibly complex expensive CPU architecture changes over about 12 years because of it. Now virtually no one cares. Hardware doesn’t matter any more. It’s been commodified.
The next layer to be commodified will be the OS. It may seem unimaginable now with iOS so dominant in the mobile, not to mention tablet space, but to me this is a very transitional period. The web will commodify operating systems. ChromeOS is a commercial example of this. Boot to Gecko, something Mozilla IMO should have been working on a long time ago is a more experimental example.

The technologies we currently call HTML5 will be the building blocks of the applications which run on these devices.

The as yet missing piece of this puzzle is the emerging Devices API standard, which exposes hardware and system APIs like the camera, address book, calendar, messaging services (for example SMS) to the browser. We’re already seeing support for aspects of this, such as the camera in Android 3 devices. I’m sure this is a big part of the “Boot to Gecko” project too.

Photo by Sam Whiteman / TEDxNSW

Do you know anyone I should interview for “People of HTML5″? Tell me on Twitter: @codepo8

Animating DOM elements[1] or the content of a canvas is a classical use case for setInterval. But the interval is not as reliable as it seems, and a more suitable API is now available…

Animating with setInterval

To animate an element moving 400 pixels on the right with javascript, the basic thing to do is to move it 10 pixels at a time on a regular interval.

An HTML5 game based on this logic would normally run at ~60fps[2], but if the animations were too complex or running on a low-spec. device (a mobile phone for instance) and processing a frame were taking more than 16ms, then the game would run at a lower framerate: when processing 1 frame takes 33ms, the game runs at 30fps and game elements move twice as slowly as they should. Animations would still look smooth enough, but the game experience would be altered.

Animating at constant speed

To animate at constant speed, we need to calculate the time delta since the last frame and move the element proportionally.

Animating with requestAnimationFrame

Since the interval parameter is irrelevant in complex animations, as there’s no guarantee that it will be honored, a new API has been designed: requestAnimationFrame. It’s simply a way to tell the browser “before drawing the next frame on the screen, execute this game logic/animation processing”. The browser is in charge of choosing the best moment to execute the code, which results in a more efficient use of resources[3].

Here’s how an animation with requestAnimationFrame would be written.
Note: Following code snippets don’t include feature detections and workarounds necessary to work in current browsers. Should you want to play with them, you should try the ready-to-use animLoop.js.

Dealing with inactive tabs

requestAnimationFrame was built with another benefit in mind: letting the browser choose the best frame interval allows to have a long interval in inactive tabs. Users could play a CPU intensive game, then open a new tab or minimize the window, and the game would pause[4], leaving resources available for other tasks.
Note: the potential impact of such behavior on resource and battery usage is so positive that browser vendors decided to adopt it for setTimeout and setInterval as well[5].

This behavior also means that the calculated time delta might be really high when switching back to a tab containing an animation. This will result in animation appearing to jump or creating “wormholes“[6], as illustrated here:

Wormholes can be fixed by clamping the time delta to a maximum value, or not rendering a frame when the time delta is too high.

Problems with animation queues

Libraries such as jQuery queue animations on elements to execute them one after the other. This queue is generally only used for animations that are purposefully consecutive.
But if animations are triggered by a timer, the queue might grow without bound in inactive tabs, as paused animations stack up in the queue. When switching back to affected tabs, a user will see a large number of animations playing consecutively when only one should happen on a regular interval.

This problem is visible in some auto-playing slideshows such as mb.gallery. To work around it, developers can empty animation queues before triggering new animations[7].

Conclusion

The delays of setTimeout and setInterval and of course requestAnimationFrame are unpredictable and much longer in inactive tabs. These facts should be taken into account not only when writing animation logic, but in fps counters, time countdowns, and everywhere time measurement is crucial.

[1] The DOM can now be animated with CSS3 Transitions and CSS3 Animations.
[2] 1 frame every 16ms is 62.5 frames per second.
[3] See the illustration of this fact on msdn.
[4] The behavior of requestAnimationFrame in inactive tabs is still being worked on at the w3c, and might differ in other browsers.
[5] See related Firefox bug and related chromium bug.
[6] This term was first coined by Seth Ladd in his “Intro to HTML5 Game Development” talk.
[7] See documentation of your js library, such as effects and stop() for jQuery.