Mozilla

Articles by Chris Heilmann

Sort by:

View:

  1. New Features of Firefox Developer Tools: Episode 25

    Firefox 25 was just uplifted to the Aurora release channel which means we are back to report about new features in Firefox Developer Tools.

    Here’s a summary of some of the most exciting new features, and to get the whole picture you can check the complete list of resolved bugzilla tickets.

    Black box libraries in the Debugger

    In modern web development, we often rely on libraries like JQuery, Ember, or Angular, and 99% of the time we can safely assume that they “just work”. We don’t care about the internal implementation of these libraries: we treat them like a black box. However, a library’s abstraction leaks during debugging sessions when you are forced to step through its stack frames in order to reach your own code. To alleviate this problem, we introduced black boxing: a feature where you can tell the debugger to ignore the details of selected sources.

    To black box a source, you can either mark them one at a time by disabling the little eyeball next to it in the sources list:
    eyeball

    Or you can black box many sources at once by bringing up the developer toolbar with Shift+F2 and using the dbg blackbox command:

    dbg blackbox --glob *-min.js[source]

    When a source is black boxed:

    • Any breakpoints it may have are disabled.
    • When “pause on exceptions” is enabled, the debugger won’t pause when an exception is thrown in the black boxed source; instead it will wait until (and if) the stack unwinds to a frame in a source that isn’t black boxed.
    • The debugger will skip through black boxed sources when stepping.

    To see this in action and learn more about the details, check out the black boxing screencast on YouTube.

    Replay and edit requests in the Network Monitor

    You can now debug a network request by modifying headers before resending it. Right-click on an existing request and select the “resend” context menu item:

    resend request

    Now you can tweak the HTTP method, URL, headers, and request body before sending the request off again:

    tweak

    CSS Autocompletion in the inspector

    Writing CSS in the inspector is now much easier as we enabled autocompletion of CSS properties and values.

    autocomplete

    What’s more, it even works on inline style attributes

    inline

    Aside: this feature was implemented by contributors Girish Sharma and Mina Almasry. If you want to take your tools into your own hands too, check out our wiki page on how to get involved with developer tools.

    Execute JS in the current paused frame

    One request we’ve heard repeatedly is the ability to execute JS from the webconsole in the scope of the current paused frame in the debugger rather than the global scope. This is now possible. Using the webconsole to execute JS in the current frame can make it much easier to debug your apps.

    Edit: The webconsole has actually been executing in the current frame since Firefox 23, in Firefox 25 the scratchpad will execute in the current frame as well.

    Import and export profiled data in the Profiler

    Hacking on a shared project and think you found a performance regression in some bit of code owned by one of your friends? Don’t just file a github issue with steps to reproduce the slowness, export and attach a profile of the code that shows exactly how much slowness there is, and where it occurs. Your friend will thank you when he or she is trying to reproduce and debug the regression. Click the “import” button next to the start profiling button to load a profile from disk, and hit “save” on an existing profile to export it.

    profileimport

    When can I use these features?

    All of these features and more are available in the Aurora release channel. In another 12 weeks, these features will roll over into Firefox stable.

    Have some feedback about devtools? Ping @FirefoxDevTools on Twitter, or swing by #devtools on irc.mozilla.org.

  2. Firefox Marketplace and alternatives – Firefox OS for developers: the platform HTML5 deserves

    In the fourth video of our “Firefox OS – the platform HTML5 deserves” series (part one, part two and part three have already been published) we talk about how to submit apps to the Firefox Marketplace, and explain alternative ways to distribute your apps.

    Firefox OS - be the future

    Here are Mozilla’s principal developer evangelist Chris Heilmann (@codepo8) and Desigan Chinniah (@cyberdees) of the Firefox OS business development team showcasing how easy it is to get your app published on Firefox OS. You can watch the video on YouTube.

    Firefox OS – like any other mobile platform – has a marketplace that allows you to find apps by name or category.

    marketplace

    As a developer, to submit your app to the marketplace all you have to do to is to create a manifest file and host it on your server (make sure to give it the correct MIME type “application/x-web-app-manifest+json”). In the manifest you define name of your app, provide icons and ask for permission to access web activities and other functionality. You can validate your manifest online before going further to avoid erroneous submissions.

    Once you have your manifest in place, you can submit your app to the marketplace. There you provide screenshots or videos and a longer description of your app.

    If the app is hosted on your server, you get all the HTML5 functionality you expect to get. You don’t get access to the camera or the contact book though. To get this, you need to package your app and host it on the marketplace. You can get more information on the different levels of app privileges on the Wiki.

    As your apps are HTML5 apps you can also install them directly from the web without having to go through the marketplace. This also means that we don’t break the link-ability of the Web – you can send someone a link that will trigger the app install on a device that allows for the Open WebApps standards proposal (Firefox OS or Android with Firefox installed). This proposal is part of the WebAPI proposals and allows you to create a “install this app” button with a few lines of code:

    if (navigator.mozApps) {
      function install() {
        var installapp = navigator.mozApps.install(manifestURL);
        installapp.onsuccess = function(data) {
          // App is installed
        };
        installapp.onerror = function() {          
          // Something went wrong,
          // information is in: installapp.error.name         
        };         	
      }
      var button = document.createElement('button');
      button.innerHTML = 'Install this app';
      button.addEventListener('click', install, false);
      document.body.appendChild('button');
    }

    This allows you to re-use all the effort you put into promoting your existing web presence to become the advertisement for your app.

  3. Getting started with apps – Firefox OS for developers: the platform HTML5 deserves

    In the third instance of our “Firefox OS – the platform HTML5 deserves” video series (part one and part two have already been published here) we talk about tools available for building apps for Firefox OS.

    Firefox OS - be the future

    Check the short video featuring Chris Heilmann (@codepo8) from Mozilla and Daniel Appelquist (@torgo) from Telefónica Digital/ W3C talking about starting your first HTML5 app. You can watch the video here.

    First things first: you don’t build apps for Firefox OS – you build HTML5 apps for the Web. Firefox OS enables you as a developer to access the hardware of the phone by means of Web APIs – JavaScript APIs that are proposals to the standards bodies to give secure and simple access.

    This means first and foremost that for web developers, nothing changes. There is no SDK for the web you need to download and install. You can use the editor and tool chain you are familiar with. This could be as simple as VI on the command line, or Eclipse as you are working with other languages than the web ones. Firefox OS doesn’t demand any fixed environment, much like the Web doesn’t. That said, there are efforts to create HTML5 tools out there and Mozilla is keeping a close eye on these efforts to see where and if partnering makes sense.

    To get you started with building a Firefox OS app, you simply start with an HTML5 application in your browser. Whilst the first wave of Firefox OS devices have a resolution of 320 x 480 pixels, you should not fix your app to that size. Embracing the ubiquitous nature of the web, it seems prudent to use a responsive design approach. We’ve collected a lot of information on how to design a good HTML5 app on the Firefox OS developer hub.

    One great feature of the Firefox Developer Tools is the responsive view mode. You can turn this one on by opening the developer tools and clicking the responsive mode icon. This will result in the current page becoming re-sizable in the browser without losing the developer tools or having to resize the window: the responsive mode in the Firefox developer tools allows you to resize your app without resizing the browser

    Firefox is not the only browser with great developer tools built in. Chrome, for example allows you to simulate touch events when you are not on a touch device. To enable this, go to the developer tools settings, click “Overrides” and check the “Enable touch events” checkbox. For some great tips on when to use touch and when to use click, check out this video by Peter-Paul Koch (@ppk).

    If you want to test Firefox OS itself or how your app performs in it – including the install process – you can download the Firefox OS simulator, a no-restart-required add-on for Firefox.

    Once installed, you get a dashboard that allows you to manage your applications on your computer and start or stop the emulator:firefox emulator dashboard

    When you start the simulator, you get a clean instance of Firefox OS running on your computer in a window of the right dimensions. You
    can try out the OS, install your apps and see what the experience is like. simulator

    More detailed testing of the performance of your apps requires a Firefox OS device. If you have one of them, you can connect the phone via USB and send your app directly from the simulator to the phone.

    device connected

    The tooling space of HTML5 applications is one of the most discussed markets on the Web right now. We are confident that in the nearer future a lot of new, amazing tools will become available to make HTML5 app development easy and give developers the insights they need when they develop. For now, using the browsers’ developer tools and the Firefox OS sSimulator will get you 90% on the way.

  4. App discovery – Firefox OS for developers: the platform HTML5 deserves

    In the previous edition of this video series we introduced FirefoxOS and what it means for the open web and HTML5. We explained that apps for FirefoxOS are HTML5 apps, and could be as simple as a mobile-optimised web site with a manifest file. be-the-future

    Now we’re back explaining how Firefox OS is different from other platforms when it comes to app discovery. Here are Mozilla’s principal developer evangelist Chris Heilmann @codepo8 and Desigan Chinniah @cyberdees of the Firefox OS business development team showcasing how easy it is to get your app found on Firefox OS. You can watch the video on YouTube.

    The main difference of app discovery in Firefox OS is that you are not limited to a listing in a closed app store. Being a pure web platform, you can publish your apps either by adding them to the marketplace, but also by adding a simple “install from web” button to your already existing web sites. The code is as simple as adding an event handler to a button that points to your application’s manifest file:

    var button = document.querySelector('#install');
    button.addEventListener('click', function(ev) {
      var installapp = navigator.mozApps.install(manifestURL);  
      installapp.onsuccess = function(data) {
        // App is installed
      };
      installapp.onerror = function() {
        // App wasn't installed, info is in 
        // installapp.error.name  
      };
    }, false);

    That way you can re-use the work you put into search engine optimisation over the last years and make what you do on the web already advertise for your app.

    For end users, the main difference in Firefox OS is that apps can be found in context and locale. The flow for an end user in a closed app environment is the following:

    • Go to the marketplace (log in if you aren’t already)
    • Pick a promoted app or drill down into a category or search apps by name
    • Pick the app, go through the install process, give it the permissions it wants and start the app
    • Use it or uninstall it

    In any case app discovery is very targeted to the name of the app or dependent on the promotion of the app in the store. Firefox OS works around these problems and instead allows users to find relevant apps with a more intelligent search functionality that also understands locales.

    In the case of Firefox OS users can search for a topic, like the name of a band or a movie and find applications that are relevant to that search. For example if you look for a band name, you get Soundcloud for music, Wikipedia for information, Ticketmaster to get tickets for their next concert and many other, relevant apps. This is in the US, in other countries you’d get apps that are relevant there.

    Activating any of the icons in the search results then opens this app with the search term you entered, instead of just opening the app and asking you to re-enter your search term. The apps that are loaded are the mobile optimised HTML5 site of that provider, which means they load fast and don’t need to install – it is a real “try before you buy”.

    If the user likes the app, they can long-tap and install it, which means you get all the extra functionality Firefox OS offers HTML5 solutions.

    In essence, with Firefox OS, we made app discovery as easy as browsing the web, and we give you a very good reason to brush up the mobile optimised web sites you already have on the web.

    We hope you enjoy this and that it answers a few of the questions you had about Firefox OS. Watch this space for more videos in this series.

  5. Introducing… our new evangelists

    It is with great pride that we can announce three new faces in our midst, three people Mozilla just managed to hire to do Firefox OS developer outreach. Over the next few months you will hear and read a lot from these, that’s why we thought we start by introducing them with some short interviews.

    Jason Weathersby

    Jason Weathersby The first of the new bunch to sign up is Jason Weathersby, based in Inman, South Carolina in the United States. You can reach Jason on Twitter as @JasonWeathersby. When asked for a one liner about what he is looking forward to the most in this new role he stated “I am looking forward to helping developers create some fantastic Firefox OS apps.” and one of his big hobbies is playing the guitar. You can see what Jason had to say in his introduction interview on YouTube.

    Angelina Fabbro

    Angelina Fabbro Angelina Fabbro, based in Vancouver, Canada also got on board despite being pestered and climbed on by her cat during the video interview. You can contact Angelina on Twitter as @angelinamagnum. In her own words, she is “looking forward to making Firefox OS a solid product for the end user by encouraging best practices amongst developers. Pretty stoked to play with the newer APIs as I like trying new things.”. When asked for hobbies, she replied that she is taking singing lessons and plays “Magic: The Gathering”. Not at the same time though. You can see what Angelina had to say about herself here.

    Frédéric Harper

    Frédéric Harper Adding the final “je ne sais quoi” into the mix we have Frédéric Harper from Montréal (Québec, Canada). You can catch him on Twitter as @fharper in French or English. He is all about “Helping the Mozilla mission by promoting the openness of the Web, sharing my passion of Web standards, and helping people to be successful with Firefox OS.” and – in his own words – is a mad Geek t-shirt collector, likes gnomes and unicorns. You can see how he dealt with my questions here.

    Get prepared to hear a lot from these around here and on the interwebs from now on and join us in welcoming them to Mozilla and to the world of open web technology evangelism.

  6. Firefox OS for developers – the platform HTML5 deserves

    Over the next few weeks we will publish a series of short videos here that explain what Firefox OS means for developers and how you can be part of the revolution it brings to the world.

    be-the-future

    In various conversations we’ve repeatedly heard from developers that they view Firefox OS as simply a third player in the mobile space next to Android and iOS. This is not exactly what we are trying to achieve. Firefox OS is unique in its approach as it doesn’t target the high-end markets already saturated by other platforms. Instead its goal is to replace feature phones in markets that have no access to high-end smartphones or aren’t even considered in closed application mechanisms like marketplaces. Furthermore we wanted to create the first truly open and web-standards based ecosystem and mobile operating system – nothing in Firefox OS is closed or alien to the Web.

    This is why we recorded this video series to explain in a short and simple fashion where you can go to get started as a developer for Firefox OS and how this means writing HTML5 without the limitations other platforms have in place for web-standards based applications.

    Today we start with a short video featuring Chris Heilmann (@codepo8) from Mozilla and Daniel Appelquist (@torgo) from Telefónica Digital/ W3C talking about the goals of Firefox OS. You can watch the video here.

    Resources mentioned in the video are:

    We hope you enjoy this and that it answers a few of the questions you had about Firefox OS. Watch this space for more videos in this series.

  7. Building a simple paint game with HTML5 Canvas and Vanilla JavaScript

    When the talk is about HTML5 Canvas you mostly hear about libraries to make it work for legacy browsers, performance tricks like off-screen Canvas and ways to draw and animate sprites and tiles. This is only one part of Canvas, though. On the lowest level, Canvas is a way to manipulate pixels of a portion of the screen. Either via a painting API or by directly manipulating the pixel array (which by the way is a typed array and thus performs admirably).

    Using this knowledge, I thought it’d be fun to create a small game I saw in an ad for a tablet: a simple game for kids to paint letters. The result is a demo for FirefoxOS called Letterpaint which will show up soon on the Marketplace. The code is on GitHub.

    letterpaint

    The fun thing about building Letterpaint was that I took a lot of shortcuts. Painting on a canvas is easy (and gets much easier using Jacob Seidelin’s Canvas cheatsheet), but on the first glance making sure that users stay in a certain shape is tricky. So is finding out how much of the letter has been filled in. However, by going back to seeing a Canvas as a collection of pixels, I found a simple way to make this work:

    • When I paint the letter, I read out the amount of pixels that have the colour of the letter
    • When you click the mouse button or touch the screen I test the colour of the pixel at the current mouse/finger position
    • When the pixel is not transparent, you are inside the letter as the main Canvas by default is transparent
    • When you release the mouse or stop touching the screen I compare the amount of pixels of the paint colour with the ones of the letter.

    Simple, isn’t it? And it is all possible with two re-usable functions:

    /*
      getpixelcolour(x, y)
      returns the rgba value of the pixel at position x and y
    */
    function getpixelcolour(x, y) {
      var pixels = cx.getImageData(0, 0, c.width, c.height);
      var index = ((y * (pixels.width * 4)) + (x * 4));
      return {
        r: pixels.data[index],
        g: pixels.data[index + 1],
        b: pixels.data[index + 2],
        a: pixels.data[index + 3]
      };
    }
     
    /*
      getpixelamount(r, g, b)
      returns the amount of pixels in the canvas of the colour 
      provided
    */
    function getpixelamount(r, g, b) {
      var pixels = cx.getImageData(0, 0, c.width, c.height);
      var all = pixels.data.length;
      var amount = 0;
      for (i = 0; i < all; i += 4) {
        if (pixels.data[i] === r &&
            pixels.data[i + 1] === g &&
            pixels.data[i + 2] === b) {
          amount++;
        }
      }
      return amount;
    }

    Add some painting functions to that and you have the game done. You can see a step by step guide of this online (and pull the code from GitHub) and there is a screencast describing the tricks and decisions on YouTube.

    The main thing to remember here is that it is very tempting to reach for libraries and tools to get things done quickly, but that it could mean that you think too complex. Browsers have very powerful tools built in for us, and in many cases it means you just need to be up-to-date and fearless in trying something “new” that comes out-of-the-box.

  8. HTML5 mythbusting

    The ongoing discussion about the “readiness” of HTML5 is based on a lot of false assumptions. These lead to myths about HTML5 that get uttered once and then continuously repeated – a lot of times without checking their validity at all.

    HTML5 doesn’t perform?

    The big thing everybody who wants to talk about the problems with HTML5 is performance. The main problem here is that almost every single comparison misses the fact that you are comparing apples and pears (no pun intended).

    Comparing an HTML5 application’s performance with a native App is comparing a tailored suit with one bought in a shop. Of course the tailored suit will fit you like a glove and looks amazing but if you ever want to sell it or hand it over to someone else you are out of luck. It will not be the same for the next person.

    IMG_4197.jpg

    That is what native Apps are – they are built and optimized for one single environment and purpose and are fixed in their state – more on that later.

    HTML5, on the other hand by its very definition is a web technology that should run independent of environment, display or technology. It has to be as flexible as possible in order to be a success on the web. In its very definition the web is for everybody, not just for a small group of lucky people who can afford a very expensive piece of hardware and are happy to get locked into a fixed environment governed by a single company.

    Native applications need to be written for every single device and every new platform from scratch whereas an HTML5 App allows you to support mobiles, tablets and desktops with the same product. Instead of having fixed dimensions and functionality an HTML5 App can test what is supported and improve the experience for people on faster and newer devices whilst not locking out others that can not buy yet another phone.

    Native Apps on the other hand do in a lot of cases need an upgrade and force the end user to buy new hardware or they’ll not get the product at all. From a flexibility point of view, HTML5 Apps perform admirably whilst native applications make you dependent on your hardware and leave you stranded when there is an upgrade you can’t afford or don’t want to make. A great example of this is the current switch from Apple to their own maps on iOS. Many end users are unhappy and would prefer to keep using Google Maps but can not.


    HexGL – a WebGL powered racing game

    Seeing that HTML5 is perfectly capable on Desktop to exceed in performance, from scrolling performance to analyzing and changing video on the fly up to running full 3D games at a very high frame rate and have high speed racing games we have to ask ourselves where the problem with its performance lies.

    The answer is hardware access. HTML5 applications are treated by mobile hardware developed for iOS and Android as second class citizens and don’t get access to the parts that allow for peak performance. A web view in iOS is hindered by the operating system to perform as fast as a native App although it uses the same principles. On Android both Chrome and Firefox show how fast browsers can perform whereas the stock browser crawls along in comparison.

    The stock browser on Android reminds us of the Internet Explorer of the 90s which threatened to be set in stone for a long time and hinder the world wide web from evolving – the very reason Mozilla and Firefox came into existence.

    In essence HTML5 is a Formula 1 car that has to drive on a dirt road whilst dragging a lot of extra payload given to it by the operating system without a chance to work around that – for now.

    HTML5 can not be monetized?

    HTML5 is a technology stack based on open web technologies. Saying that HTML5 has no monetization model is like saying the web can not be monetized (which is especially ironic when this is written on news sites that show ads).

    Whilst on the first glance a closed App-market is a simple way to sell your products there is a lot of hype about their success and in reality not many developers manage to make a living with a single app on closed App markets. As discovery and find-ability is getting increasingly harder in App markets a lot of developers don’t build one App but hundreds of the same App (talking dog, talking cat, talking donkey…) as it is all about being found quickly and being on the first page of search results in the market.

    This is where closed App markets with native Apps are a real disadvantage for developers: Apps don’t have an address on the web (URL) and can not be found outside the market. You need to manually submit each of the Apps in each of the markets, abide to their review and submission process and can not update your App easily without suffering outages in your offering.

    An HTML5 App is on the web and has a URL, it can also get packaged up with products like Adobe PhoneGap to become a native application for iOS or Android. The other way around is not possible.

    In the long term that begs the question what is the better strategy for developers: betting on one closed environment that can pull your product any time it wants or distributing over a world-wide, open distribution network and cover the closed shops as well?

    Many apps in the Android and iOS store are actually HTML5 and got converted using PhoneGap. The biggest story about this was the Financial Times releasing their app as HTML5 and making a better profit than with the native one. And more recently the New York Times announced it was following suit with its Web app.

    HTML5 can not be offline?

    As HTML5 is a web technology stack the knee-jerk reaction is thinking that you would have to be online all the time to use them. This is plain wrong. There are many ways to store content offline in a HTML5 application. The simplest way is the Web Storage API which is supported across all modern browsers (excluding Opera mini which is a special case as it sends content via a cloud service and has its own storage tools). You can also store the application itself offline using AppCache which is supported by all but Internet Explorer. If you have more complex data to store than Web Storage provides you can use either IndexedDB (for Chrome and Firefox) or WebSQL (for iOS and Safari). To work around the issues there are libraries like Lawnchair available to make it easy for developers to use.

    HTML5 has no development environment?

    One concern often mentioned is that HTML5 lacks in tooling for developers. Strangely enough you never hear that argument from developers but from people who want to buy software to make their developers more effective instead of letting them decide what makes them effective.

    HTML5 development at its core is web development and there is a quite amazingly practical development environment for that available. Again, the main issue is a misunderstanding of the web. You do not build a product that looks and performs the same everywhere – this would rob the web of its core strengths. You build a product that works for everybody and excels on a target platform. Therefore your development environment is a set of tools, not a single one doing everything for you. Depending on what you build you choose to use many of them or just one.

    The very success of the web as a media is based on the fact that you do not need to be a developer to put content out – you can use a blogging platform, a CMS or even a simple text editor that comes with your operating system to start your first HTML page. As you progress in your career as a developer you find more and more tools you like and get comfortable and effective with but there is no one tool to rule them all. Some developers prefer IDEs like Visual Studio, or Eclipse. Others want a WYSIWYG style editor like Dreamweaver but the largest part of web developers will have a text editor or other of some sorts. From Sublime Text, Notepad++ up to VIM or emacs on a Linux computer, all of these are tools that can be used and are used by millions of developers daily to build web content.

    When it comes to debugging and testing web developers are lucky these days as the piece of software our end users have to see what we build – the browser – is also the debugging and testing environment. Starting with Firefox having Firebug as an add-on to see changes live and change things on the fly, followed by Opera’s Dragonfly and Safari and Chrome’s Devtools, all browsers now also have a lot of functionality that is there especially for developers. Firefox’s new developer tools go even further and instead of simply being a debugging environment are a set of tools in themselves that developers can extend to their needs.

    Remote debugging is another option we have now. This means we can as developers change applications running on a phone on our development computers instead of having to write them, send them to the phone, install them, test them, find a mistake and repeat. This speeds up development time significantly.


    Remote debugging in Firefox

    For the more visual developers Adobe lately released their Edge suite which brings WYSIWYG style development to HTML5, including drag and drop from Photoshop. Adobe’s Edge Inspect and PhoneGap makes it easy to test on several devices at once and send HTML5 Apps as packaged native Apps to iOS and Android.

    In terms of deployment and packaging Google just released their Yeoman project which makes it dead easy for web developers to package and deploy their web products as applications with all the necessary steps to make them perform well.

    All in all there is no fixed development environment for HTML5 as that would neuter the platform – this is the web, you can pick and choose what suits you most.

    Things HTML5 can do that native Apps can not

    In essence a lot of the myths of HTML5 are based on the fact that the comparison was between something explicitly built for the platform it was tested on versus something that is also supported on it. Like comparing the performance of speedboat and a hovercraft would result in the same predictable outcome. The more interesting question is what makes HTML5 great for developers and end users, that native applications can or do not do:

    • Write once, deploy anywhere – HTML5 can run in browsers, on tablets and desktops and you can convert it to native code to support iOS and Android. This is not possible the other way around.
    • Share over the web – as HTML5 apps have a URL they can be shared over the web and found when you search the web. You don’t need to go to a market place and find it amongst the crowded, limited space but the same tricks how to promote other web content apply. The more people like and link to your app, the easier it will be found.
    • Built on agreed, multi-vendor standards – HTML5 is a group effort of the companies that make the web what it is now, not a single vendor that can go into a direction you are not happy with
    • Millions of developers – everybody who built something for the web in the last years is ready to write apps. It is not a small, specialized community any longer
    • Consumption and development tool are the same thing – all you need to get started is a text editor and a browser
    • Small, atomic updates – if a native app needs an upgrade, the whole App needs to get downloaded again (new level of Angry Birds? Here are 23MB over your 3G connection). HTML5 apps can download data as needed and store it offline, thus making updates much less painful.
    • Simple functionality upgrade – native apps need to ask you for access to hardware when you install them and can not change later on which is why every app asks for access to everything upfront (which of course is a privacy/security risk). An HTML5 app can ask for access to hardware and data on demand without needing an update or re-installation.
    • Adaptation to the environment – an HTML5 app can use responsive design to give the best experience for the environment without having to change the code. You can switch from Desktop to mobile to tablet seamlessly without having to install a different App on each.

    Let’s see native Apps do that.

    Breaking the hardware lockout and making monetization easier

    The main reason why HTML5 is not the obvious choice for developers now is the above mentioned lockout when it comes to hardware. An iOS device does not allow different browser engines and does not allow HTML5 to access the camera, the address book, vibration, the phone or text messaging. In other words, everything that makes a mobile device interesting for developers and very necessary functionality for Apps.

    To work around this issue, Mozilla and a few others have created a set of APIs to define access to these in a standardized way called Web APIs. This allows every browser out there to get access to the hardware in a secure way and breaks the lockout.

    The first environment to implement these is the Firefox OS with devices being shipped next year. Using a Firefox OS phone you can build applications that have the same access to hardware native applications have. Developers have direct access to the hardware and thus can build much faster and – more importantly – much smaller Apps. For the end user the benefit is that the devices will be much cheaper and Firefox OS can run on very low specification hardware that can for example not be upgraded to the newest Android.

    In terms of monetization Mozilla is working on their own marketplace for HTML5 Apps which will not only allow HTML5 Apps to be submitted but also to be discovered on the web with a simple search. To make it easier for end users to buy applications we partner with mobile providers to allow for billing to the mobile contract. This allows end users without a credit card to also buy Apps and join the mobile web revolution.

    How far is HTML5?

    All in all HTML5 is going leaps and bounds to be a very interesting and reliable platform for app developers. The main barriers we have to remove is the hardware access and with the WebAPI work and systems like PhoneGap to get us access these are much less of a stopper than we anticipated.

    The benefits of HTML5 over native apps mentioned above should be reason enough for developers to get involved and start with HTML5 instead of spending their time building a different code base for each platform. If all you want to support is one special platform you don’t need to go that way, but then it is also pointless to blame HTML5 issues for your decision.

    HTML5 development is independent of platform and browser. If you don’t embrace that idea you limit its potential. Historically closed platforms came and went and the web is still going strong and allows you to reach millions of users world-wide and allows you to start developing without asking anyone for permission or having to install a complex development environment. This was and is the main reason why people start working with the web. And nobody is locked out, so have a go.

  9. Broken promises of HTML5 and what’s next? – a presentation at HTML5DevConf

    Yesterday Mozilla attended the HTML5 Developer Conference in San Francisco, California to give a keynote presentation. The very packed schedule of the conference already covered a lot of topics around the subject matter, which is why we considered it worth while to contribute with a talk that told tales from the trenches of advocating HTML5 instead of going into technical details. Under the title of “Broken Promises of HTML5 and what’s next?” we reported some of the findings we had when talking to press and people outside the web enthusiast sphere.

    Keynote audience

    The Slides of the talk are available online and there is a screencast of the live presentation on YouTube.

    The organisers of HTML5DevConf promised to release the video recording in the next few weeks.

    Here are a few of the points covered to make it more interesting for you to check the 50 minute talk, in case you need more incentive:

    Following the press around HTML5 lately we get more and more the impression that we are on the downward slope of the hype cycle about the cool new tech HTML5. The honeymoon period where every shiny HTML5 demo was heralded as the coolest thing and the future of the internet is over and business analysts and developers start feeling disappointed by what HTML5 is portrayed as. A lot of the things that get us as developers excited have been done in Flash years ago and performed better – even on the hardware of the day. The main mistake we seem to make when advocating HTML5 is not think about what makes it unique and how it is different than other approaches to bring higher fidelity to the web.

    This talk covers a few ideas we can follow to turn the disappointment around. We will soon deliver a more in-depth article about this and are in talks with business analysts to make that message clearer. Some of the points mentioned here are allowing for re-use of existing knowledge with tools to get Flash developers to create HTML5 content, convert C++ to HTML5 for games using Emscripten (with Bananabread as the flagship demo) and in general not to think about what we can add but instead concentrate on what we can not remove to make our products web products and apps instead of simulating native and mobile apps.

    It is up to us to move HTML5 from a flash in the pan to a productive platform, and we can do that by re-using existing knowledge and merge it with the web ideals and the basic principles of HTML5. We will not succeed by trying to replace other platforms that have a lot of knowledge and perform very well indeed.

  10. Using data-* attributes in JavaScript and CSS

    When HTML5 got defined one of the things that was planned for was extensibility in terms of data that should be in the HTML, but not visible. The data-* attributes allow us to store extra information on HTML elements without needing to use a non-semantic element or pollute the class name. In essence this is what we did with custom attributes before.

    These data attributes can be used in many ways, some are a bad idea but others are a good plan. The rule of thumb is that content that should be visible and accessible should not be stored in them. The reason is that assistive technology is not likely to be able to access them and search crawlers don’t index them either.

    The syntax is dead easy. Say you have an article and you want to store some extra information that doesn’t have any visual representation. Just use data attributes for that:

    <article 
      id="electriccars"
      data-columns="3" 
      data-indexnumber="12314" 
      data-parent="cars">
    ...
    </article>

    Reading those out in JavaScript is also very simple. You could use getAttribute to read them but the HTML5 standard defines a simpler way: a DOMStringMap you can read out via a dataset property:

    var article = document.querySelector('#electriccars'),
                  data = article.dataset;
     
    // data.columns -> "3"
    // data.indexnumber -> "12314"
    // data.parent -> "cars"

    Each property is a string (even if you omit the quotes in the HTML) and can be read and written. In the above case setting article.dataset.columns = 5 would change that attribute.

    Now, as data-attributes are plain HTML attributes you can even access them from CSS. For example to show the parent data on the article you can use generated content in CSS:

    article::before {
      content: attr(data-parent);
    }

    You can also use the attribute selectors in CSS to change styles according to the data:

    article[data-columns='3']{
      width: 400px;
    }
    article[data-columns='4']{
      width: 600px;
    }

    You can see all this working together in this JSBin example.

    Data attributes can also be stored to contain information that is constantly changing, like scores in a game. Using the CSS selectors and JavaScript access here this allows you to build some nifty effects without having to write your own display routines. See the following screencast for an example using generated content and CSS transitions:

    The code example shown in the screencast is also on JSBin.

    Issues with data-attributes

    Sadly enough it seems there is nothing that is so simple and useful that doesn’t come with a price. In this case the main issues to consider are that Internet Explorer does not support the dataset but you’d need to read them out with getAttribute() instead. The other issue is that the performance of reading data-attributes compared to storing this data in a JS data warehouse is bad. Using dataset is even slower than reading the data out with getAttribute().

    That said, though, for content that is not to be shown they are a great solution and maybe we can get them into the next IE soon.