Mozilla

Found 438 results for “html5”

Sort by:

View:

  1. Mozilla at SXSW 2012

    Building on the momentum generated by Mozilla at Mobile World Congress last week, this week we’re rolling into Austin, Texas for South by Southwest. If you’re attending SXSW, please join us at events and sessions.

    Reminder: Daylight Savings Time starts on Sunday, March 11 at 2am. Clocks move forward one hour. Sunday sessions are earlier than you expect them to be.

    Events

    Mozilla is partnering with Samsung Mobile and Twitter to present FEED at Austin Museum of Art—Arthouse at the Jones Center, 700 Congress Avenue. Mozilla is sponsoring events Friday to Monday. Please join us on Saturday and Sunday nights for drinks and music on the rooftop deck. Or, if you’re looking for a quiet place during the day to have a conversation or recharge away from the crowds, please stop by, and see an installation using Collusion. Art hackers Beak Labs will also be creating a Popcorn.js installation live on site. The space is open from 10am to 6pm, and 9pm to 2am.

    We’re also participating in the Knight Foundation’s Media Innovation Fair at Brush Square Park on Saturday and sponsoring the Austin JavaScript riverboat cruise on Sunday evening.

    Sessions

    Look for these Mozillians appearing at SXSW sessions (Interactive Festival, unless noted):

    Day Time Who Title
    Saturday 9:30-10:30am Joe Stagner Brendan Eich The State of Browser Developer Tools
    11am-noon Gary Kovacs (CEO) SOPA/PIPA: Why the Open Internet Needs Us
    11am-noon David Bolter Accessible HTML5 Canvas? Really? How?
    3:30-4:30pm Tantek Çelik The Rise of the Indie Web
    5-6pm Brendan Eich Browser Wars V: The Angry Birds Era
    Sunday 11am-noon CDT David Baron Fast CSS: How Browsers Lay Out Web Pages
    12:30-1:30pm Elika Etemad, Boris Zbarsky CSS.next: Current Experiments, CSS4 and the Future
    12:30-1:30pm Brett Gaylor Does HTML5 Offer a Montage Moment for Web Cinema? (Film)
    3:30-4:30pm Dan Sinker Open Web, Open News: Reporters & Developers Remix
    Monday 9:30-10:30am Ben Moscowitz HTML5 for Film: Leading Edge or Bleeding Edge? (Film)

    SXSW is a long event, especially if you stay for the film and music festivals. Pace yourself, hydrate, and before you go to sleep, remember to plug in all the devices.

  2. Ask your HTML5 Browser Tools Questions for SXSW Panel.

    At this years “South by Southwest” (SXSW) Interactive event I’m joining Paul Irish from Google, Mike Taylor from Opera, Brandon Satron from Telerik and Javascript Developer and author Garann Means in a panel on “The State of Browser Developer Tools

    The group has a Google Moderator page where you can ask your questions in advance. Please do so.

    Not able to attend the panel at SXSW? No problem. I’ll post a collection of the questions and answer right here on Hacks sometime after the event.

  3. There is no simple solution for local storage

    TL;DR: we have to stop advocating localStorage as a great opportunity for storing data as it performs badly. Sadly enough the alternatives are not nearly as supported or simple to implement.

    When it comes to web development you will always encounter things that sound too good to be true. Sometimes they are good, and all that stops us from using them is our notion of being conspicuous about *everything* as developers. In a lot of cases, however, they really are not as good as they seem but we only find out after using them for a while that we are actually “doing it wrong”.

    One such case is local storage. There is a storage specification (falsely attributed to HTML5 in a lot of examples) with an incredibly simple API that was heralded as the cookie killer when it came out. All you have to do to store content on the user’s machine is to access the navigator.localStorage (or sessionStorage if you don’t need the data to be stored longer than the current browser session):

    localStorage.setItem( 'outofsight', 'my data' );
    console.log( localStorage.getItem( 'outofsight' ) ); // -> 'my data'

    This local storage solution has a few very tempting features for web developers:

    • It is dead simple
    • It uses strings for storage instead of complex databases (and you can store more complex data using JSON encoding)
    • It is well supported by browsers
    • It is endorsed by a lot of companies (and was heralded as amazing when iPhones came out)

    A few known issues with it are that there is no clean way to detect when you reach the limit of local storage and there is no cross-browser way to ask for more space. There are also more obscure issues around sessions and HTTPS, but that is just the tip of the iceberg.

    The main issue: terrible performance

    LocalStorage also has a lot of drawbacks that aren’t quite documented and certainly not covered as much in “HTML5 tutorials”. Especially performance oriented developers are very much against its use.

    When we covered localStorage a few weeks ago using it to store images and files in localStorage it kicked off a massive thread of comments and an even longer internal mailing list thread about the evils of localStorage. The main issues are:

    • localStorage is synchronous in nature, meaning when it loads it can block the main document from rendering
    • localStorage does file I/O meaning it writes to your hard drive, which can take long depending on what your system does (indexing, virus scanning…)
    • On a developer machine these issues can look deceptively minor as the operating system cached these requests – for an end user on the web they could mean a few seconds of waiting during which the web site stalls
    • In order to appear snappy, web browsers load the data into memory on the first request – which could mean a lot of memory use if lots of tabs do it
    • localStorage is persistent. If you don’t use a service or never visit a web site again, the data is still loaded when you start the browser

    This is covered in detail in a follow-up blog post by Taras Glek of the Mozilla performance team and also by Andrea Giammarchi of Nokia.

    In essence this means that a lot of articles saying you can use localStorage for better performance are just wrong.

    Alternatives

    Of course, browsers always offered ways to store local data, some you probably never heard of as shown by evercookie (I think my fave when it comes to the “evil genius with no real-world use” factor is the force-cached PNG image to be read out in canvas). In the internal discussions there was a massive thrust towards advocating IndexedDB for your solutions instead of localStorage. We then published an article how to store images and files in IndexedDB and found a few issues – most actually related to ease-of-use and user interaction:

    • IndexedDB is a full-fledged DB that requires all the steps a SQL DB needs to read and write data – there is no simple key/value layer like localStorage available
    • IndexedDB asks the user for permission to store data which can spook them
    • The browser support is not at all the same as localStorage, right now IndexedDB is supported in IE10, Firefox and Chrome and there are differences in their implementations
    • Safari, Opera, iOS, Opera Mobile, Android Browser favour WebSQL instead (which is yet another standard that has been officially deprecated by the W3C)

    As always when there are differences in implementation someone will come up with an abstraction layer to work around that. Parashuram Narasimhan does a great job with that – even providing a jQuery plugin. It feels wrong though that we as implementers have to use these. It is the HTML5 video debate of WebM vs. H264 all over again.

    Now what?

    There is no doubt that the real database solutions and their asynchronous nature are the better option in terms of performance. They are also more matured and don’t have the “shortcut hack” feeling of localStorage. On the other hand they are hard to use in comparison, we already have a lot of solutions out there using localStorage and asking the user to give us access to storing local files is unacceptable for some implementations in terms of UX.

    The answer is that there is no simple solution for storing data on the end users’ machines and we should stop advocating localStorage as a performance boost. What we have to find is a solution that makes everybody happy and doesn’t break the current implementations. This might prove hard to work around. Here are some ideas:

    • Build a polyfill library that overrides the localStorage API and stores the content in IndexedDB/WebSQL instead? This is dirty and doesn’t work around the issue of the user being asked for permission
    • Implement localStorage in an asynchronous fashion in browsers – actively disregarding the spec? (this could set a dangerous precedent though)
    • Change the localStorage spec to store asynchronously instead of synchronously? We could also extend it to have a proper getStorageSpace interface and allow for native JSON support
    • Define a new standard that allows browser vendors to map the new API to the existing supported API that matches the best for the use case?

    We need to fix this as it doesn’t make sense to store things locally and sacrifice performance at the same time. This is a great example of how new web standards give us much more power but also make us face issues we didn’t have to deal with before. With more access to the OS, we also have to tread more carefully.

  4. March Dev Derby: Show us what you can do with CSS 3D transforms

    The March Dev Derby begins today! A monthly contest hosted by the Mozilla Developer Network, the Dev Derby allows creative web developers to push the web forward and compete for fame, glory, and prizes too.

    This month, we want to see what you can do with CSS 3D transforms. New to the topic? That’s okay. We have a great article on CSS 3D transforms over on the MDN that should help you get started. Additionally, Mozilla principal evangelist Chris Heilmann has contributed three great resources on the topic: an article on getting started, an article on progressively enhanced rollovers, and a screencast on rollovers. With all this great documentation, you’ll be an expert in no time.

    The Prizes

    • First place: An Android mobile device from Motorola or Samsung and an article featuring your work here on Mozilla Hacks.
    • Second place: A hand-crafted laptop messenger bag from Rickshaw.
    • Third place: A limited edition MDN t-shirt to show off your geek cred.

    You might have noticed that the March Derby already has three entries. Want to get a head start like these people did? We are also accepting entries related to HTML5 audio (April Derby) and the Websocket API (May Derby). Submit today!

  5. Presentation: HTML5 and friends at Mobile World Congress 2012

    As part of the WIP Jam at the Mobile World Congress in Barcelona, Spain we were asked to give and introduction to HTML5 so we sent Chris Heilmann and Joe Stagner to set the record straight in terms of what HTML5 is and what you can do with it.

    The presentation was on the last day of the conference and both of us had spent long hours explaining all Mozilla technologies on our booth and really not enough hours sleeping in between. In addition to that the room was a boiling 30 degrees and packed with lots of developers. It seems we did a good job regardless as nobody left and we had a lot of great questions afterwards.

    The slides (well, the HTML5 document) are available for you to see:

    Slides for HTML5 and friends

    However, they make much more sense when you see them in context, which is why we also provide you with a screencast of the talk:

    All in all it was a lot of fun talking to people at MWC and Boot to Gecko showed that HTML5 is the future of mobile as much as it is already the present technology of choice on the desktop.

  6. Friday fun: Trigger Rally in WebGL

    As reported by Creative JS, Jasmine Kent ported her open source Linux racing game Trigger Rally to WebGL to run in HTML5 browsers. In the following video you can see it running pretty smoothly on my MacBook air that is already running 12% of CPU without it starting (as ScreenFlow is recording and VLC was playing music whilst TweetDeck used quite a chunk, too):

    If you are the artistic type, you can even design your own levels for the game.

    You can play play Trigger Rally online here: http://triggerrally.com/ or follow it on Twitter @triggerrally.

  7. Rounding-up the first Mozilla HTML5 games work week

    A few weeks ago I wrote about the first Mozilla HTML5 games work week in Toronto and why it is important. In this post I summarise the week’s events and highlight some key observations.

    DSCF0062

    Before I start I should point out that I won’t be making any dramatic announcements from Mozilla or going into too much detail about some of the decisions that were made during the work week. While some important discussions and decisions did occur, some aren’t quite ready to be made public yet. However, we will be posting specifically about some of these things in the coming weeks so keep an eye open. The purpose of this post is to give an overview of the week’s events and some of the discussions that were made.

    So with that out of the way, let’s crack on.

    Why a HTML5 games work week?

    With the amount of buzz happening around HTML5 and JavaScript, it could be seen as surprising that we hadn’t organised a get-together of all the interested parties within Mozilla sooner. The long and short of it is that it has only been recently that we have begun to construct a consistent vision and commitment to HTML5 games.

    To create a vision we need to find out who within the Mozilla community is actually interested in games and how we can work together to lay the path towards the future. The HTML5 games work week was set up to start the ball rolling. It’s safe to say that Mozilla cares a lot about games and this work week is just the beginning.

    Aside from the internal interest and passion to build games, there are an increasing number of HTML5 games being released in the Web community each and every week. This shows that there is desire for these types of games and for browsers to work out how to support them.

    DSCF0068

    It’s also clear that there are areas of improvement that need to be addressed within all browsers so that HTML5 games can flourish in the future. The point of the work week has been to bring all interested parties together in one place to make stuff happen and actually make decisions about how to address these issues.

    From another perspective, the work week gave Mozilla the chance to listen to external developers and hear about the issues they are experiencing in the real world of HTML5 game development. We don’t develop games every day, so it is of absolute importance for us to fully understand the concerns of the people who do. Without this type of feedback we simply won’t be able to make our improvements as useful as they could be.

    Who was there?

    The work week was split into 2 parts: the first was attended by Mozilla staff and key Mozilla contributors, and the second included some invited external guests.

    DSCF0083

    It was clear from the beginning that we had a whole bunch of people within Mozilla who were passionate about games and wanted to see us commit to them. I already knew a handful of these people, but I had absolutely no idea that so many Mozillians from so many different areas of the organisation were so interested. It great to see all those people in one (big) room working together to make awesome stuff happen.

    The invited guests for the second part of the work week included developers from game studios like EA, as well as individual developers who have proven themselves experts in specific technologies, like WebGL. We worked with these guests to hear about issues from the guys dealing with this stuff every single day. It was absolutely fascinating to hear their concerns and work with them to find ways of improving the situation for games on the Web.

    What was discussed?

    Throughout the week we discussed a whole variety of topics ranging from how to better engage with the game developer community all the way to narrowing down fine-grained performance improvements to be made in JavaScript.

    DSCF0082

    Overall, both the internal Mozilla staff and invited guests covered the following areas and many more (in no particular order):

    • Looking into the issue of mobile and how its requirements differ from those on the desktop
    • Working out what tools are needed for authoring HTML5 games
    • Graphics, specifically Canvas and WebGL
    • Delving into the issues surrounding DRM and the protection of assets
    • NaCl and Emscripten as methods of porting existing games to the Web
    • Being clear about who exactly wants HTML5 games
    • Looking at what dev tools are required to ease the debugging of games
    • Learning the business model behind games from those with years of experience in this area
    • Working out how to better engage with the game development community
    • Producing a roadmap for the Firefox platform specifically related to games
    • Looking at ways JavaScript performance could be increased
    • Discussing the situation with asset management and how it can be solved
    • Uncovering any new WebAPIs that might become necessary
    • Delving deep into common audio issues and looking at its future
    • Hearing how high-precision timers would be used by game developers
    • Learning about WebRTC and how it will provide the functionality for peer-to-peer communication
    • Looking at how games tie into the Mozilla Marketplace and the questions that Mozilla needs to answer in this area

    All in all we covered a huge amount of stuff in the space of just a few days. I won’t list each and every decision that was made but rest assured that you’ll be hearing about them in the near-future as they get finalised and released.

    In the meantime, please check out the Are We Fun Yet site as it’s where you’ll be able to keep tabs on the status of game-related technology within Mozilla. There are also some links to the detailed feedback and notes taken during this work week.

    External demos and code review

    During the final 2 days of the work week we saw demos from our external guests and worked with them to review specific issues that they have been experiencing in Firefox.

    DSCF0080

    These demos proved invaluable for those within Mozilla to get a better idea of how professional game developers are using the technologies on the Web. We were inspired and amazed by the quality of these demos and the kind of games that could be created by pushing JavaScript right to the very limits.

    As a result of these demos and code reviews, issues have been pinned down, test-cases written, and in some cases even fixes produced there and then. It was really a very useful aspect of the work week that we clearly need to explore further in the future.

    What’s next?

    So, what does that future look like for Mozilla and game development? Frankly, very bright indeed. There is so much interest and desire within Mozilla to further the Web as a platform for games. It’s clear that we have the knowledge and resources, we just need to work out how best to apply them.

    While we work on refining our position on games and exactly how we’re going to tackle them, there are a few things that I can say for sure about the future.

    The first is that we’re dedicated to helping developers learn how to use Web technologies, that’s the reason why MDN and this blog exist. We’ve started to work on ways to help developers learn how to use Web technologies to create games. We’re not quite there yet but it’s a priority.

    Stack of gamepads

    Aside from MDN, we are going to be reaching out to developers at game-related events. At some events we’ll be even bringing along hardware for you to play with and hack with JavaScript APIs, like gamepads for the Gamepad API. We’ll also be present at some of the larger events like GDC so we can keep up to speed with the game world and talk to developers about the issues they’re facing.

    You’ll also see games as a focus on this year’s Mozilla Festival. We’re refining the program but we’re working on tying in elements like the successful Game On competition that we ran last year.

    Documenting the game-related decisions and discussions within Mozilla is key, and it is something that we’re working on improving. For now the best place to keep up to date is this blog, the #games channel on irc.mozilla.org, and the HTML5 games page on the Mozilla wiki.

    With recent announcements it’s clear that Boot to Gecko (B2G) and games will be an area that Mozilla and the developer community will explore in the near future. It will be interesting to see what people do with a mobile platform as open and hackable as B2G.

    I could go on but it’s safe to say that there is a whole bunch of stuff happening around games at Mozilla, it’s an exciting time indeed. No doubt we’ll have another work week in the coming months to take stock and take more steps in the right direction.

  8. Accepting February Dev Derby entries for one extra day

    Wait a minute, there are how many days in February?

    Looks like leap day got the best of us. Earlier today, we ended the February Dev Derby prematurely, making it impossible for some of you to submit those last-minute demos for a couple of hours.

    To make up for this oversight, we will accept February Dev Derby submissions for one extra day. Please submit your entry before March 1 at 11:59:59 p.m. PT for them to be counted.

    Want to get a head start on an upcoming Derby? We are now accepting entries related to CSS 3D Transforms (March) and HTML5 audio (April). Submit today!