1. Browserscene: Creating Demos on the Web – Presentation at ASSEMBLY

    Last Friday I got to attend and speak at the ASSEMBLY event in Finland. The atmosphere was amazing, just check out this photo:

    ASSEMBLY 2011

    Here is how the organisers describe the event:

    ASSEMBLY is a four day computer festival, in which thousands of people and their computers spend the long weekend by meeting friends, playing games, surfing on the net, talking on IRC and enjoying the great productions from the demoscene. The idea is to be there with or without your computer and enjoy the great atmosphere of being with like-minded people. ASSEMBLY is for anyone who enjoys doing just a bit more with their computer: be it tweaking your hardware, making web pages, playing games, spending hours on IRC, making great graphics or music with your computer or programming complex routines. ASSEMBLY is where you meet the most interesting people, have the greatest game matches, and see the most amazing demoscene works of art. ASSEMBLY is where you need to be.

    Sounds great, right? It’s probably one of my new favourite places in the world.

    Creating demos on the Web

    My talk at ASSEMBLY was all about the browserscene, which is my way of referring to the demoscene on the Web. In the talk I covered all the latest technologies that are out there within browsers that allow you to create amazing games and demos, all with nothing but HTML, CSS, and JavaScript.

    Slides

    Video

    Further resources

    I mention a lot of resources throughout the talk. I’ve listed all the major ones on my blog and have provided links to them all.

  2. Ask MDN follow-up: HTML5 Gaming & Creative JavaScript

    Just over a week ago we gathered 8 experts in the field to answer your questions about HTML5 gaming and creative JavaScript. This was our first Ask MDN event and, although it had a couple of teething problems, it went really well.

    In this post I want to follow up on the previous event and outline our plans for the future, taking into consideration all the lessons that we’ve learnt so far.

    Thanking the developer community

    Without you the first Ask MDN would have been completely pointless, so I’d like to thank those who submitted questions and took part in the discussion. You keep our experts on their toes and sparked some great conversations on Twitter.

    We were actually a little overwhelmed with the amount of questions coming in, so we’re sorry for not answering them all. It’s one of the things we want to improve on, which you can see in the section further on on this post.

    Thanking the experts

    Our intrepid group of experts did a fantastic job at answering the questions as they came in. I’d particulary like to thank them for their patience as we dealt with changes in procedure during the event.

    Find out more about our experts:

    Learning from our mistakes

    We learnt a lot from the first event, so much so that we’re taking steps to make sure we don’t repeat the same mistakes. Here are just a few of them.

    Tweaking the format

    Originally we wanted Ask MDN to be a weekly event, and we still do, but we’ve decided to move to a bi-weekly format for the near-future. This will allow us more time to work on the other issues we encountered, with the ultimate aim of making the event even more awesome.

    We’ll move to a weekly format once we’ve got everything working how we’d like. It shouldn’t be too long.

    Archiving the event

    We’re going to start archiving each event ourselves, but in the meantime you can check out this great transcript from Andrzej Mazur. Thank you!

    Tracking the live conversation

    Related to the archival of the event is tracking the conversation on Twitter as it happens live. We noticed that a lot of people were finding it hard to know which questions were being answered, particularly as there were often more than one question being answered at a time.

    We plan to make the conversation on Twitter easy to follow with a dedicated Ask MDN dashboard website. This will aggregate all the information you need to know about the conversation; like the current questions and their hashtags, answers to each question displayed in a threaded format, the ability to submit questions directly, and more!

    Cutting redtape

    Originally we thought that a solid procedure for answering questions would be best. This was wrong and it meant that more time was being spent delegating questions to experts and waiting around than actually answering questions.

    In the future we plan to relax the procedure and allow the experts to answer any question they want at any time within the hour.

    Dealing with unanswered questions

    Something we hadn’t thought about was what to do with all the questions that didn’t get answered during the hour. In the future we will be posting these all online, probably on the dashboard, for experts and the community to answer at a later date.

    Have feedback?

    We’re doing this for you, so please let us know if you have any feedback about how Ask MDN could be better. Leave a comment below and we’ll consider them all as we evolve the event in the future.

    Next up: The History API

    This Friday we’re convering the History API, which is also the focus of this month’s Dev Derby.

    We’re now open for questions, so send them to us now on Twitter or use the the #askmdn hashtag.

    This event will occur at the following times around the world:

    • 10am in San Francisco (PDT)
    • 1pm in New York (EDT)
    • 7pm in Paris, Berlin and Madrid (CEST)

    Find the time where you live to make sure you don’t miss out.

  3. Rendering 3D with CSS and JavaScript with dom3d (guest post)

    James Long Today we have a guest post by James Long (@jlongster).

    James is the tech lead for mozilla.com on the Web Development team. James is passionate about interactive graphics on the open web.

    Today he explains how you can create 3D objects using CSS without having 3D transforms support. Take it away, James.


    Recently I was tinkering with CSS3 and I discovered that it enabled me to do primitive 3D rendering, which I found fascinating! This led to the creation of dom3d, a JavaScript library that uses CSS to render basic 3D objects.

    Now the question is: why? Aren’t canvas, WebGL, and even SVG better technologies to work with for this? Possibly. However, CSS is becoming a powerful language for describing complex effects and shapes, and we should experiment.

    Keep that in mind, because CSS definitely isn’t intended to do this, but it’s worth trying to see where we should take CSS in the future.

    Advantages

    Although this is more of an experiment, it has a few real world benefits:

    All rendering libraries available for the web (canvas, WebGL, SVG) require a canvas, which is a constrained box on the page with a specific width and height. It is not possible to render anything outside this box. The canvas also captures all DOM events (like clicks), even completely transparent sections. Theoretically, this could make it difficult to do effects that overlay large parts of the page or are somehow deeply integrated to the content.

    Using CSS, we aren’t constrained to a box, and the effect can overlay large portions of the page without covering any the the links or other content requiring interaction.

    Other advantages include no need to initialize canvas 2D or WebGL, and a simplistic API making it easy to pick up even if you don’t know much about 3D. It might be easier for kids to start playing around with this before they jump into WebGL or something else. Also, because it’s just a dump of DOM elements you can embed it anywhere (without animation).

    So keep in mind that this is a hack, but with the above advantages. This might be good for certain effects: 3D cursor, nav transitions, and others.

    How it works

    Three-D objects are just a bunch of triangles put together, so let’s start with one simple triangle. If we get that working, it’s a simple step forward to render multiple triangles to form a 3D object.

    Rendering a 3d triangle on a 2D screen involves something called “projection”. This is the act of taking a 3D point and projecting it onto a 2D screen. Plug in a 3D triangle to a simple math equation, and you get a 2D triangle representing how the 3D one would look on the screen.

    The math is remarkably simple but may seem weird if you aren’t familiar with linear algebra. You can take a look at the renderer code.

    Now comes the fun part: can you render any 2D triangle simply with CSS3 transforms? Turns out you can! It just takes some fiddling to figure out which transforms to generate. CSS3 transforms are composed of translate, scale, rotate, and skew values, and we need a few equations to compute these values for a specific 2D triangle.

    First, let’s take a simple DOM element and turn it into a triangle. We can do this with the linear-gradient background image (another way is border triangles).

    Now let’s draw the following blue triangle with the points [20, 20], [50, 120], and [120, 30]. A vital step is to set a few initial reference points which set everything in the same space. Our equations will assume these coordinate spaces. This is how the points A, B, C and the side AB are related.

    Triangle comparison

    If we take a closer look at this, we can derive the transform values. First, get an idea of which angles and values we need and then use geometry to form the equations (in pseudo-code). The red box represents the DOM element, the form AB represents the side formed by points A and B, and rotation occurs clockwise.

    dissecting triangles

    rotation = atan2(AB.x, AB.y)
    AC' = rotate(AC, -rotation)
    width = AC'.x
    height = length(AB)
    skew = atan2(AC'.y, AC'.x)
    translate = A

    Awesome! Let’s try it out. Here is a live DOM element being transformed by applying each of our equations:

    The resulting triangle matches our target triangle! Here is the final CSS:

    width: 93px;
    height: 104px;
    background: -moz-linear-gradient(-0.727211rad, #0000FF 50%, transparent 0pt);
    -moz-transform: translate(20px, 20px) rotate(-0.291457rad) skewY(0.391125rad);
    -moz-transform-origin: top left;

    Note: The tranform-origin: top left line is important. Normally transforms happen relative to the center of the element, but our equations assume the top left.

    Note: dom3d also generates code with the -webkit and -o prefixes for WebKit and Opera support.

    You can view the implementation of these equations. It turns out that these equations work for any triangle, as long as the points given are in counter-clockwise order, which is standard in the graphics world.

    Taking it all the way

    Since we can project a 3D triangle into 2D space and render it with CSS, all we have to do now is apply that to several 3D triangles to form a 3D object!

    We need some 3D data at this point. I used Blender to export a teapot into the simple OBJ file format and wrote a script to dump the data as JavaScript. Rendering all those triangles with this technique produces the following:

    Teapot! However, we can do much better. A big part of the 3D effect is shading. If we calculate normals, a vector representing where the triangle is facing, and specify a light direction, we can take the dot product of the normal and light for each triangle to get flat shading. View the code for flat shading.

    There are many tweaks that take this even further. For example, the above objects have z-indexing enabled. Without this, a triangle that is supposed to be behind another may actually appear on top because it was rendered later. The dom3d uses a heap to render the triangles from back to front.

    Real-time animation can be achieved with a setTimeout or requestAnimationFrame function that continually renders the object. The dom3d supports the scale, translate, yaw, and pitch transformations, but there’s nothing stopping you from modifying the object data however you like between renderings. See some examples over at the dom3d website.

    Here is the code which renders the teapot animation with dom3d:

    It’s more appropriate for webpages to update an animation in response to user interaction instead of constantly rendering and hogging the CPU. See the pole example on the dom3d site for an example.

    Improvements and last thoughts

    The most interesting possibility with this is to include actual page elements as part of 3D objects. A navigation item could pop out and swirl around in 3d space, and the nav item is seamlessly transformed along with it.

    That’s where this hack starts to show its faults, though. Unfortunately this is a little too hacky to provide an appropriate web experience. Because it tricks DIVs into fake triangles, it removes the possibility of integrating any page elements with it. With the coming of 3D CSS transforms though, we can start building true 3D objects made up of any kind of page elements. The only restriction with 3D transforms is that the 3D objects need to built with rectangles instead of triangles.

    Other people have already experimented with 3D transforms, like building a pure CSS 3D city. There’s another cool library, Sprite3D, which provides a JavaScript API for building basic 3d objects from page elements.

    The most glaring problem with dom3d is the seams in the object, which appear in all browsers. Apparently there are a few bugs in rendering engines when stressing their CSS3 transforms and using linear-gradients!

    The dom3d library provides an API to work with all of this, but is hasn’t been documented very well yet. Feel free to browse the README and code on github. These APIs could be improved as well. It also provides an SVG rendering backend, seen here, but I don’t this is the right direction to take. We should focus on building basic 3D objects with page elements.

    This was a fun experiment and I’m excited by how fast and capable browsers are becoming. The web is an exciting platform and getting richer and more powerful every year!

  4. Wiki Wednesday: August 3, 2011

    (Yeah, it’s Thursday — sorry).

    Here are today’s Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki@mozilla.org.

    Contributors to Wiki Wednesday will get recognition in next week’s Wiki Wednesday announcement. Thanks in advance for your help!

    JavaScript

    SpiderMonkey

    Thanks to Mark Giffin for contributing since last time.

    Developing Mozilla

    Extensions

    Thanks to Marc-Aurèle Darche for his contribution.

    XUL

    Thanks to darktrojan for contributing!

    XPCOM

    Interfaces

    Thanks to Mark Finkle and Trevor Hobson for their contributions since last time.

    Plugins

    CSS

    Thanks to McGurk for contributing!

    SVG

    HTML

    DOM

  5. Animating with javascript: from setInterval to requestAnimationFrame

    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.

  6. Living on the Edge – new Adobe animation tool sparks necessary conversations

    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:

    Edge showing the wheel demo

    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.

  7. Making history with the August Dev Derby

    It is time to announce another month’s Dev Derby and this August we want you to play with the History API. The History API is a much needed piece of the puzzle of creating modern web applications and here is why:

    Links are good, they make the web work

    The web is made up from sites linking to each other. You are on some site and read an HTML document, you hit a link or submit a form and the browser redirects you to another page. This is great as it allows for a few things:

    • You always get a unique address you can bookmark and send to your friends to see the page you were on
    • You can use the browser’s back button when you did something wrong and get back to where you were before
    • Search engines love links and following them through your site

    Why load a whole page when only a small bit changes?

    Of course there are some annoyances with that, mainly that you need to leave the page and download a full new document and its linked resources every time to perform a simple action. As this took too long even in the dark past of the web we found workarounds like frames which only loaded part of the site rather than the whole document. This broke the bookmarking and going back in history bit for the first time. The other big thing of course was to make Flash sites bookmarkable and allow for using the back button in them (you might remember JavaScript confirm boxes popping up saying “do you really want to leave this page?”).

    When AJAX came around we totally killed the bookmarking and history of the browser. This was a problem as our visitors have already been conditioned to hit the back button every time something goes wrong (admit it, you also found yourself reloading or hitting back in GMail one time or another). We needed a fix for that. As far as I remember Mike Stenhouse was the first to propose a fix in 2005 using the fragment identifier of the URI to store information and a hidden iframe element to seed the history. This fix got wrapped into several libraries like the YUI history manager and the jQuery History plugin.

    Breaking the web with “hashbang URLs”

    The problem of broken links and browsing session histories escalated when some sites like Twitter and Gawker media discarded real URLs for hashbang URLs. So instead of reaching me at http://twitter.com/codepo8 clicking my profile in Twitter will get you to http://twitter.com/#!/codepo8. As Twitter is an app that uses a lot of JavaScript, it was deemed more efficient to use the latter to navigate – all Twitter does is load the new content of my profile via JavaScript. This saves them a lot of traffic, but also makes the links dependent on JavaScript which means search engines don’t follow them. In Twitter’s case this is not an issue but when Gawker moved all his blogs to a format using hashbangs rather than reloading the page, a simple JavaScript error in a different script caused a major outage on a lot of blogs. But Hashbang URLs became something people really wanted to have to create fast loading apps and pages instead of reloading the page over and over.

    Hashbang URLs are brittle to say the least and a lot of people voiced concerns about them. Not all user agents on the web have JavaScript enabled, which means your site can’t even be reached by them. This includes search engine spiders which is why Google set up a proposal how to make Ajax sites crawlable even throwing out a whole spec. As an aside, the Facebook vanity URLs also redirect with JavaScript, which is why mine is “document.location.href”.

    The solution: History API and server redirects

    So instead of using hashbangs and break the web and very basic browser usage patterns we now have the History API in HTML5. It allows you to dynamically change the URL in the browser toolbar and add to its history without reloading the page. You get the best of both worlds – you do atomic updates in the page and you leave real, working URLs behind for the user to go to, bookmark and send to friends. The History API is in use by quite a few major sites, Facebook allows for back button use and Flickr uses it in their lightbox view. The coolest implementation however is GitHub and their Tree Slider:

    Isn’t that slick? You navigate the whole page, it loads in milliseconds rather than seconds and you can hit the back button or copy and paste the URL any time you want.

    Now it is your turn, show us what you can do with the History API! Here are some resources to read up on.

    Resources:

    Ladies and gentlemen, start your editors and show us how to make History!