Mozilla

Found 448 results for “html5”

Sort by:

View:

  1. Aurora 16 is out — Unprefixing time !

    Web developers, it is time to celebrate! In the upcoming Firefox 16, which reached the Aurora status today, a major enhancement is the unprefixing of several stable CSS features. Other notable features of interest to Web developers include several more HTML5-related APIs, better accessibility on Mac OS, and improvements to Firefox Developer Tools.

     

    So which CSS features are unprefixed?

    Specification Properties, functional notations, and at-rules More information
    CSS3 Animations animation, animation-name, animation-duration, animation-delay, animation-timing-function, animation-iteration-count, animation-direction, animation-play-state, animation-fill-mode, @keyframes Using CSS Animations
    CSS3 Transitions transition, transition-property, transition-delay, transition-duration, transition-timing-function Using CSS Transitions
    CSS3 Transforms transform, transform-origin, transform-style, backface-visibility, perspective, perspective-origin Using CSS Transforms
    CSS3 Image Values linear-gradient(), radial-gradient(), repeating-linear-gradient(), repeating-linear-gradient() Using CSS Gradients
    CSS3 Values & Units calc()

    Pay attention to the gradient syntax

    While the syntax of CSS animations, transitions and transforms has not changed lately, that is not the case of the CSS gradients syntax, which is significantly different than in most prefixed implementations.

    The definitive syntax for linear gradients is :

    <linear-gradient> = linear-gradient([ [ <angle> | to <side-or-corner> ] ,]? <color-stop>[, <color-stop>]+ )
    <side-or-corner> = [left | right] || [top | bottom]

    If we break it down, its structure is :

    linear-gradient( direction , color-stop )

    As the color-stop syntax hasn’t evolved lately, the direction parameter is where most of the latest changes happened.

    The direction parameter can be defined either using a CSS <angle>, or using the to keyword followed by one or two keywords describing the side or the corner.

    That’s the major change! This to keyword wasn’t there before and it reverses the direction that was use previously: -prefix-linear-gradient( top left ) becomes linear-gradient( to bottom right ).

    Also the <angle> changed: before, 0deg pointed to the right; now it points, consistently with other angles in the CSS spec, to the top. Like this:

    0deg points to the top, 90deg to the right, 180deg to the bottom, and 270deg to the left

    So here again, you need to change -prefix-linear-gradient(0deg) to linear-gradient(90deg). Failure to adapt the angle will lead to the gradient to be oriented differently, like this:

    An horizontal gradient, blue at the far left, white at the far right.A vertical gradient, blue at the top, white at the bottom

    Similar changes have been made to the radial gradient syntax, with a newly introduced at keyword.

    More HTML5 & friends goodies

    Unprefixing mature CSS features is not the only improvement in the area of supporting standards:

    • IndexedDB has reached Candidate Recommendation status and has been unprefixed too. This is amazing.
    • Support for the HTML5 Microdata API landed.
    • Support for the HTML5 <meter> element landed.
    • We unprefixed the Battery API.
    • We unprefixed the Vibration API.
    • We improved our media queries support by adding support for the dppx unit.
    • The CSS properties height and width are now animatable.
    • The CSS animations can be “reversed“:  the reverse and alternate-reverse keywords have been added.
    • Our implementation of JavaScript improved with several new features in Harmony (the maybe future EcmaScript 6):
      • Support for direct proxies
      • Support for the Array‘s spread operator
      • Improvement of Number, supporting now toInteger(), isInteger() and isFinite()
    • Improvement of Keyboard (still prefixed as mozKeyboard), now supporting setSelectedOption(), setValue() and onfocuschange().

    Accessiblity

    A giant step has been done in making Firefox more accessible. Support for VoiceOver on Mac OS has landed. It was the last platform where our accessibility features where severely behind. This is very exciting for all people needing such features on the Mac. More information.

    Developers Tools

    Last but not least, we continued to improved our developer tools!

    Now you can toggle a developer toolbar: go to Tools > Web Developer > Developer Toolbar, or press Shift-F2. The toolbar itself looks like this:

    The toolbar has a command line interface and also nice buttons to the right to quickly reach useful tools. The command line interface is easy to expand and more commands are expected in the future. Typing help in it displays the supported commands.

    The Web Console also has been improved and displays now a nifty error count.

    Finally our Scratchpad gained a list of recently opened files. Always convenient.

    Other notable changes

    See more details in the release notes and in Firefox 16 for developers.

    Conclusion

    Firefox 16 is on the way to being a very strong release for Web developers, both on the support of standards, and with the nice improvements in our tools, maturing quickly. In the future, Web sites will be easier to do and more powerful!

  2. HTML5 Web applications and libraries survey – first results

    At Mozilla, we are dedicated to keep the web open and independent of a single company or technology. This means that users should have a choice of browsers and technology to use to go online and should not be blocked out because they can’t afford a certain device or are forbidden to change their browser.

    In the world of mobile web development there is currently a massive debate going on about the need for support of various browsers seeing that the most successful phone systems both use the same browser engine. This is good, and we need this debate. It is not good though when developers block out users because they concentrate on targetting a browser. Sometimes this is not by choice of the developer – they are simply using tools that do that blocking for them and the usefulness of the tool outweighs the qualms developers have about that.

    We are now planning to talk to library and tool developers and help them support more than one browser engine to prevent this. As a start of that process we wanted to get a glimpse of what people are using right now so we make sure we have the most impact when we help. This is why we started a quick online survey asking developers about their tools for mobile development.

    We are happy to report that to date we have 480 answers and it is time to take a first stab at looking at the data.

    We are very aware that this is *not* a scientifically clean research and should be taken with a grain of salt (we haven’t asked how many times people used the tools or how much of their work is building mobile apps) but it gives us a good first glimpse at what makes most sense for us to do.

    So without further ado, here are the raw numbers as charts:

    Platforms

    Not many surprises there, iOS and Android are in the lead, quite a lot of people see the web as a must-have (but this is a survey called out by Mozilla…) and Blackberry and Windows Mobile are not that hight on people’s radar.

    What platforms are you targeting with your apps – iOS
    focus 208 43%
    must have 168 35%
    supported 43 9%
    sometimes 24 5%
    not at all 36 8%
    What platforms are you targeting with your apps – Android
    focus 147 31%
    must have 183 38%
    supported 85 18%
    sometimes 33 7%
    not at all 31 6%
    What platforms are you targeting with your apps – Blackberry
    focus 5 1%
    must have 11 2%
    supported 83 17%
    sometimes 136 28%
    not at all 244 51%
    What platforms are you targeting with your apps – Web
    focus 306 64%
    must have 121 25%
    supported 26 5%
    sometimes 18 4%
    not at all 8 2%
    What platforms are you targeting with your apps – Windows phone
    focus 8 2%
    must have 36 8%
    supported 112 23%
    sometimes 137 29%
    not at all 186 39%

    Libraries

    jQuery rules supreme but Sencha touch and Zepto also have their place. Interestingly enough a lot of answers discarded libraries completely and considered them an overhead that will cause damage in the future.

    What libraries do you use to build mobile web apps/sites?
    jQuery 349 73%
    jQuery mobile 248 52%
    Zepto.js 90 19%
    JO 5 1%
    XUI.js 18 4%
    Sproutcore 7 1%
    Sencha touch 72 15%
    JQTouch 50 10%
    Mootools mobile 11 2%
    M project 1 0%
    Nimblekit 2 0%
    Lime.js 9 2%
    Wink 1 0%
    Uxebu Bikeshed 1 0%
    Other 126 26%
    People may select more than one checkbox, so percentages may add up to more than 100%.

    Conversion frameworks

    You do love your PhoneGap / Cordova, it seems. There is not too much competition in this market and a lot of feedback was questioning the sense of converting apps as “building them natively makes more sense”.

    Which frameworks do you use to convert apps to native apps?
    PhoneGap 257 90%
    Appcellerator 45 16%
    MoSync 2 1%
    Other 31 11%
    People may select more than one checkbox, so percentages may add up to more than 100%.

    Visual editors

    The space of visual editors seems to be not to frequented with this audience – would be interesting to see if there is already a mass market for WYSIWYG-like tools in the web app space.

    Do you use any visual tools/converters to build apps? If so, which?
    Adobe Edge 14 35%
    Sencha Animator 9 23%
    Other 18 45%
    People may select more than one checkbox, so percentages may add up to more than 100%.

    Webkit only?

    71% of the audience saying they test on other browsers than webkit is making us happy of course, but seeing that a lot of the tools in use are webkit only makes that number questionable. Then again, we didn’t qualify what testing entices in this case.

    Do you test on non-Webkit browsers?
    Yes 340 71%
    No 139 29%

    Reasons to test for webkit only

    The main reason here is a lack of time to test on other platforms which is understandable – we can assume that a lot of projects from a planning perspective have 99% iOS/Android written all over them. The “lack of incentive” number is high, too, which is understandable – if you can’t show the numbers, you don’t get the time to support.

    If no, can you tell us why?
    Fixed environment defined by client needs 36 23%
    Lack of time to support more browser platforms 85 54%
    Lack of incentive – I don’t know what the benefit of supporting more is 65 42%
    Lack of documentation how to install and debug on non-webkit browsers 39 25%
    Bugginess of other browsers on test platforms 24 15%
    Lack of support for other browsers on target hardware 55 35%
    Other 16 10%
    People may select more than one checkbox, so percentages may add up to more than 100%.

    More to come

    These are just the numbers right now. Soon we’ll be publishing also the free-form comments we got but for now this should get some discussion going and gives us a great start.

    And finally – a massive thank you for everybody who participated in this survey!

  3. Weekly HTML5 Apps Developer Resources, July 18th 2012

    Weekly Resources for HTML5 Apps Developers

    Articles

    Resources

    Bonus Link

    If you find a link that you think should be included, please feel free to forward it to JStagner at Mozilla.com

  4. The Web Developer Toolbox: Modernizr

    This is the third in a series of articles dedicated to useful libraries that all web developers should have in their toolbox. The intent is to show you what those libraries can do and help you to use them at their best. This third article is dedicated to the Modernizr library.

    Introduction

    Modernizer is a library originally written by Faruk Ateş.

    It is one of the key libraries for building cross-browser websites or applications in a modern fashion. The heart of the library is the web design pattern known as Progressive enhancement & Graceful degradation. This design pattern does not require Modernizr, but Modernizr can make things a lot easier. It detects the availability of native implementations for next-generation web technologies such as HTML5 or CSS3 and allow you to adapt your application accordingly, which is way better than trying some ugly voodoo user-agent sniffing.

    Basic usage

    Using this library is amazingly simple: Download it, link it to your pages—you’re done!

    Modernizr will automatically add some CSS classes to the root html element. For example if you want to test Web Sockets support, it will add a websockets class to the html element if the browser supports that feature, otherwise it will add the no-websockets class. It will do the same with JavaScript by adding a global variable Modernizr.websocket with a boolean value.

    Let’s see a simple example: Doing some stuff with RGBa colors.

    First: Download a customized version of Modernizr

    Modernizr, download page.

    Second: Link it to your document

    <!DOCTYPE html>
    <!--
    The "no-js" class is here as a fallback.
    If Modernizr is not running, you'll know
    something is wrong and you will be able to act
    accordingly. In contrast, if everything goes well,
    Modernizr will remove that special class.
    -->
    <html class="no-js">
    <head>
        <meta charset="utf-8">
        <title>I want to do stuff with RGBa</title>
        <script src="modernizr.js"></script>
    </head>
    <body>
    ...
    </body>
    </html>

    Third: Use it

    With CSS

    .rgba div {
        /* Do things with CSS for browsers that support RGBa colors */
    }
     
    .no-rgba div {
        /* Do things with CSS for browsers that DO NOT support RGBa colors */
    }

    With JavaScript

    if(Modernizr.rgba) {
        // Do things with JS for browsers that support RGBa colors
    } else {
        // Do things with JS for browsers that DO NOT support RGBa colors
    }

    Let’s see this silly example in action:

    %CODEtoolbox-3-1%

    Advanced usage

    The basic usage is already awesome when you have to deal with a heterogeneous environment (such as mobile browsers for example), but there’s more.

    Conditional loading

    Modernizr offers a convenient way to do conditional loading. Actually, the YepNope library is a standalone spin-off of the Modernizr project. So, if you wish, you can bundled YepNope directly inside Modernizr. It’s perfect if you want to load based polyfills depending on specific browser capacity.

    Modernizr.load({
        test: Modernizr.indexeddb,
        nope: "indexeddb-polyfill.js"
    });

    This is a very powerful tool: do not hesitate to read the documentation. Note that the Modernizr team maintain a list of very accurate polyfills. Feel free to use whatever you need (with caution, of course).

    Custom tests

    Modernizr come with a set of 44 tests for mainstream technologies. If you need to test some other technologies, Modernizr provide an API to build and plug your own tests.

    // Let's test the native JSON support ourselves
    Modernizr.addTest('json', function(){
        return window.JSON
            && window.JSON.parse
            && typeof window.JSON.parse === 'function'
            && window.JSON.stringify
            && typeof window.JSON.stringify === 'function';
    });
    

    Assuming the above test passes, there will be now a json class on the HTML element and Modernizr.json will be true. Otherwise, there will be a no-json class on the HTML element and Modernizr.json will be false.

    Dealing with CSS prefix

    CSS prefixes is a very sensitive subject. Modernizr provides cross-browser code to take care of this issue. Modernizr offers a very useful tool to deal with this: Modernizr.prefixed(). This method works with CSS properties (in the CSS OM camelCase style) as well as with DOM properties.

    For example, Modernizr.prefixed("transition") will return “MozTransition” with Firefox but “WebkitTransition” with Safari and Chrome.

    Testing media-queries

    There is currently no simple way to test a media query from JS in any browser. To help with that, Modernizr has a special tool: Modernizr.mq(). This method will test the media query of your choice and will return true or false accordingly.

    if(Modernizr.mq("screen and (max-width: 400px)")) {
        // Do some stuff for small screens
    }

    Limits and precautions

    This library is a fantastic tool but it’s not magic. You should use it with caution and do not forget about other techniques to deal with unpredictable behaviors. For example, do not forget to rely on the CSS cascade when it’s sufficient.

    The following example is a huge misuse of Modernizr:

    div {
        color : white;
    }
     
    .rgba div {
        background : rgba(0,0,0,.8);
    }
     
    .no-rgba div {
        background : #333;
    }

    If for some reason Modernizr is not executed, your text will not be readable (white text over a white background). In this specific case, you are better doing the following (which, by the way, is also easier to read and maintain):

    div {
        color : white;
        background : #333;
        background : rgba(0,0,0,.8);
    }

    So, don’t be blind when you use this library, take the time to think about what will happen if Modernizr is not available. In many case you have existing fallbacks, don’t forget to use them.

    Conclusion

    Modernizr is the most useful tool when you have to build large cross-browser stuff, from the oldest Internet Explorer 6 to the latest Firefox Nightly. Once you master it, you will be able to add some magic to your sites and applications. However, as with all the powerful tools, it takes some time to become comfortable with and to use it wisely at its full potential. But, Modernizr is definitely worth the effort.

  5. Interview: Jay Salvat, Audio Dev Derby winner

    Jay SalvatJay Salvat won the Audio Dev Derby with Buzz demo, his wonderful children’s game powered by the open web. Using a JavaScript library that he wrote himself, Jay demonstrated that web audio can be not only useful, but also practical and even engaging.

    Recently, I had the opportunity to learn more about Jay: his work, his history, and his thoughts on the future of web development. In our chat, Jay shared insight and advice that should be useful to all web developers, newcomers and veterans alike.

    How did you become interested in web development?

    I am totally self taught. I come from sales and marketing schools. I quickly realized that I was not done for this life. I tried some stuff, first working for free as designer and then as a layout artist in print press and magazines. At the time internet barely existed.

    With the 1997/8 internet big bang, I naturally passed from print design to web design to work in one of the first local web agencies. The agency was sold to a big international company and I then worked on ergonomics and interface designs for key accounts and managed a team of developers on these interfaces.

    Seeing them work gave me the taste of development, so I starting to develop some personal projects. My skills as marketing guy, designer, developer allowed me to get some interesting results by myself.

    Tell us about developing your Buzz demo. Was anything especially exciting, challenging, or rewarding?

    The idea behind the Buzz library was to allow developers to creatively manage sounds on their websites. My fear was to see Buzz used to add sounds on button clicks or some unbearable music background loops. Everything I hate as a user.

    I wanted to be clear and create a demo to show my vision of how sounds should be used on the web in 2012. This educational HTML5 game is inspired by games used by my 5 year old daughter on iPad.

    What makes the web an exciting platform for you?

    What is interesting is being able to quickly test ideas, share them with the world and see them used, improved, distributed and discussed by others. It’s invaluable to get hundreds of comments worldwide. It taught me a lot.

    What up-and-coming web technologies are you most excited about?

    HTML5/CSS3/JavaScript are really exiting and now make everything possible in a browser. I’m really interested by node.js as well allowing full JavaScript client/server side applications.

    If you could change one thing about the web, what would it be?

    Clearly, cross-browser compatibility (I’m looking at you Internet Explorer). It is very frustrating to work a few weeks on ideas, to finally get the desired result and then move to the testing phase on different browsers to see that everything is skewed or unusable. This is what happened to me on the markitup! 2.0 development, which I have never actually found the energy and time to correct.

    I dream to not worry about vendors prefixes, hacks and ridiculous compatibility barriers.

    What advice would you give to aspiring web developers?

    Be curious, be a sharer. Whenever possible do not hesitate to expose your work as open source projects. This is a great challenge to make your code public and have it judged by peers. It’s exciting and rewarding.

    Further reading

  6. Dr.Seuss and Persona – Mozilla at Webvisions Barcelona

    Last week Webvisions, a 3 day conference covering everything UX and web lured a few hundred enthusiasts to the sunny Barcelona. Mozilla sent Crystal Beasley and Chris Heilmann to talk about logging into the web with Persona and the future of the web.

    Crystal gave a workshop on login systems and how to improve them and a talk on 13 signs your UX needs an exorcism.

    Having watched The Lorax on the flight over, and seeing that the audience consisted of a lot of parents we thought it a good idea to write the “Future of HTML5 and the web” talk in the style of Dr. Seuss so people can read to their kids and reflect on what we tried to convey at the same time. Many thanks also to Eric Shepherd for some rhyming help.

    Here are just the rhymes with all the links (also available on GitHub):

    1. There’s a big web out there, 
      it’s huge – I tell you, 
      it spans the whole world
      but it was boring and blue
    2. Then change came about, 
      in the shape of a fox
      it was cunning and open
      and it broke all the locks.
    3. Others showed up,
      and joined the good fight
      a singer, an adventurer
      and a shiny new knight.
    4. These all played together
      and spoke the same tongue
      which brought back old players,
      to join them in song. 
    5. A standard was set, 
      and it changed a few things,
      a richer web for apps
      was the promise it brings.
    6. Bah, standards! Who needs them?
      Some flashy ones said, 
      till a phone that was smart,
      kicked them out of its bed.
    7. We moved past one standard, 
      as web work is richer,
      so HTML5 and friends,
      paints a much better <picture>.
    8. Things that are fun
      should be shiny and cool,
      that’s why the new standards
      bring many a new tool.
    9. Watching and hearing,
      are what people like to do.
      Using <audio> and <video> is simple,
      and you can do it, too.
    10. Both of them are web-native,
      which is a reason to clap.
      They can interact with other content,
      and Mozilla Popcorn makes that a snap.
    11. If beats and frequencies are
      what you need to play,
      check the Web Audio API -
      it gives you just that – even today.
    12. To play nice with batteries,
      use requestAnimationFrame(),
      don’t let it stop you
      that it has such a long name.
    13. 3D graphics are thrilling,
      as gamers will tell,
      we now have that on the web
      and it is called WebGL.
    14. Water goes everywhere you pour it,
      just ask Chris about his Macbook Air :(
      MediaQueries allow you be as fluid
      and respond instead of despair.
    15. Natural movements are smooth,
      just open your eyes.
      With CSS animation, transforms and transition,
      you can mimic this – nice!
    16. “The web means you need to be online”,
      I hear smartypants gloat,
      well, we have offline storage,
      so there – take your coat.
    17. Got a cam and some friends,
      and do you want to chat?
      WebRTC is what you need,
      even to show off your cat.
    18. Rhymes sometimes don’t come easy,
      as you just became aware.
      So let’s just move ahead quickly,
      this was just too much to bear.
    19. An artist needs a <canvas>,
      and HTML5 gave us that.
      Read, write and convert pixels,
      All in the client, it’s mad!
    20. “We don’t have rich elements!”
      many people complain,
      Use Web Components with X-Tag
      and create them – easy to maintain.
    21. Passwords are tough, 
      it is easy to see, 
      so allow login with emails,
      using BrowserID.
    22. The web is a mess,
      with third party buttons abound.
      Web Intents make them pointless,
      let’s not have them around.
    23. By design HTML5 is forgiving,
      its parser is great.
      It didn’t want to break the web,
      so let’s not break it in its stead.
    24. Course you can write weird things,
      and they will work – there’s no doubt.
      But will they be readable by others?
      This is what it’s about.
    25. You don’t create for yourself,
      or your friends who are the same.
      You develop for the next guy,
      so make sure you’re not to blame.
    26. You don’t jump in a river,
      if you don’t know its depth.
      On the web using Modernizr,
      should be your first step.
    27. Give new stuff to new players,
      and use it to enhance.
      Don’t support when it’s not needed
      IE6 walks – it can’t dance!
    28. With a vendor prefix browsers tell you
      “this is not ready”.
      So by all means, give them a go,
      but don’t expect to go steady
    29. And those prefixes vanish,
      you mustn’t forget!
      End with a prefixless version,
      It’s your very best bet.
    30. So we ask you to help us,
      build a web that will last.
      Be future friendly and look forward,
      and stop building for the past.
    31. rong>The web is on phones,
      tablets, computers, TVs.
      We have to move it forward.
      or else our existence will cease.
    32. Hardware that is locked up,
      is not what we are about,
      so check out Firefox OS,
      if you like the web – you will like it – no doubt.
    33. Last but not least,
      if you find something’s wrong
      please file a bug and tell us,
      this is how things get done.
    34. So there you have a lot to play with,
      check out and share.
      We really want you to do that,
      come on, show us you care.
    35. Unless someone like you
      cares a whole awful lot,
      nothing is going to get better.
      It’s not.
    36. So well done for reading and listening,
      and going great lengths,
      that’s all we got time for today,
      so good-bye and thanks!

    Encountering a lot of hardware problems we couldn’t do a recording of the talk so I made a screencast of the presentation available on YouTube.

    Alternatively, you can also have a video version with just the rhymes

    Other formats for you to download and use:

    The audience reaction was very positive and we found out that when you rhyme your talk it flows much faster. The 45 minute slot was 20 minutes of our talk and another 25 minutes explaining in detail what we covered in a Q&A.

    All in all Webvisions was a great event and watch out for videos of the other talks being available soon and other slides on the web.

  7. Weekly HTML5 Apps Developer Resources, July 11th 2012

    Weekly Resources for HTML5 Apps Developers

    Articles

    Resources

    Bonus Link

    If you find a link that you think should be included, please feel free to forward it to JStagner at Mozilla.com

  8. Weekly HTML5 Apps Developer Resources, June 20th 2012

    Weekly Resources for HTML5 Apps Developers

    Articles

    Resources

    Bonus Link

    If you find a link that you think should be included, please feel free to forward it to JStagner at Mozilla.com