Mozilla

Web Developers Articles

Sort by:

View:

  1. Launching Open Web Apps feedback channels – help us make the web better!

    About three months ago we launched a feedback channel for the Firefox Developer Tools, and since it was a great success, we’re happy announce a new one for Open Web Apps!

    For Developer Tools, we have, and keep on getting, excellent suggestions at http://mzl.la/devtools, which has lead to features coming from ideas there being implemented in both Firefox 32 & 33 – the first ideas shipped in Firefox only 6 weeks after we launched the feedback channels!

    Your feedback as developers is crucial to building better products and a better web, so we want to take this one step further.

    A channel for Open Web Apps

    We have now just opened another feedback channel on UserVoice about Open Web Apps, available at http://mzl.la/openwebapps

    It is a place for constructive feedback around Open Web Apps with ideas and feature suggestions for how to make them more powerful and a first-class citizen on all platforms; desktop, mobile and more.

    What we cover in the feedback channel is collecting all your ideas and also updating you on the different areas we are working on. In many cases these features are non-standard, yet: we are striving to standardize Apps, APIs, and features through the W3C/WHATWG – so expect these features to change as they are transitioned to become part of the Web platform.

    If you want to learn more about the current state, there’s lots of documentation for Open Web Apps and WebAPIs on MDN.

    Contributing is very easy!

    If you have an idea for how you believe Open Web Apps should work, simply just go to the feedback channel, enter a name and an e-mail address (no need to create an account!) and you’re good to go!

    In addition to that, you have 10 votes assigned which you can use to vote for other existing ideas there.

    Just make sure that you have an idea that is constructive and with a limited scope, so it’s actionable; i.e. if you have a list of 10 things you are missing, enter them as a separate ideas so we can follow up on them individually.

    We don’t want to hear “the web sucks” – we want you to let us know how you believe it should be to be amazing.

    What do you want the web to be like?

    With all the discussions about web vs. native, developers choosing iOS, Android or the web as their main target, PhoneGap as the enabler and much more:

    Let us, and other companies building for the web, know what the web needs to be your primary developer choice. We want the web to be accessible and fantastic on all platforms, by all providers.

    Share your ideas and help us shape the future of the web!

  2. Introducing webcompat.com

    For the past few months a small group of contributors inside and outside of Mozilla have been working on webcompat.com. We just recently celebrated moving past the “too broken to share” milestone to the “functional-under-construction.gif” milestone of the project and are eager to share what we’ve been up to.

    There’s a more elaborate description of web compatibility and the site over at http://webcompat.com/about, but the basic premise of this project is: what if you could “file a bug on the internet” in a public space where developers, users and browser vendors could be made aware of compatibility issues?

    You can report issues to browser vendors today, through bug trackers or other feedback mechanisms, some public and some not. But frequently you cannot see the results of such a report—or see what related issues others have reported. It can feel like a black hole experience.

    This is where webcompat.com comes in. We want to provide a simple, open interface to web compatibility issues that affect us all as users of the web, regardless of our browsers or devices of choice. Perhaps more importantly, we hope to foster and enable a community of people who are passionate about a web for everyone to help out.

    So is this a Mozilla-only effort?

    Not at all. Mozilla kindly allows me to work on this project as a part of my full-time responsibilities on the Mozilla Mobile Web Compatibility team—but the project’s goal has always been to create an open resource for all people who use and build things on the internet. We’ve had some positive conversations with some of our browser vendor colleagues that have motivated us to start initial plans around future collaborations. It’s clear to us that Mozilla isn’t the only entity invested in a compatible web.

    OK Neat. What can I do?

    There’s actually quite a bit to do if this type of work is interesting to you.

    Reporting Issues

    Do you happen to notice sites that block you, nag you to install a different browser, or are just plain broken or buggy? Instead of just tweeting sad emoticons or #fail hashtags, you can help make a difference by creating a record of these issues with the form at webcompat.com.

    We’ve also created some browser extensions to make reporting easier—just click the added UI button to open a new tab with some bug report info pre-filled for you. You can grab that for Firefox Desktop, Firefox for Android, Chrome, Opera, and Safari. There’s also a bookmarklet you can install in your bookmark or favorites bar. These are all open source, so feel free to hack away and port them to new platforms.

    Diagnosing Compatibility Issues

    Do you have a knack for figuring out why things are broken and want to hone your internet CSI skills? Have you considered getting a “TypeError: ‘undefined’ is not a function” tattoo? Do you love reading minified code and debugging the entire web stack? We could use your help confirming and diagnosing issues (tattoos not required).

    Site Outreach

    Are you more interested in doing outreach and making sites and developers aware of issues? We need your help too. Stay tuned for better tooling around this role—or hop into the #webcompat irc channel on the Mozilla IRC network and say hi.

    Development

    Do you know or want to get better at JavaScript, Python, CSS, UX, design, GitHub, browser extensions, testing, and more? We’ve got a pile of issues we’re working on over at GitHub and welcome patches, opinions, issues, and feedback.

    What’s coming next?

    Right now two of our biggest priorities are being able to view and interact with issues in the site itself, and creating tools that will enable importing existing web compatibility issues from bug trackers (both open and closed) and exporting compatibility issues on webcompat.com to browser vendors (when the bug lies with the browser, not the site).

    Our project is still in its infancy, but we look forward to your compatibility bug reports and comments!

  3. Take the Developer Economics 7th Global Survey

    I’ve always preferred to think of myself as anything but a Marketer. In business school, there was a clear hierarchy assigned to the functional classifications amongst us. At the very top sat the investment bankers, commanding the most respect and highest paying job offers. And always at the very bottom the Marketing folks groveled, earning less and often viewed by their peers as having a “softer,” less competitive skillset.

    However much I disagreed with this classification — knowing that the digital age has made modern day marketing every bit as analytical and numbers-intensive as corporate financing jobs — it didn’t change the fact that I didn’t want to be called a Marketing person anyway. With the success of the Mad Men series and the constant headlines about privacy invasion and digital media, it seemed impossible to completely shake the Marketing job function from the stereotype of scumbag executives on Madison Avenue, or even a dirty car salesman whose only real skill is the ability to smoothly tell lies.

    In corporate America, no matter what job function you’re in, you’re all there for the same purpose – to drive profits (also referred to by business-schoolers as “maximizing shareholder value”). But the Marketing folks are more directly involved with sales metrics, and so the stereotypes live on. But being a Marketer at Mozilla is different. As a non-profit, mission oriented company, we’re not trying to sell you anything at all. Our only goal is to provide greater value – to our developers, our users, our community, and the world.

    As a Developer (un)Marketer, my job is to make you successful. Does this mean I’m never going to try to get you to do anything? Or could this mean I’m ready to be embrace the Marketing title? Okay, no on both counts. But it does mean that when I ask you to do something, I’m really asking just so I can, in the end, help you.

    Take the Survey

    Surprise – the Marketer that won’t call herself a Marketer writes her first blog post asking you to do something. Mozilla has teamed up with research company VisionMobile to get the latest, most accurate facts and insights surrounding the mobile app economy and developer ecosystem. We need this to make sure we’re prioritizing our efforts to provide you with the tools and resources that help you the most. The research relies heavily on developer surveys, and we want to ensure we get a representative sample of Firefox OS and HTML5 developers around the world. We also need this sample to be large enough to for the data to be statistically significant.

    If you’re an HTML5 or Firefox OS developer, we’d love you to participate in this 10-minute survey for their research report on Developer Economics. This report provides a comprehensive analysis of the app economy and developer ecosystems based on the largest and most global developer surveys. The results of the survey will be available as a free download in July, plus I’ll be back to talk about some of the best challenges and opportunities for developers based on insights from the full report.

    The survey will run until May 9th, and there is also a lucky draw for survey respondents to win prizes! Please help us generate the best research possible with your participation. And please comment or tweet us (@mozhacks) with any thoughts or ideas on the survey questions!

    Survey Methodology

    The research in VisionMobile’s Developer Economics report is based on survey responses from its global developer survey, in addition to one-to-one interviews with mobile app developers. The developer survey is entirely administered online. Respondents for the 5th edition of Developer Economics came from 115+ different countries, led by the US (18.7%), India (13.9%), and the UK (5.9%), followed by Russia, Germany, and France. This is outlined in more detail in Developer Economics: Methodology.

    About the Survey

    Developer Economics is a semi-annual report series published by VisonMobile, providing benchmarking of developer attitudes, trends and monetization by region. The report is now the largest and most global research available on the apps economy, surveying over 6.000 developers worldwide. You can also download a free copy of the 5th Edition (Q3 2013) of the report.

    About VisionMobile

    A leading research firm in the app economy and mobile business models, VisionMobile’s team includes PhDs, MBAs, economists and engineers that analyze the strategies behind the world’s most successful technology companies. Visit their website to learn more.

  4. What Mozilla Hacks is

    With the Mozilla moniker, many people believe that the Hacks blog is only about Mozilla products or news. Therefore, I wanted to take the chance to enlighten you and also invite you to be a part of creating content here.

    What we cover here

    The goal and objective of Mozilla Hacks is to be one of the key resources for people developing for the Open Web; talking about both news and in-depth descriptions of technologies and features. This means that as long as it’s about open technologies, we want to share all that information, tips, tricks and learnings with you.

    We’re Mozilla, and for us it is key to be a web browser agnostic resource, and it’s exactly the same with MDN (Mozilla Developer Network). The content here is written by a lot of different authors, where about half of them aren’t part of or associated with Mozilla in any way – they just do good things for the Open Web, and we believe that deserves exposure, and that it will be beneficial to you.

    Allow me to also emphasize that Mozilla Hacks is not a press release channel, we work hard to make everything we cover to be informational, practical and inspirational for you.

    More information is outlined in the guidelines for Mozilla Hacks.

    Behavior

    Mozilla Hacks is a place based on mutual respect and understanding, and the way we address each other is supposed to reflect that. We expect anyone writing or commenting to use proper language and refrain from insulting other people. If you ask a question here, give feedback and more, you deserve a reply from us. And when we talk about things – even though we might disagree – we all should and are entitled to always be met with respect and a proper behavior.

    Write for us!

    We know that a lot of you reading this have great knowledge, skill sets and experiences, and we would be very happy to help and support you in sharing it with the world and fellow developers.

    We have had hundreds of people writing and collaborating in content for Hacks, and if you write two posts or more, you’ll show up in great company among all our fantastic authors!

    Talk to me

    For me personally, I’ve been running Mozilla Hacks as its Editor for about two years now, and I’m constantly on the lookout for good content that web developers writing for the Open Web, with open technologies, can learn from. I.e. topics that I’d love to read about myself.

    I would be very happy for you to reach out to me at robert [at] mozilla [dot] com or via @robertnyman on Twitter – I’m always interested in discussing the web, technology and the ideas you might have. Talk to me. :-)

  5. Building a persistent Notes app for Firefox OS

    In this tutorial we will be building a notes app (like Evernote) from scratch and deploy it to Firefox OS! See a live demo.

    A persistent notes app needs a place to store all the notes for a user (so no one else can read it). For this we will use my own backend solution called Sproute. Sproute is a hosted web framework for quickly building dynamic webapps.

    First create an account with a unique subdomain then access the Dashboard through http://<mysubdomain>.sproute.io/admin. You must login with the same details used to signup to Sprotue.

    Models

    In Sproute there is a concept called Models. A model defines the dynamic data in our app with properties for data integrity. Create a new model called notes with the following fields and properties:

    • body: Text, Required, Min: 1
    • sharing: Text, Allowed Values: public, private, Default Value: private
    The model form filled out for notes

    The model form filled out for notes

    The body field will store the contents of the note. The sharing field will specify whether the note can be viewed by others (with a direct link) or just the owner. This is all the data we need to define, everything else is covered by built-in fields.

    List notes

    We need a way to list the available notes for a user. This can be done with Pages. A page is HTML with embedded template tags for retrieving and processing data.

    Open the index page. This is the home page when people view your space. We will list the notes here. Add the following:

    {{ get /data/notes?sort=_lastUpdated,desc as notes }}

    All data is retrieved through an HTTP interface so the {{ get }} tag must take a URL. The request above is retrieving all notes for the logged in user and stores the results in a variable called notes. We use a query parameter to sort the results by last modified first (An underscore denotes a built-in field).

    Let’s display each note in a list:

    <ul>
        {{ each notes as note }}
            <li><a href="/view/{{note._id}}">
            {{ word note.body 0 5 }}
            </a></li>
        {{ / }}
    </ul>

    The {{ word }} template tag will extract the first 5 words from the body content. We link to a not-yet-made page with the URL /view/<id>. note._id is a built-in unique identifier.

    Add the above code in the 'index' page

    Add the above code in the ‘index’ page

    Create a note

    Before creating the view page for a note, let’s make a new page for creating a note. Create a new page called create. Add the following HTML:

    <form action="/data/notes?goto=/" method="post">
        <div><textarea name="body"></textarea></div>
        <div><select name="sharing">
            <option value="private">Private</option>
            <option value="public">Public</option>
        </select></div>
        <button type="submit">Create Note</button>
    </form>

    Simple! As mentioned above, all data is retrieved and modified through an HTTP interface. This means we can use a simple HTML form to create a new note. The goto query parameter will redirect the user to that URL.

    Because this is a new page we need to create a new route so the page is accessible. A route is a pattern for a requested URL that will render a page if matched. There will already be a route for the index page. Click Routes and create a new one with the following:

    • Route: /create, Page: create.
    New route to 'create' page

    New route to ‘create’ page

    User login and registration

    User accounts are built into Sproute but we still need to create a Register and Login page. Thankfully this is also a simple HTML form so create a new page called users and add the following:

    <h2>Login</h2>
    <form action="/api/login?goto=/" method="post">
        <label>
            <div>Username:</div>
            <input type="text" name="name" />
        </label>
        <label>
            <div>Password:</div>
            <input type="password" name="pass" />
        </label>
        <button type="submit">Login</button>
    </form>

    You may add the Register form on the same page by copying the login form and replace the action attribute to /api/register. Create two new routes with the following:

    • Route: /login, Page: users
    • Route: /register, Page: users

    View and update a note

    Previously we created a link to view a note. This will also be where we let users modify the note. Create a new page called view and add the following:

    {{ get /data/notes/_id/:params.id?single=true admin as note }}
     
    {{ if note.sharing eq private }}
        {{ if note._creator neq :session.user._id }}
            {{ error This note is private }}
        {{ / }}
    {{ / }}
     
    <form action="/data/notes/_id/{{params.id}}?goto=/" method="post">
        <div><textarea name="body">{{note.body}}</textarea></div>
        <div><select name="sharing">
           <option value="private" selected>Private</option>
           <option value="public">Public</option>
        </select></div>
        <button type="submit">Update Note</button>
    </form>

    We make a request to get the note data for the note that was passed into the URL (through the params object). The query parameter single=true will return just the object instead of a one item collection. admin will run the request with the specified user-type. Next we check whether the note is private. If so throw an error if the user is not the creator.

    The update form is very similar to the create form. We only need to change the action to update notes where the _id matches the one in the URL.

    This page requires a slightly complex route. We need to use a placeholder in the route so that /view/anything will still match the view page and store anything in a variable.

    Create a route with the following:

    • Route: /view/:id, Page: view

    Now you can see where params.id comes from. params is an object for all placeholders in the route and the matched values.

    Permissions

    The last important concept of Sproute is permissions. Permissions are just like routes where a requested URL matches a pattern but instead of pointing to a page, it validates against a required user type.

    Click Permissions and add the following:

    • Method: GET, Route: /data/notes, User: Owner
    • Method: GET, Route: /data/notes/*, User: Owner

    This will make sure the only notes listed will be ones the user has created (i.e. the owner). Because of the second permission, we needed to run the {{ get }} request as admin otherwise it would fail for everyone (except for admins and the creator) even if the note is public.

    Adding a permission to retrieving notes

    Adding a permission to retrieving notes

    Firefox OS support

    Sproute can very easily support hosted apps on Firefox OS by creating a page with the manifest JSON data and the route: /manifest.webapp.

    Create a new page called manifest with the following:

    {
        "name": "{{self.name}}",
        "description": "A persistent notes app",
        "launch_path": "/",
        "icons": {
            "128": "/absolute/path/to/icon"
        }
    }

    Create a Route with the pattern /manifest.webapp pointing to the manifest page.

    We’re done! Test this in the app manager by using the link to the manifest (http://notes.sproute.io/manifest.webapp). Sproute is open-source and on GitHub under the Mozilla Public License v2 so you may clone the repo for private hosting.

    Notes app at mobile width

    Notes app at mobile width

  6. Introducing the Firefox OS App Manager

    The Firefox OS App Manager is a new developer tool available in Firefox 26 that greatly improves the process of building and debugging Firefox OS apps, either in the Simulator or on a connected device. Based on the the Firefox OS Simulator add-on, it bridges the gap between existing Firefox Developer tools and the Firefox OS Simulator, allowing developers to fully debug and deploy their web apps to Firefox OS with ease.

    AppManager

    Additional features made available in Firefox 26 are discussed in this post.

    App Manager In Action

    The App Manager replaces the current Simulator Dashboard and provides an integrated debug and deployment environment for your Firefox OS apps, by leveraging the existing Firefox Developer Tools. You can install hosted or packaged apps and debug them in the Simulator or with a connected device. The App Manager also provides additional information to the developer including the current Firefox OS version of a connected device, the ability to take screenshots, a list of all currently installed apps and a list of all the APIs and what privilege level is required to use each. Here is a screencast of the App Manager showing off some of the features available for Firefox OS Development.

    In addition to debugging your own apps, the App Manager also provides the ability to update, start, stop and debug system level apps. Debugging an app using the Developer Tools is similar to debugging any other Web app and changes made in the Tools are automatically reflected real-time to the app either in the Simulator or the connected device. You can use the Console to see warnings and errors within the app, the Inspector to view and modify the currently loaded HTML and CSS, or debug your JavaScript using the Debugger.

    Developer Tools

    For more information about using the Developer Tools be sure to check out the Developer Tools series on this blog and for the most up to date information take a look at the Developer Tools section of MDN.

    Getting Started with the App Manager

    To get started using the App Manager take a look at the MDN Documentation on Using the The App Manager. Do keep in mind that to see what is shown above you need:

    • Firefox 26 or later
    • Firefox OS 1.2 or later
    • at least the 1.2 version of the Firefox OS Simulator
    • either the ADB SDK or the ADB Helper Add-on

    Details for these are described in the above MDN link.

    Mozilla is very interested in your feedback as that is the best way to make useful tools, so please be sure to reach out to us through Bugzilla or in the comments and let us know what you think about the new App Manager.

  7. Firefox OS Development: Web Components and Mozilla Brick

    In this edition of “Firefox OS: The platform HTML5 deserves” (the previous six videos are published here), Mozilla’s Principal Evangelist Chris Heilmann (@codepo8) grilled Mozilla’s “Senior HTML5 Engineer Angle Bracket Coordinator” Matthew Claypotch (@potch) about the exciting new possibilities of Web Components for Web App developers and how Mozilla’s Brick library, a collection of custom elements to build applications with, can help with the transition. You can watch the interview on YouTube.

    The Why of Web components

    There is a problem with the Web as a platform for applications: HTML, the language that makes it easy to mark up documents and give them meaning doesn’t have enough elements to build applications. There are quite a few new elements in the HTML5 spec, but their support is sketchy across browsers and there are still a lot of widgets missing that other platforms like Flex or iOS give developers out-of-the-box. As a result, developers build their own “widgets” like menu bars, slider controls and calendars using non-semantic HTML (mostly DIV elements) and make them interactive using JavaScript and theme-able using CSS.

    This is a great workaround but the issue is that we add on top of the functionality of browsers instead of extending the way they already function. In other words, a browser needs to display HTML and does a great job doing that at least 60 frames per second. We then add our own widget functionality on top of that and animate and change the display without notifying the browser. We constantly juggle the performance of the browser and our own code on top of it. This leads to laggy interfaces, battery drain and flickering.

    To work around that problem a few companies and standards body members are working on the Web Components specification which allows developers to extend the browser’s understanding of markup with own elements. Instead of writing a slider control and make it work after the browser already displayed the document, you define a slider element and become part of the normal display flow. This means our widgets get more responsive, don’t work against the browser’s rendering flow and all in all perform better. Especially on low spec mobile devices this is a massive win. The whole thing already happens: if you for example add a video element to the document you see a video controller with a timed slider bar, a play button and volume controls. All of these are HTML, CSS and JavaScript and you can even see them in the debugging tools:

    Anatomy of a video element

    Firefox OS, being targeted at low end devices can benefit a lot from widgets that are part of the rendering flow, which is why Mozilla created Mozilla Brick, a collection of custom elements to build applications with. Earlier we introduced the concept using a library called XTags, which powers Brick. Using Brick, it is very simple to create for example a deck based application layout using the following markup:

    <x-deck selected-index="0">
      <x-card>
        0<span>I'm the first card!</span>
      </x-card>
      <x-card>
        1
        <span>
          These cards can contain any markup!<br>
          <img src="../../site/img/grounds_keeping_it_real_s3.gif">
          <img src="../../site/img/grounds_keeping_it_real_s1.gif">
          <img src="../../site/img/grounds_keeping_it_real_s2.gif">
        </span>
      </x-card>
      <x-card>
        2 <img src="../../site/img/thumbs_up.gif">
      </x-card>
    </x-deck>

    The resulting app consists of three decks that can be animated into another without having to do anything but call a deck.shuffleNext(); function.

    Web Components are a huge topic right now and many libraries and frameworks appear each week. We hope that by using Brick we can enable developers to build very responsive apps for Firefox OS quickly and cleanly and leave the pain of making your app perform really well up to the OS.

  8. Mozilla goes to Washington

    Last month, Mozilla Foundation employee Jess Klein was honored by the White House Office of Science & Technology Policy as a Champion of Change for her work with Rockaway Help in the wake of Hurricane Sandy.

    Before the White House event, Mozilla sponsored a Civic Hackers’ Happy Hour in DC at canvas.co. Here’s an excerpt about the event from the Code for Tulsa write-up.


    Mozilla Civic Hackers’ Happy Hour

    We arrived at canvas around noon to arrange all the catering and set everything up. We met fellow civic hackers from Austin to Chicago, Minneapolis to Miami, Oakland to DC, and everywhere in between – hackers and officials representing Code for America, Sunlight Foundation, E-Democracy, United States CTO, Census Bureau, NASA, FEMA, USDA and many others.

    By 8pm we had about 100 people, so we had a few quick presentations – I spoke about Mozilla, Kevin Curry spoke about the Code for America Brigade program, and Garret Miller spoke about Mapbox. Everyone mingled and we learned about some great civic projects going on like the Smart Chicago Collaborative, mspbus.org in Minneapolis, and Keep Austin Fed. We had made a congratulatory card for Jennifer Pahlka, founder of Code for America and recently-appointed Deputy CTO of the US. Everyone had a chance to sign the card, and then… Jennifer showed up! So we presented the card to her in person!


    In my presentation about Mozilla, I discussed how I’ve come to realize that openness, innovation, and opportunity on the web is at the heart of developers improving their communities.

    Cities that think like the web

    In 2011, I found Mozilla Foundation Executive Director Mark Surman’s City of Toronto 2.0 Web Summit presentation from 2008 – A city that thinks like the web.

    Mark tells the story that seems obvious to us now – Mozilla believed that participation could create a better internet, and the tiny non-profit with a global community of volunteers forced open a monopoly browser market with standards and protocols that have created the largest communication platform in the history of the world.

    If openness and participation created a better web, could it create better cities? Mark says yes. After a couple of years hacking my city, I completely agree.

    Tulsa, Oklahoma, USA

    I first started civic hacking in 2011 when our Tulsa Web Devs group took it upon ourselves to put Tulsa Transit on Google Maps. At the time, we knew nothing about transit, and only a little about Google Maps. In a few short hack days with web resources, we taught ourselves everything we needed to convert route shapefiles and schedule csv files into a valid GTFS feed.

    Tulsa Transit GTFS Prototype

    As soon as I saw the prototype working, I was hooked on civic hacking. It was the same feeling I had when I received my first patch for my first open-source project. In a way, my personal journey – from proprietary enterprise software development, to SourceForge, to Mozilla and Code for Tulsa – reflects trends in open technology: open source disrupted proprietary software and brought forth the open web, the open web brought forth open government and civic hacking.

    In Tulsa, we’ve gone on to create civic APIs and apps for citizens, planning organizations, Tulsa Library, Tulsa Fire Department, and the Oklahoma Urban Search & Rescue task forces. Because we build on the web, all our apps are available to every citizen, regardless of device or platform. I jokingly ask, “If we created our Fire Department app for iPhones, would Android users just watch their house burn down?”

    Innovation can come from anywhere

    Here’s the thing – we are just one group (but maybe the best group!) of civic hackers … in Tulsa, Oklahoma. The web enables anyone with a text editor to make these things and deliver them directly to anyone with a web browser. Morgamic says it best in “What do you want the web to be?

    The future of the web won’t be decided by corporations, governments, or shareholders. It will be chosen by people like you and me – passionate individuals with great ideas, who won’t take no for an answer, who won’t settle.

    Having worked with and for corporations, shareholders, and now governments, I know just how true this statement is. On the web, Google’s latest billion-dollar project and Code for Tulsa’s $35 raspberry pi hack are both a single link – a single click. The web platform is the only platform designed to include everyone at an equal level of access.

    Serving the greater good

    Mozilla’s mission is to promote openness, innovation, and opportunity on the web. It’s a lofty goal; sometimes it’s hard to see what that looks like “on the ground.” At our happy hour, I saw it: designers, engineers, programmers, entrepreneurs – hackers experimenting and making amazing things for the betterment of their communities.

  9. New Features in Firefox Developer Tools: Episode 24

    Releases have recently rolled, and there are a slew of new features coming to the developer tools in Firefox 24. Firefox 24 is currently in our alpha channel Firefox Aurora, and will hit the main release channel on September 17th, 2013.

    A little alitteration leads to lots of cool features coming this release. I’m only touching on a few highlights here; to see a comprehensive list of all the new changes to developer tools, check out the full list of bugs fixed since last release.

    Console Clean Ups

    An oft-requested feature, the console will now clear all of the existing logs when you refresh the page. If you need logs to persist across reloads, don’t worry: this behavior is toggle-able in the options panel. Here’s to less clutter!

    Users were also reporting that the “clear” button was confusing. It wasn’t obvious whether it was clearing the logs or the the filter text because the button as adjacent to the filtering search box. We moved it to so that this won’t happen anymore!

    New position of the clear button

    Source Map Sourcery

    Source maps are now enabled by default. If you need to debug the JavaScript generated by your tool or compiler rather than the original source, you can still toggle them on and off in the debugger options.

    Furthermore, because of issues with Internet Explorer, the source map specification was updated so that you link a source map to its script with //#
    sourceMappingURL=...
    rather than the deprecated //@ sourceMappingURL=.... We will still respect the old style, but will warn you that it is deprecated. Here is a summary of the why this change was made.

    Finally, we will load the text of a source mapped source from its source map’s sourcesContent property, if it exists. This property was added to source maps to enable dynamic source map creation, and to bundle your sources into the source map so that you don’t need to juggle extra files on your server.

    Debugger Developments

    Frozen, sealed, and non-extensible objects are now visually distinguished in the debugger’s variables view.

    Frozen, sealed, and non-extensible objects

    Also, when stepping out of a stack frame in the debugger, you will now see either the return value or the exception thrown (depending on why you are exiting the frame) in the variables view labeled <return> and <exception> respectively.

    A stack frame's return value

    A stack frame's exception

    JavaScript-Free Fun

    Need to see how your web page gracefully degrades when JavaScript is disabled? Head on over to the options panel and you can quickly disable JavaScript for the current tab. This persists until either you close the tab or the developer tools.

    Network Monitor Magic

    You can now filter by types of requests in the network monitor. Want to see only requests for stylesheets? Or maybe only XHRs? We’ve got your back. On top of that, there are now total number of requests, file sizes, and response times listed in the bottom that update with you filters, so you can see just how many KBs (or even MBs) of images you are requesting on every page load.

    Filtering only images

    Profiler Pleasantries

    You can now control the profiler from your web app’s code base via console.profile() to start a new profile, and console.profileEnd() to end it. No more trimming your sample range, start and stop profiling in the exact places you want to from your code!

    That’s it for this episode. Keep on hacking the free web!

  10. Speed Up App Development with X-Tag and Web Components

    In the last few years we’ve witnessed an evolution in what ‘app’ means to both developers and consumers. The word app evokes the idea of a rich, task-oriented user experience with highly optimized user interface that responds to its environment and can be used on an array of common devices. In order to make development of rich app experiences easier, native platforms have generated many of their own controls and components that Just Work™.

    For other native technology stacks, extensible components are all but assumed – not so much for the web. Soon, that all changes. We are on the verge of a declarative renaissance that will dramatically advance app development for the web platform, and Web Components will drive it.

    X-Tag and Web Components offer features that obliterate the status quo for layout, UI, and widget development – here’s a few notable Web Component features:

    • Create real custom elements the browser understands
    • Stop the instantiation madness: $$(‘button.super’).initSuperButton()
    • Remove unmanageable HTML widget guts from your app’s view files
    • Work with sharable components, based on standard technologies

    Meet the Web Components Family

    Web Components is a group of W3C specifications, quickly moving toward standardization, that provide a robust HTML component model. You should not assume the following specs are implemented in your browser of choice. While these specifications are in various stages of implementation across browsers, you can use X-Tag (with either Mozilla or Google’s prollyfill) today to create custom elements that work well in recent version of Firefox, Chrome, Safari, and stock mobile browsers. X-Tag is a powerful sugar library primarily focused on wrapping and enhancing one of the draft-state Web Component specs: Custom Elements (document.register). We’ll get to X-Tag shortly – but for now, let’s quickly review the key features of each spec:

    Custom Elements

    Custom Elements provides you a way to create new elements for use in your environment. There are two ways to declare a new custom element, the imperative DOM API – document.register(), and the declarative HTML tag – (whose DOM constructor is HTMLElementElement). After declaration, new custom elements can be created in the same ways native elements are, such as document.createElement, presences in original source (the markup of a page), and innerHTML, etc.

    Here’s an example of what a custom element registration looks like in both the declarative and imperative styles:

    document.register('x-foo', {
      prototype: Object.create(HTMLElement.prototype, {
        readyCallback: { 
          value: function(){
            // do stuff here when your element is created
            this.innerHTML = '<div>Barrrr me matey!</div>';
          }        
        },
        bar: {
          get: function() { return 'bar'; },
        },
        // add more properties to your custom prototype
        // ...
      })
    });
    <element name="x-foo">
      <script>
        if (this !== window) {
          this.register({
            prototype: {
              readyCallback: { 
                value: function(){
                  // do stuff here when your element is created
                  this.innerHTML = '<div>Barrrr me matey!</div>';
                }        
              },
              bar: {
                get: function() { return 'bar'; },
              }
            }
          });
        }
      </script>
    </element>

    Shadow DOM

    The Shadow DOM allows you to encapsulate structural and supporting elements within components. Elements within nodes remain visible for purposes of display UI (depending on the type of element and your styles), but are hidden from the rest of your application code, unless you explicitly cross the shadow boundary.

    HTML Templates

    HTML Templates bring simple DOM templating and markup reuse to the web platform – which are often shimmed today using the HTMLScriptElement + DocumentFragment hack-pattern.

    HTML Imports

    HTML Imports are external HTML documents that contain declarative component definitions. HTML component documents can by imported using the link element with the rel attribute value import. Imported resources may themselves contain additional sub-imports, which the browser then retrieves and performs automatic dependency resolution upon.

    Web Components + X-Tag = WINNING

    Mozilla’s X-Tag library enhances the imperative (JavaScript) route for creating custom elements. X-Tag’s primary interface is the xtag.register() method – it wraps the soon-to-be standard document.register() DOM API with features and functionality that make development of amazing custom elements effortless.

    Creating a Custom Element

    Here’s a quick example of what registering a custom element looks like using X-Tag:

    xtag.register('x-pirate', {
      lifecycle: {
        ready: function(){
          this.innerHTML = '<blockquote>' +
                             '<img src="pirate-1.png"/>Barrr me matey!' +
                           '</blockquote>';
        }
      },
      accessors: {
        src: {
          // X-Tag's attribute sugar relays any value passed to the src 
          // setter on to the src attribute of our <x-pirate> and its
          // <img> element (specified by CSS selector), and vice versa.
          attribute: { selector: 'img' },
          set: function(){
            // When a <x-pirate>'s src attribute/setter is changed, we 
            // stop everything to announce the arrival of a new pirate.
            // Ex: doc.querySelector('x-pirate').src = 'pirate-2.png';
            alert("There's a new captain on deck ye scurvy dogs!");
          }
        }
      },
      events: {
        // This is an example of X-Tag's event and pseudo systems. The
        // "tap" custom event handles the dance between click and touch,
        // the ":delegate(img)" pseudo ensures our function is only 
        // called when tapping the <img> inside our <x-pirate>.
        'tap:delegate(blockquote > img)': function(){
          alert("A pirate's life for me!");
        }
      }
    });

    To the Democave Batman!

    We’re actively working on a custom element UI toolkit and style pack that will make development of app interfaces a breeze. It’s still in very early stages, but we have a few demos for you.

    Get the Code

    Head over to X-Tags.org and grab the code to develop custom elements of your own. After you get the hang of things, start contributing to our open source effort!