Planet MozillaWant to be selected for Google Summer of Code 2016?

I've mentored a number of students in 2013, 2014 and 2015 for Debian and Ganglia and most of the companies I've worked with have run internships and graduate programs from time to time. GSoC 2015 has just finished and with all the excitement, many students are already asking what they can do to prepare and be selected for Outreachy or GSoC in 2016.

My own observation is that the more time the organization has to get to know the student, the more confident they can be selecting that student. Furthermore, the more time that the student has spent getting to know the free software community, the more easily they can complete GSoC.

Here I present a list of things that students can do to maximize their chance of selection and career opportunities at the same time. These tips are useful for people applying for GSoC itself and related programs such as GNOME's Outreachy or graduate placements in companies.


There is no guarantee that Google will run the program again in 2016 or any future year until the Google announcement.

There is no guarantee that any organization or mentor (including myself) will be involved until the official list of organizations is published by Google.

Do not follow the advice of web sites that invite you to send pizza or anything else of value to prospective mentors.

Following the steps in this page doesn't guarantee selection. That said, people who do follow these steps are much more likely to be considered and interviewed than somebody who hasn't done any of the things in this list.

Understand what free software really is

You may hear terms like free software and open source software used interchangeably.

They don't mean exactly the same thing and many people use the term free software for the wrong things. Not all projects declaring themselves to be "free" or "open source" meet the definition of free software. Those that don't, usually as a result of deficiencies in their licenses, are fundamentally incompatible with the majority of software that does use genuinely free licenses.

Google Summer of Code is about both writing and publishing your code and it is also about community. It is fundamental that you know the basics of licensing and how to choose a free license that empowers the community to collaborate on your code well after GSoC has finished.

Please review the definition of free software early on and come back and review it from time to time. The The GNU Project / Free Software Foundation have excellent resources to help you understand what a free software license is and how it works to maximize community collaboration.

Don't look for shortcuts

There is no shortcut to GSoC selection and there is no shortcut to GSoC completion.

The student stipend (USD $5,500 in 2014) is not paid to students unless they complete a minimum amount of valid code. This means that even if a student did find some shortcut to selection, it is unlikely they would be paid without completing meaningful work.

If you are the right candidate for GSoC, you will not need a shortcut anyway. Are you the sort of person who can't leave a coding problem until you really feel it is fixed, even if you keep going all night? Have you ever woken up in the night with a dream about writing code still in your head? Do you become irritated by tedious or repetitive tasks and often think of ways to write code to eliminate such tasks? Does your family get cross with you because you take your laptop to Christmas dinner or some other significant occasion and start coding? If some of these statements summarize the way you think or feel you are probably a natural fit for GSoC.

An opportunity money can't buy

The GSoC stipend will not make you rich. It is intended to make sure you have enough money to survive through the summer and focus on your project. Professional developers make this much money in a week in leading business centers like New York, London and Singapore. When you get to that stage in 3-5 years, you will not even be thinking about exactly how much you made during internships.

GSoC gives you an edge over other internships because it involves publicly promoting your work. Many companies still try to hide the potential of their best recruits for fear they will be poached or that they will be able to demand higher salaries. Everything you complete in GSoC is intended to be published and you get full credit for it. Imagine a young musician getting the opportunity to perform on the main stage at a rock festival. This is how the free software community works. It is a meritocracy and there is nobody to hold you back.

Having a portfolio of free software that you have created or collaborated on and a wide network of professional contacts that you develop before, during and after GSoC will continue to pay you back for years to come. While other graduates are being screened through group interviews and testing days run by employers, people with a track record in a free software project often find they go straight to the final interview round.

Register your domain name and make a permanent email address

Free software is all about community and collaboration. Register your own domain name as this will become a focal point for your work and for people to get to know you as you become part of the community.

This is sound advice for anybody working in IT, not just programmers. It gives the impression that you are confident and have a long term interest in a technology career.

Choosing the provider: as a minimum, you want a provider that offers DNS management, static web site hosting, email forwarding and XMPP services all linked to your domain. You do not need to choose the provider that is linked to your internet connection at home and that is often not the best choice anyway. The XMPP foundation maintains a list of providers known to support XMPP.

Create an email address within your domain name. The most basic domain hosting providers will let you forward the email address to a webmail or university email account of your choice. Configure your webmail to send replies using your personalized email address in the From header.

Update your ~/.gitconfig file to use your personalized email address in your Git commits.

Create a web site and blog

Start writing a blog. Host it using your domain name.

Some people blog every day, other people just blog once every two or three months.

Create links from your web site to your other profiles, such as a Github profile page. This helps reinforce the pages/profiles that are genuinely related to you and avoid confusion with the pages of other developers.

Many mentors are keen to see their students writing a weekly report on a blog during GSoC so starting a blog now gives you a head start. Mentors look at blogs during the selection process to try and gain insight into which topics a student is most suitable for.

Create a profile on Github

Github is one of the most widely used software development web sites. Github makes it quick and easy for you to publish your work and collaborate on the work of other people. Create an account today and get in the habbit of forking other projects, improving them, committing your changes and pushing the work back into your Github account.

Github will quickly build a profile of your commits and this allows mentors to see and understand your interests and your strengths.

In your Github profile, add a link to your web site/blog and make sure the email address you are using for Git commits (in the ~/.gitconfig file) is based on your personal domain.

Start using PGP

Pretty Good Privacy (PGP) is the industry standard in protecting your identity online. All serious free software projects use PGP to sign tags in Git, to sign official emails and to sign official release files.

The most common way to start using PGP is with the GnuPG (GNU Privacy Guard) utility. It is installed by the package manager on most Linux systems.

When you create your own PGP key, use the email address involving your domain name. This is the most permanent and stable solution.

Print your key fingerprint using the gpg-key2ps command, it is in the signing-party package on most Linux systems. Keep copies of the fingerprint slips with you.

This is what my own PGP fingerprint slip looks like. You can also print the key fingerprint on a business card for a more professional look.

Using PGP, it is recommend that you sign any important messages you send but you do not have to encrypt the messages you send, especially if some of the people you send messages to (like family and friends) do not yet have the PGP software to decrypt them.

If using the Thunderbird (Icedove) email client from Mozilla, you can easily send signed messages and validate the messages you receive using the Enigmail plugin.

Get your PGP key signed

Once you have a PGP key, you will need to find other developers to sign it. For people I mentor personally in GSoC, I'm keen to see that you try and find another Debian Developer in your area to sign your key as early as possible.

Free software events

Try and find all the free software events in your area in the months between now and the end of the next Google Summer of Code season. Aim to attend at least two of them before GSoC.

Look closely at the schedules and find out about the individual speakers, the companies and the free software projects that are participating. For events that span more than one day, find out about the dinners, pub nights and other social parts of the event.

Try and identify people who will attend the event who have been GSoC mentors or who intend to be. Contact them before the event, if you are keen to work on something in their domain they may be able to make time to discuss it with you in person.

Take your PGP fingerprint slips. Even if you don't participate in a formal key-signing party at the event, you will still find some developers to sign your PGP key individually. You must take a photo ID document (such as your passport) for the other developer to check the name on your fingerprint but you do not give them a copy of the ID document.

Events come in all shapes and sizes. FOSDEM is an example of one of the bigger events in Europe, is a similarly large event in Australia. There are many, many more local events such as the Debian UK mini-DebConf in Cambridge, November 2015. Many events are either free or free for students but please check carefully if there is a requirement to register before attending.

On your blog, discuss which events you are attending and which sessions interest you. Write a blog during or after the event too, including photos.

Quantcast generously hosted the Ganglia community meeting in San Francisco, October 2013. We had a wild time in their offices with mini-scooters, burgers, beers and the Ganglia book. That's me on the pink mini-scooter and Bernard Li, one of the other Ganglia GSoC 2014 admins is on the right.

Install Linux

GSoC is fundamentally about free software. Linux is to free software what a tree is to the forest. Using Linux every day on your personal computer dramatically increases your ability to interact with the free software community and increases the number of potential GSoC projects that you can participate in.

This is not to say that people using Mac OS or Windows are unwelcome. I have worked with some great developers who were not Linux users. Linux gives you an edge though and the best time to gain that edge is now, while you are a student and well before you apply for GSoC.

If you must run Windows for some applications used in your course, it will run just fine in a virtual machine using Virtual Box, a free software solution for desktop virtualization. Use Linux as the primary operating system.

Here are links to download ISO DVD (and CD) images for some of the main Linux distributions:

If you are nervous about getting started with Linux, install it on a spare PC or in a virtual machine before you install it on your main PC or laptop. Linux is much less demanding on the hardware than Windows so you can easily run it on a machine that is 5-10 years old. Having just 4GB of RAM and 20GB of hard disk is usually more than enough for a basic graphical desktop environment although having better hardware makes it faster.

Your experiences installing and running Linux, especially if it requires some special effort to make it work with some of your hardware, make interesting topics for your blog.

Decide which technologies you know best

Personally, I have mentored students working with C, C++, Java, Python and JavaScript/HTML5.

In a GSoC program, you will typically do most of your work in just one of these languages.

From the outset, decide which language you will focus on and do everything you can to improve your competence with that language. For example, if you have already used Java in most of your course, plan on using Java in GSoC and make sure you read Effective Java (2nd Edition) by Joshua Bloch.

Decide which themes appeal to you

Find a topic that has long-term appeal for you. Maybe the topic relates to your course or maybe you already know what type of company you would like to work in.

Here is a list of some topics and some of the relevant software projects:

  • System administration, servers and networking: consider projects involving monitoring, automation, packaging. Ganglia is a great community to get involved with and you will encounter the Ganglia software in many large companies and academic/research networks. Contributing to a Linux distribution like Debian or Fedora packaging is another great way to get into system administration.
  • Desktop and user interface: consider projects involving window managers and desktop tools or adding to the user interface of just about any other software.
  • Big data and data science: this can apply to just about any other theme. For example, data science techniques are frequently used now to improve system administration.
  • Business and accounting: consider accounting, CRM and ERP software.
  • Finance and trading: consider projects like R, market data software like OpenMAMA and connectivity software (Apache Camel)
  • Real-time communication (RTC), VoIP, webcam and chat: look at the JSCommunicator or the Jitsi project
  • Web (JavaScript, HTML5): look at the JSCommunicator

Before the GSoC application process begins, you should aim to learn as much as possible about the theme you prefer and also gain practical experience using the software relating to that theme. For example, if you are attracted to the business and accounting theme, install the PostBooks suite and get to know it. Maybe you know somebody who runs a small business: help them to upgrade to PostBooks and use it to prepare some reports.

Make something

Make some small project, less than two week's work, to demonstrate your skills. It is important to make something that somebody will use for a practical purpose, this will help you gain experience communicating with other users through Github.

For an example, see the servlet Juliana Louback created for fixing phone numbers in December 2013. It has since been used as part of the Lumicall web site and Juliana was selected for a GSoC 2014 project with Debian.

There is no better way to demonstrate to a prospective mentor that you are ready for GSoC than by completing and publishing some small project like this yourself. If you don't have any immediate project ideas, many developers will also be able to give you tips on small projects like this that you can attempt, just come and ask us on one of the mailing lists.

Ideally, the project will be something that you would use anyway even if you do not end up participating in GSoC. Such projects are the most motivating and rewarding and usually end up becoming an example of your best work. To continue the example of somebody with a preference for business and accounting software, a small project you might create is a plugin or extension for PostBooks.

Getting to know prospective mentors

Many web sites provide useful information about the developers who contribute to free software projects. Some of these developers may be willing to be a GSoC mentor.

For example, look through some of the following:

Getting on the mentor's shortlist

Once you have identified projects that are interesting to you and developers who work on those projects, it is important to get yourself on the developer's shortlist.

Basically, the shortlist is a list of all students who the developer believes can complete the project. If I feel that a student is unlikely to complete a project or if I don't have enough information to judge a student's probability of success, that student will not be on my shortlist.

If I don't have any student on my shortlist, then a project will not go ahead at all. If there are multiple students on the shortlist, then I will be looking more closely at each of them to try and work out who is the best match.

One way to get a developer's attention is to look at bug reports they have created. Github makes it easy to see complaints or bug reports they have made about their own projects or other projects they depend on. Another way to do this is to search through their code for strings like FIXME and TODO. Projects with standalone bug trackers like the Debian bug tracker also provide an easy way to search for bug reports that a specific person has created or commented on.

Once you find some relevant bug reports, email the developer. Ask if anybody else is working on those issues. Try and start with an issue that is particularly easy and where the solution is interesting for you. This will help you learn to compile and test the program before you try to fix any more complicated bugs. It may even be something you can work on as part of your academic program.

Find successful projects from the previous year

Contact organizations and ask them which GSoC projects were most successful. In many organizations, you can find the past students' project plans and their final reports published on the web. Read through the plans submitted by the students who were chosen. Then read through the final reports by the same students and see how they compare to the original plans.

Start building your project proposal now

Don't wait for the application period to begin. Start writing a project proposal now.

When writing a proposal, it is important to include several things:

  • Think big: what is the goal at the end of the project? Does your work help the greater good in some way, such as increasing the market share of Linux on the desktop?
  • Details: what are specific challenges? What tools will you use?
  • Time management: what will you do each week? Are there weeks where you will not work on GSoC due to vacation or other events? These things are permitted but they must be in your plan if you know them in advance. If an accident or death in the family cut a week out of your GSoC project, which work would you skip and would your project still be useful without that? Having two weeks of flexible time in your plan makes it more resilient against interruptions.
  • Communication: are you on mailing lists, IRC and XMPP chat? Will you make a weekly report on your blog?
  • Users: who will benefit from your work?
  • Testing: who will test and validate your work throughout the project? Ideally, this should involve more than just the mentor.

If your project plan is good enough, could you put it on Kickstarter or another crowdfunding site? This is a good test of whether or not a project is going to be supported by a GSoC mentor.

Learn about packaging and distributing software

Packaging is a vital part of the free software lifecycle. It is very easy to upload a project to Github but it takes more effort to have it become an official package in systems like Debian, Fedora and Ubuntu.

Packaging and the communities around Linux distributions help you reach out to users of your software and get valuable feedback and new contributors. This boosts the impact of your work.

To start with, you may want to help the maintainer of an existing package. Debian packaging teams are existing communities that work in a team and welcome new contributors. The Debian Mentors initiative is another great starting place. In the Fedora world, the place to start may be in one of the Special Interest Groups (SIGs).

Think from the mentor's perspective

After the application deadline, mentors have just 2 or 3 weeks to choose the students. This is actually not a lot of time to be certain if a particular student is capable of completing a project. If the student has a published history of free software activity, the mentor feels a lot more confident about choosing the student.

Some mentors have more than one good student while other mentors receive no applications from capable students. In this situation, it is very common for mentors to send each other details of students who may be suitable. Once again, if a student has a good Github profile and a blog, it is much easier for mentors to try and match that student with another project.

GSoC logo generic


Getting into the world of software engineering is much like joining any other profession or even joining a new hobby or sporting activity. If you run, you probably have various types of shoe and a running watch and you may even spend a couple of nights at the track each week. If you enjoy playing a musical instrument, you probably have a collection of sheet music, accessories for your instrument and you may even aspire to build a recording studio in your garage (or you probably know somebody else who already did that).

The things listed on this page will not just help you walk the walk and talk the talk of a software developer, they will put you on a track to being one of the leaders. If you look over the profiles of other software developers on the Internet, you will find they are doing most of the things on this page already. Even if you are not selected for GSoC at all or decide not to apply, working through the steps on this page will help you clarify your own ideas about your career and help you make new friends in the software engineering community.

Bruce LawsonReading List

Steve Faulkner et alShort note on aria-labelledby and aria-describedby

The ARIA attributes aria-labelledby and aria-describedby can be used to provide an accessible name or accessible description for a subset of HTML elements. It is important to note that by design, hiding the content (using CSS display:none or visibility:hidden or the HTML hidden attribute) of the element(s) referenced by these attributes does not stop the content from being used to provide the name/description.

Hidden or visible – makes no difference

By default, assistive technologies do not relay hidden information, but an author can explicitly override that and include hidden text as part of the accessible name or accessible description by using aria-labelledby or aria-describedby.
Accessible Name and Description: Computation and API Mappings 1.1

In the following example the description will be available to assistive technology users in both states:

Non error state: message not visible

<label>Name <input type="text"  aria-describedby="error-message"></label>
<span id="error-message" <mark>style="display:none"</mark>>
You have provided an incorrect name</span>

Note: addition of aria-hidden=true to the referenced element makes no difference:

<span id="error-message" style="display:none" <mark>aria-hidden="true"</mark>>
 You have provided an incorrect name</span>

Error state: message visible

<span id="error-message" <mark>style="display:inline"</mark>>
You have provided an incorrect name</span>

Methods to provide context sensitive name/description text

If you want to associate context sensitive text, such as an error message you can:

  • Add the referenced element to the DOM when the error state occurs.
  • Add the error text as child of the referenced element in the DOM when the error state occurs.
    • non error state: <p id="error1"></p>
    • error state: <p id="error1">incorrect mallory!</p>
  • Add the id reference in the DOM to the aria-labelledby/aria-describedby attribute, when the error state occurs.

Further reading: Notes on Using ARIA in HTML

Steve Faulkner et al#A11Y Slackers

#a11y slackers - play on the slack multicolored hash symbolA ubiquitous issue for people involved in moving the web forward is that there is always too much to do. Identifiying and prioritising tasks is critical. Identifying is fairly easy, prioritising not so. Priorities depend on both internal and external factors often beyond our control.

I have a tendency to be critical of huge, profit making, corporations that are involved in moving the web forward who de-prioritise accessibility [who appear to de-prioritise accessibility]. It’s not always a useful trait, but it’s who I am. I am also aware that many of the people who I interact with, while working for these corporations, are doing their best to make accessibility a priority despite the internal and external factors beyond their control.

A current example is Microsoft, what we know is that Windows 10 will be with us at the end of the month along with a new much improved standards based browser called Edge. What is known is that Microsoft is a huge corporation with a long history of accessibility support in its software and also a long history of broken sub-standard accessibility support for HTML in its browser (IE). IE has come along way in web standards support in the last few years, the  same cannot be said for the accessibility branch of web standards.

There is the future promise that with Edge accessibility web standards support will be much improved, but as is often the case due to corporate prioritisation, and resulting provision of resources and expertise, Windows 10 will arrive with a brand new browser, with broken accessibility support and advice to continue to use the old IE browser whose support, while broken, is more robust because assistive technology have had a lot of time to hack around the brokeness.

It is instructive to understand that when an organization genuinely prioritises the needs of users with disabilities, anything is possible:

<script async="" charset="utf-8" src=""></script>

Further Reading

Windows 10: Advisories from screen reader developers and final thoughts


It was unfair of me to imply that the current Microsoft browser team are #a11y slackers. They are doing all they can under difficult circumstances to bring a modern, robust accessibility implementation to Edge, something that unfortunately Microsoft failed to do in the history of IE.

Steve Faulkner et alShort Note on HTML conformance checking

When you check a HTML document, using the W3C HTML conformance checker, to find out whether its code conforms to the rules defined in the HTML specification (and other referenced specifications). It’s useful to understand what the output means.

W3C Nu Markup checker


Errors are instances where the code you are checking does not conform to MUST level requirements defined in the HTML specification.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT  This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

For example, the following code snippet breaks the rule:

Content model for element ol: Zero or more li and script-supporting elements.


In other words, an ol element must only contain li, script or template elements as child elements.


MUST level requirements and the errors they produce are there to stop you doing stuff that can cause problems or remind you to do stuff that you need to do to avoid problems.

W3C Old Skool W3C validator


Warnings are instances where the code you are checking does not conform to SHOULD level requirements defined in the HTML specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

For example, the following code snippet breaks the rule:

Default Implicit ARIA semantics – SHOULD NOT be used

<ol <mark>role="list"</mark>>
<li>item 1

In other words, ol has a an implicit role of list, which is conveyed by browsers automatically, so there is no neeed to add the explicit role as an attribute.

<mark><li></mark>list item

SHOULD level requirements and the warnings they produce are there to stop you doing stuff that is unecessary or harmful in general or as a reminder to do stuff that it is useful or helpful to do, in general.

Where do these requirement terms come from?

An ancient (1997) text handed down by our ancestors: Key words for use in RFCs to Indicate Requirement Levels. Which you will find referenced by many (all?) W3C specifications that define what are known as normative requirements. Requirements are defined in HTML, for user agent implementers, conformance tool implementers or web developers (AKA authors).

Further Reading

Steve Faulkner et alShort note on coding alt text

The other day, in relation to a github comment, I was asked by my friend Mike[tm]Smith “Can alt have line breaks in it or does that do weird things to assistive technologies like screen readers?”.  I did some quick testing. What I found was that line breaks in alt attribute text, has a few suboptimal effects, dependent on browser and screen reader used.

The noted UX effects of line breaks (limited browser/screen reader combinations tested) in HTML source code of alt are:

  • Reading of alt text stops at the end of a line.
  • After pressing the continue reading key, reading of the alt text resumes but the object role (in this case “graphic”) is announced at the start of each new line.

Given that a primary use case for alt text is to provide information for screen readers users, it is reasonable that developers should consider not including arbitrary line breaks in alt text, so that the best UX for screen reader users is provided.


The following code example would be announced something like
“graphic, Having no line breaks in HTML code of alt attributes produces better UX
graphic, than
graphic, having
graphic, line
graphic, breaks.”

<img alt="Having no line breaks in HTML code of alt attributes produces better UX, 

Where as The following code example would be announced something like: “graphic, Having no line breaks in HTML code of alt attributes produces better UX, than having line breaks.”

<img alt="Having no line breaks in HTML code of alt attributes produces better UX, than having line breaks.">

Steve Faulkner et alEasy content organisation with HTML5

Typically designers and web developers divide web pages into macro content areas (let’s call them regions). Doing an image search for typical web page returns lots of examples of diagrammatic representations of web pages with similar regions delineated:

  • header
  • navigation
  • main content
  • sidebar
  • footer

All of the page content is organised into a small number of regions which are parents of the rest of the page content. Usually these regions are identifiable visually by design and the type of content they contain, a user can scan the page and quickly get a feel for the page content and find what they are looking for. With HTML5 you can express this visual organisation semantically in your code. By using just 5 elements (aside, footer, header, main and nav)  available in HTML5 you can provide the understanding and navigation benefits of content organisation to users who would otherwise not be able to perceive it from the visual cues alone:

Typical web page diagram.

Page layout with header at top, nav on right side, main in the middle, aside on right side and footer at bottom.

Code example


Region order

The order in which the elements are organised and the region types used is based on your content organisation. Hell, if your content is organised such that you have a fat footer at the top of the page and navigation at the bottom, then so be it.

atypical content organisation.

Page layout with a fat footer at the top, followed by the main content and navigation at the bottom.

Code example


Regions within Regions

If you content organisation is such that a region is nested within another region, go for it.

nested nav within header

Page with navigation within the header region

Code example


That’s it!

When it comes to using HTML5 structural elements to define page regions the semantic magic is done my the browser (mapping the elements to ARIA landmark roles). There are a few general rules that will help users get the most out of your semantic markup:

  • Ensure all page content is within a region.
  • Less is more, regions are macro structures, so use them parsimoniously. As their number increases their utility to users decreases.
  • To mark up more granular content, within regions, use article/section/headings/paragraphs/lists etc.

Planet MozillaOf impostor syndrome and running in circles (part 2)

These are the notes of my talk at SmartWebConf in Romania. Part 1 covered how Impostor Syndrome cripples us in using what we hear about at conferences. It also covered how our training and onboarding focuses on coding. And how it lacks in social skills and individuality. This post talks about the current state of affairs. We have a lot of great stuff to play with but instead of using it we always chase the next.

This is part 2 of 3.

Lunch eaten by native: news at 11

When reading about the state of the web there is no lack of doom and gloom posts. Native development is often quoted as “eating our lunch”. Native-only interaction models are sold to us as things “people use these days”. Many of them are dependent on hardware or protected by patents. But they look amazing and in comparison the web seems to fall behind.

The web doesn’t need to compete everywhere

This is true, but it also not surprising. Flash showed many things that are possible that HTML/CSS/JS couldn’t do. Most of these were interesting experiments. They looked like a grand idea at the time. And they went away without an outcry of users. What a native environment have and what we do on the web is a comparison the web can’t win. And it shouldn’t try to.

The web per definition is independent of hardware and interaction model. Native environments aren’t – on the contrary. Success on native is about strict control. You control the interaction, the distribution and what the user can and can’t see. You can lock out users and not let them get to the next level. Unless they pay for it or buy the next version of your app or OS. The web is a medium that puts the user in control. Native apps and environments do not. They give users an easy to digest experience. An experience controlled by commercial ideas and company goals. Yes, the experience is beautiful in a lot of cases. But all you get is a perishable good. The maintainer of the app controls what stays in older versions and when you have to pay the next version. The maintainers of the OS dictate what an app can and can not do. Any app can close down and take your data with it. This is much harder on the web as data gets archived and distributed.

The web’s not cool anymore – and that’s OK

Evolution happens and we are seeing this right now. Browsers on desktop machines are not the end-all of human-computer interaction. That is one way of consuming and contributing to the web. The web is ubiquitous now. That means it is not as exciting for people as it was for us when we discovered and formed it. It is plumbing. How much do you know about the electricity and water grid that feeds your house? You never cared to learn about this – and this is exactly how people feel about the web now.

This doesn’t mean the web is dead – it just means it is something people use. So our job should be to make that experience as easy as possible. We need to provide a good service people can trust and rely on. Our aim should be reliability, not flights of fancy.

It is interesting to go back to the promises HTML5 gave us. Back when it was the big hype and replacement for Flash/Flex. When you do this, you’ll find a lot of great things that we have now without realising them. We complained when they didn’t work and now that we have them – nobody seems to use them.

Re-visiting forms

Take forms for example. You can see the demos I’m about to show here on GitHub.

When it comes down to it, most “apps” in their basic form are just this: forms. You enter data, you get data back. Games are the exception to this, but they are only a small part of what we use the web for.

When I started as a web developer forms meant you entered some data. Then you submitted the form and you got an error message telling you what fields you forgot and what you did wrong.

<form action="/cgi-bin/">
  <ul class="error">
    <li>There were some errors:
        <li><a href="#name">Name is required</a></li>
        <li><a href="#birthday">Birthday needs to 
          be in the format of DD/MM/YYYY</a></li>
        <li><a href="#phone">Phone can't have 
          any characters but 0-9</a></li>
        <li><a href="#age">Age needs to be 
          a number</a></li>
  <p><label for="name">Contact Name *</label>
     <input type="text" id="name" name="name"></p>
  <p><label for="bday">Birthday</label>
     <input type="text" id="bday" name="bday"></p>
  <p><label for="lcolour">Label Colour</label>
     <input type="text" id="lcolour" name="lcolour"></p>
  <p><label for="phone">Phone</label>
     <input type="text" id="phone" name="phone"></p>
  <p><label for="age">Age</label>
     <input type="text" id="age" name="age"></p>
  <p class="sendoff">
    <input type="submit" value="add to contacts">

form with error links

This doesn’t look much, but let’s just remember a few things here:

  • Using labels we make this form available to all kind of users independent of ability
  • You create a larger hit target for mobile users. A radio button with a label next to it means users can tap the word instead of trying to hit the small round interface element.
  • As you use IDs to link labels and elements (unless you nest one in the other), you also have a free target to link to in your error links
  • With a submit button you enable user to either hit the button or press enter to send the form. If you use your keyboard, that’s a pretty natural way of ending the annoying data entry part.

Nothing ground-breaking, I admit, but a lot of useful functionality. Functionality you’d have to simulate if you did it all with SPANs and DIVs. And all this without a single line of JavaScript.

Enter JavaScript

Then we got JavaScript. This enabled us to create higher fidelity forms. Forms that tell the user when something went wrong before submitting. No more uneccesary page reloads. We started to build richer interaction models like forms with optional fields depending on the content of others. In my 2006 book Beginning JavaScript with DOM Scripting in Ajax I had a whole chapter dedicated to forms (code examples are here). All of these enhancements had the problem that when JavaScript for some reason or another didn’t work, the form still was happily submitting data to the server. That meant and still means that you have to validate on the server in addition to relying on client-side validation. Client side validation is a nice-to-have, not a security measure.

Enter HTML5 and browser convenience features

HTML5 supercharged forms. One amazing thing is the required attribute we can put on any form field to make it mandatory and stop the form from submitting. We can define patterns for validation and we have higher fidelity form types that render as use-case specific widgets. If a browser doesn’t support those, all the end user gets is an input field. No harm done, as they can just type the content.

In addition to this, browsers added conveniences for users. Browsers remember content for aptly named and typed input elements so you don’t have to type in your telephone number repeatedly. This gives us quite an incredible user experience. A feature we fail to value as it appears so obvious.

Take this example.

<form action="/cgi-bin/">
  <p><label for="name">Contact Name *</label>
     <input type="text" required id="name" name="name"></p>
  <p><label for="bday">Birthday</label>
     <input type="date" id="bday" name="bday" 
  <p><label for="lcolour">Label Colour</label>
     <input type="color" id="lcolour" name="lcolour"></p>
  <p><label for="phone">Phone</label>
     <input type="tel" id="phone" name="phone"></p>
  <p><label for="age">Age</label>
     <input type="number" id="age" name="age"></p>
  <p class="sendoff">
    <input type="submit" value="add to contacts">

animation showing different form elements and auto-filling by browsers

There’s a lot of cool stuff happening here:

  • I can’t send the form without entering a contact name. This is what the required attribute does. No JavaScript needed here. You even can rename the error message or intercept it.
  • The birthday date field has a placeholder telling the user what format is expected. You can type a date in or use the arrows up and down to enter it. The form automatically realises that there is no 13th month and that some months have less than 31 days. Other browsers even give you a full calendar popup.
  • The colour picker is just that – a visual, high-fidelity colour picker (yes, I keep typing this “wrong”)
  • The tel and number types do not only limit the allowed characters to use, but also switch to the appropriate on-screen keyboards on mobile devices.
  • Any erroneous field gets a red border around it – I can’t even remember how many times I had to code this in JavaScript. This is even style-able with a selector.

That’s a lot of great interaction we get for free. What about cutting down on the display of data to make the best of limited space we have?

Originally, this is what we had select boxes for, which render well, but are not fun to use. As someone living in England and having to wonder if it is “England”, “Great Britain” or “United Kingdom” in a massive list of countries, I know exactly how that feels. Especially on small devices on touch/stylus devices they can be very annoying.

<form action="/cgi-bin/">
  <label for="lang">Language</label>
  <select id="lang" name="lang">
<p class="sendoff">
  <input type="submit" value="add to contacts">

scrolling through a select box

However, as someone who uses the keyboard to navigate through forms, I learned early enough that these days select boxes have become more intelligent. Instead of having to scroll through them by clicking the tiny arrows or using the arrow keys you can start typing the first letter of the option you want to choose. That way you can select much faster.

typing in a select box

This only works with words beginning with the letter sequence you type. A proper autocomplete should also match character sequences in the middle of an option. For this, HTML5 has a new element called datalist.

<form action="/cgi-bin/">
    <label for="lang">Language</label>
    <input type="text" name="lang" id="lang" list="languages">
    <datalist id="languages">
  <p class="sendoff">
    <input type="submit" value="add to contacts">

This one extends an input element with a list attribute and works like you expect it to:

datalist autocomplete example

There is an interesting concept here. Instead of making the select box have the same feature and roll it up into a combo box that exists in other UI libraries, the working group of HTML5 chose to enhance an input element. This is consistent with the other new input types.

However, it feels odd that for browsers that don’t support the datalist element all this content in the page would be useless. Jeremy Keith thought the same and came up with a pattern that allows for a select element in older browsers and a datalist in newer ones:

<form action="/cgi-bin/">
    <label for="lang">Language</label>
    <datalist id="languages">
    <select name="lang">
    <div>or specify: </div>
    <input type="text" name="lang" id="lang" list="languages">
  <p class="sendoff">
    <input type="submit" value="add to contacts">

This works as a datalist in HTML5 compliant browsers.

datalist autocomplete example working

In older browsers, you get a sensible fallback, re-using all the option elements that are in the document.

datalist autocomplete example failing and falling back to a select box

This is not witchcraft, but is based on a firm understanding of how HTML and CSS work. Both these are fault tolerant. This means if a mistake happens, it gets skipped and the rest of the document or style sheet keeps getting applied.

In this case, older browsers don’t know what a datalist is. All they see is a select box and an input element as browsers render content of unknown elements. The unknown list attribute on the input element isn’t understood, so the browser skips that, too.

HTML5 browsers see a datalist element. Per standard, all this can include are option elements. That’s why neither the select, nor the input and the text above it get rendered. They are not valid, so the browser removes them. Everybody wins.

A craving for control

Browsers and the standards they implement are full of clever and beautiful things like that these days. And we’ve loudly and angrily demanded to have them when they got defined. We tested, we complained, we showed what needed to be done to make the tomorrow work today and then we forgot about it. And we moved on to chase the next innovation.

How come that repeatedly happens? Why don’t we at some point stop and see how much great toys we have to play with? It is pretty simple: control.

We love to be in control and we like to call the shots. That’s why we continuously try to style form elements and create our own sliders, scroll bars and dropdown boxes. That’s why we use non-support by a few outdated browsers of a standard as an excuse to discard it completely and write a JavaScript solution instead. We don’t have time to wait for browsers to get their act together, so it is up to us to save the day. Well, no, it isn’t.

Just because you can do everything with JavaScript, doesn’t mean that you should do it. We invented HTML5 as the successor and replacement of XHTML as it had one flaw: a single wrong encoding or nesting of elements and the document wouldn’t render. End users would be punished for our mistakes. That’s why HTML5 is fault tolerant.

JavaScript is not. Any mistake that happens means the end user looks at an endless spinner or an empty page. This isn’t innovation, this is building on a flaky foundation. And whilst we do that, we forgot to re-visit the foundation we have in browsers and standards support. This is a good time to do that. You’d be surprised how many cool things you’ll find you only thought possible by using a JavaScript UI framework.

But more on that in part 3 of this post.

IEBlogAccessibility: Towards a more inclusive web with Microsoft Edge and Windows 10

Microsoft is committed to accessibility as a core part of software design, and today we would like to share more about how Microsoft Edge is evolving to improve support for assistive technology beyond what was possible in Internet Explorer.

Inclusive development is a journey, not merely a destination, and we are committed to continuing to evolve Microsoft Edge to be the best place for accessible browsing on Windows. We’ve made a major step forward with architectural changes in Microsoft Edge, some of which regress experiences compared to Internet Explorer in the short term, but which are in the interest of creating a more inclusive experience for everyone in the long term. This post outlines our journey to a more accessible web experience, including changes in Microsoft Edge available today and recommendations for Windows 10 users who rely on third-party assistive technology software.

Our journey to a more accessible web experience

Windows has used the Microsoft Active Accessibility (MSAA) API since Windows 98 to express buttons, menus, text, and other on-screen content to assistive technology. Assistive technology vendors have used the MSAA API (along with other app-specific APIs like the DOM in IE, the Office Object Model in Office, and even scraping video drivers) to make text and interfaces more accessible. These techniques have the disadvantage of varying wildly between different applications and documents, which leads to a fragmented and unreliable experience. As user interfaces, documents, and the web significantly increased in complexity, Microsoft introduced the more modern UI Automation (UIA) API in Windows Vista as the successor to MSAA.

UIA was designed to expose more information about the user interface and structured documents, improve performance, and be portable across platforms. Because UIA replaces a variety of potentially unreliable and non-interoperable techniques with a single API, it reduces software complexity, allows developers to express novel UI concepts more easily, and improves stability and user experience consistency between web and native apps, across all types of assistive technology.

Though UIA superseded in MSAA in 2005, Internet Explorer continued to rely on MSAA, using a ‘bridge’ to convert between MSAA and UIA. Relying on this bridge introduced bugs and performance problems in Internet Explorer, and for years it has been a goal of the browser team to move to a native UIA implementation.

Accessibility investments in Microsoft Edge

In Microsoft Edge, we are thrilled to finally have the opportunity to make the transition from MSAA to UIA, alongside enormous complementary investments in rearchitecting our DOM implementation and rewriting the browser interface from scratch. The change to UIA is our largest investment in browser accessibility ever, and it lays the foundation for a more inclusive web experience for users who depend on assistive technology in Windows 10. Because EdgeHTML is used throughout Windows 10 (inside Universal Windows Apps, in Cortana, etc.), these benefits will have an impact beyond the browser. Users will also benefit from the evergreen nature of the EdgeHTML engine.

You can see many of the improvements in action today using Narrator, which is built into Windows 10. We’re using Narrator to vet UIA as we simultaneously work with third party assistive technology providers to transition in the near future. For example, while MSAA supports only basic UI constructs, Narrator works with UIA in Microsoft Edge to express more complex roles, states, and properties to better represent structured and interactive documents.

<iframe allowfullscreen="true" class="youtube-player" frameborder="0" height="390" src=";rel=1&amp;fs=1&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;wmode=transparent" type="text/html" width="640"></iframe>

Using Narrator in Microsoft Edge exposes a set of new accessibility features, including:

  • ARIA roles: none, article, definition, log, math, note, scrollbarapplication, banner, complementary, contentinfo, form, main, navigation, search
  • ARIA properties: aria-atomic, aria-autocomplete, aria-dropeffect, aria-grabbed, aria-label, aria-multiline, aria-orientation, aria-sort, aria-valuetext
  • HTML headings (<h1> to <h6>) are exposed via role and property
  • Indeterminate HTML checkbox
  • Narrator table and list reading improvements
  • UIA implementation in HTML5 form elements

The Microsoft Edge team continues to work with the W3C and other browser vendors on an ongoing basis to ensure that new web platform features have sufficient built-in accessibility. For example, Internet Explorer was one of the first browsers to support the <track> element and WebVTT caption format for video captioning. The work we shipped in Windows 10 gives us a foundation to release future features more quickly, as part of our commitment to making EdgeHTML an evergreen platform.

Getting to good: Our backlog

We recognize Microsoft Edge isn’t where it needs to be to provide a fully accessible browsing experience. Building a new browser required new user experience work in all levels of the product, including accessibility.  Windows Insiders and others in the accessibility community have provided valuable feedback which we’re using to prioritize improvements to the accessibility of the browser’s controls and the web itself in Microsoft Edge that will be available in the coming months.  These include:

  • Better keyboarding and narrator support in major UI elements such as the address bar, settings, favorites, history, and downloads
  • Support for semantically tagged PDFs for paragraphs, links, and images including alternative text specified for links and images. PDF improvements also include better keyboarding for links within a document.
  • Improved Flash accessibility
  • Improved ARIA and HTML mapping to UIA

We’re also working on longer-term investments. The following are high priority items on our backlog:

Finally, we’re working to help enable WebDriver support for automating accessibility API testing.

This list is just the beginning – we will continue to invest in Microsoft Edge and sharing our development roadmap via this blog and our Platform Status page, which we’re updating to reflect the above priorities. We encourage you to share your feedback on our priorities to help us rank our backlog appropriately.

Recommendations for Assistive Technology users on Windows 10

Many assistive technology users rely on third-party screen readers, so we are working closely with the most popular third-party assistive technology vendors to help them transition to UIA to provide a better experience for their users than was possible in Internet Explorer. These conversations are also a valuable feedback channel for us as we evolve UIA to close any remaining gaps with other APIs like MSAA and IAccessible2.

Users who depend on third party assistive technology should read Rob Sinclair’s post, “Windows 10 upgrade considerations for screen reader and magnifier users,” on the Microsoft Accessibility Blog. Some third party assistive technology may not yet be fully compatible with Microsoft Edge; in the short term, we recommend Internet Explorer for the most accessible browsing experience with these tools as our partners complete this transition. As we continue to work with assistive technology providers and evolve UIA in Windows 10, we expect Microsoft Edge to close the gap with Internet Explorer, and third party assistive technologies to begin providing UIA support on par with Narrator in the coming months.

If you encounter issues using assistive technology on Windows 10, you can contact the Microsoft Disability Answer Desk for support, or contact your assistive technology vendor for more information on their Windows 10 and Microsoft Edge support.

As we continue to improve the accessibility of Windows 10, your feedback is crucial. We encourage you to consider joining the Windows Insider Program to share your experiences and suggestions with us.

– Cynthia C. Shelly, Senior Program Manager, Microsoft Developer Platform

Planet WebKitXabier Rodríguez Calvar: WebKit Contributors Meeting 2015 (late, I know)

After writing my last post I realized that I needed to write a bit more about what I had been doing at the WebKit Contributors Meeting.

First thing to say is that it happened in March at Apple campus in Cupertino and I atteded as part of the Igalia gang.

My goal when I went there was to discuss with Youenn Fablet about Streams API and we are implementing and see how we could bootstrap the reviews and being to get the code reviewed and landed efficiently. Youenn and I also made a presentation (mainly him) about it. At that moment we got some comments and help from Benjamin Poulain and nowadays we are also working with Darin Adler and Geoffrey Garen so the work is ongoing.

WebRTC was also a hot topic and we talked a bit about how to deal with the promises as they seem to be involved in the WebRTC standard was well. My Igalian partner Philippe was missed in this regard as he is involved in the development of WebRTC in WebKit, but he unfortunately couldn’t make it because of personal reasons.

I also had an interesting talk with Jer Noble and Eric Carlson about Media Source and Encrypted Media Extensions. I told them about the several downstream implementations that we are or were working on, specially the WebKit4Wayland one and that we expect to begin to upstream soon. They commented that they still have doubts about the abstractions they made for them and of course I promised to get back to them when we begin with the job. Actually I already discussed some issues with Quique, another fellow Igalian.

Among the other interesting discussions, I found very necessary the migration of Mac port to CMake. Actually, I am experiencing now the painbenefits of using XCode to add files, specially the generated ones to the compilation. I hope that Alex succeeds with the task and soon we have a common build system for all main ports.

Reddit: BrowsersH.264 video CPU usage in browsers, result: IE wins, your results?

I recently tested various browsers on Windows playing a h264-encoded and hardware accelerated YouTube video. Much to my surprise, IE/Edge won by a mile, it had by far the lowest CPU usage and smoothest video. Now I'm very interested if you guys could confirm this. If you don't have the time, just write a sentence or two, but for the sake of comparison, here's sort of a testing procedure you could follow:

  • Play this video using IE/Edge, Chrome and FF:
  • Switch to 1080p
  • Make sure it plays using the HTML5 player
  • Make sure it's using hardware acceleration. Right-click the player and click "stats for nerds", make sure it shows avc (h264) as a codec. If it says VP8/VP9, it's most probably not hardware accelerated as very few (none?) graphics cards support it yet. To force h264, you can install an addon called "h264ify", available for Chrome and FF, not neccessary in IE/Edge as it uses h264 by default.
  • Over 20-30 seconds, note the bottom average CPU usage (valleys, not spikes) and subjective smoothness of the video playback. To test smoothness, the part at is very useful.

My results:

  • IE/Edge: 15%, smooth as butter
  • Chrome: 35%, fairly smooth
  • Firefox: 45%, slightly choppy

Surprising, isn't it? Very different results despite they're all hardware accelerated. I made sure by switching to flash and disabling hardware acceleration in the context menu, I got 100% CPU usage on all browsers. Anything above 60% most likely means your hardware acceleration isn't working.

Linux results are welcome as well, as bad video acceleration support is the only thing that keeps me from making the switch.

submitted by asdf922
[link] [3 comments]

Reddit: BrowsersBrowsers that don't use GTK/QT

Hi all. I'm looking for a browser that doesn't use gtk or qt. I'm familiar with links and dillo for instance. I would really like something that dealt with javascrip, css, and html5 like a more modern browser (vivaldi, chromium, firefox etc.) but without the GTK/QT toolkit. I'm not opposed to trying other toolkits (Dillo uses FLTK after all) Breach seemed like a good bet but their domain has expired and I don't know if it's still actively being worked on.

submitted by MrDowntempo
[link] [10 comments]

Bruce LawsonReading List

Planet MozillaQuick trick: using template to delay loading of images

In addition to this explanation, I also recorded a quick screencast. Feel free to check that one first.

When it comes to newer elements to play with there are a few that are slightly odd. Canvas is one of them, as it doesn’t do anything without scripting. It is a placeholder for a canvas painting or animation and can contain fallback content when it is not supported. This ailed purists of semantic HTML when it came out, because – to a degree – this was just a rehash of applet or object we used with Java or Flash.

Template is an even weirder thing. Using template you can define inert content in HTML - this means the content is not rendered by the browser, and anything inside it is not executed (for example script elements). Again, this is something that can annoy purists, as this content only makes sense when JavaScript is available. But, to people who are used to templating in other languages, this is a great opportunity.

The biggest issue with template is that it can’t really by polyfilled as browsers that don’t know template, treat it like a DIV and render its content. In the past we simulated this functionality with script elements with a type of text/html as those will be skipped by browsers.

For more info about template itself, check these resources:

One thing you can do with template is to put content in it that is “nice to have” but would delay the loading of the page and especially the firing of the onload handler.

I’ve done this in the Cuter demo of Tinderesque. This demo loads a lot of images, and not all of them need to be available right away. That’s why I put five of them in the document and wrapped the rest in a template:

<ul class="cardlist">
  <li class="card current"><img src="images/a-push-please.jpg" alt=""></li>
  <li class="card"><img src="images/amazing-dog.jpg" alt=""></li>
  <li class="card"><img src="images/awesome-mix-dog.jpg" alt=""></li>
  <li class="card"><img src="images/baby-amardillo.jpg" alt=""></li>
  <li class="card"><img src="images/baby-hippo-nom.jpg" alt=""></li>
    <li class="card"><img src="images/baby-rhino.jpg" alt=""></li>
    <li class="card"><img src="images/barbie-frenchie.jpg" alt=""></li>
    <li class="card"><img src="images/basset-helmet.jpg" alt=""></li>
    <li class="card"><img src="images/bear-dog.jpg" alt=""></li>
    <li class="card"><img src="images/bear-puppy-fluff.jpg" alt=""></li>
    <li class="card"><img src="images/best-day-ever-puppy.jpg" alt=""></li>
    <li class="card"><img src="images/bleh-puppy.jpg" alt=""></li>
    <li class="card"><img src="images/bleh-tapir.jpg" alt=""></li>
    <li class="card"><img src="images/cat-on-stairs.jpg" alt=""></li>
    <li class="card"><img src="images/chocolate-puppy.jpg" alt=""></li>
    <li class="card"><img src="images/corgisquee.jpg" alt=""></li>
    <li class="card"><img src="images/corns-and-penny.jpg" alt=""></li>
    <li class="card"><img src="images/crazy-otter.jpg" alt=""></li>
    <li class="card"><img src="images/cute-brown-puppy.jpg" alt=""></li>
    <li class="card"><img src="images/dalmatian.jpg" alt=""></li>
    <li class="card"><img src="images/derpy-hedgehog.jpg" alt=""></li>

This allows me to maintain all the info of my images in HTML (rather than having to add all the sources, alternative text, titles and so on in some JSON blob) and only load the first five when the page loads.

To add the rest, I just use an onload handler, that takes the content of the template and adds it to the parent element.

window.addEventListener('load', function(ev) {
  // check if template is supported
  // browsers without it wouldn't need to
  // do the content shifting
  if ('content' in document.createElement('template')) {
    // get the template
    var t = document.querySelector('template');
    // get its parent element
    var list = t.parentNode;
    // cache the template content
    var contents = t.innerHTML;
    // kill the template
    // add the cached content to the parent
    list.innerHTML += contents;
  all = document.body.querySelectorAll('.card').length + 1;

The difference is pretty significant. Without the template trick the 542 KB transferred in 26 requests take 6.43 seconds on a 3G connection. The onload handler fires after that. With the template, onload fires at 2.08 seconds. Here’s a screenshot of both using Chrome Devtools:

Onload delay with and without template

Template support is pretty great. The only browsers that don’t support it for now are IE and Microsoft Edge. Opera Mini also doesn’t support it, but that’s due to it’s non-client script nature.

Browsers that don’t support template will load all the images and delay the onload handler. But all the others can properly benefit from this. Why not give it a go?

Planet MozillaUpdate on Glucosio

Glucosio is an open source project I founded recently. I blogged about the kick off here. I wanted to give an update as the project is moving forward better than I had imagined.


We are currently aiming for our Glucosio for Android Alpha release this month with a tentative release date on September 20th, 2015. This being our Alpha and our first public release will be the base of the app. It will have basic functions but the more advance features on our roadmap will be distributed across subsequent releases and I’m sure we will keep coming up with innovative ideas as we research the needs of people with diabetes. Hat tip to Paolo, Ahmar, Satyajit and Elio who have been working tirelessly on this release.



I’m happy to report that Glucosio is already translated into 13 languages. More specifically: Albanian, Arabic, Bengali, Bengali (India), Breton, Bulgarian, Chinese Simplified, German, Italian, Spanish, Spanish (Venezuela), and Spanish (Mexico). We plan to have Greek, Japanese, Vietnamese, Malay, Portuguese, Russian, Hindi before launch. (Want to translate these for us? Check here.) Translations are really important to this project because every language we can offer is a population of people we can reach with our app seeing as diabetes is a global problem. The more people we reach worldwide, the more we can offer great tools to and the more opt-ins to share anonymous trends and demographic data with diabetes researchers we can get. Hat tip to Arturo who is leading our l10n efforts!



We are still actively looking for a lead iOS Developer or even two people contributing part-time on our Glucosio for iOS product. If you know someone, tell them to ping me!

HTML5 App (Firefox OS, Ubuntu Phone and Tizen)

This is sitting in our backburner but it is definitely within the scope of our vision and will help us reach platforms like Firefox OS, Ubuntu Phone and Tizen. We initially looked at doing cross-platform development but realized we could give a better experience if we built individual apps for Android and iOS.



Currently, this project has been very low cost thanks to some great supporters. Other than that, I have bootstrapped any costs, which again have been very small. We have decided from the start of this project that we do not want to monetize our apps because we feel it will dilute our vision and goals for the project. That being said, maybe the team will look into donations, crowdfunding or other options in the future if it becomes necessary. We are also looking into becoming a SPI (Software in the Public Interest) associated project so we will have a financial home and some resources available to us.


What’s next?

We are just going to be focusing for the next few weeks on getting this Alpha out the door. That includes wrapping up translations, doing some internal testing, and making sure we get out a crisp Alpha (that happens right?). Then we will sit down and discuss next things we want to prioritize and have a release post-mortem to improve our next cycle.


How you can help?

We have a really great team of people and would love to have more help. It has so far helped for us to have lots of hands in the pot and allowed us to scale as a project and get a lot of work done in a very short amount of time. If you are interested in contributing, hit us up at hello [AT] or ping us on Twitter at @GlucosioApp. We have contribution areas to include Development (iOS/Android/HTML5), l10n, Marketing, QA, and more. Hopefully by our Beta release, we will have some crisp documentation on our wiki on how to get started on all of these pathways!



Planet MozillaIntroducing a New Thimble and Bramble


This week we're shipping something really cool with Mozilla, and I wanted to pause and tell you about what it is, and how it works.

The tldr; is that we took the Mozilla Foundation's existing web code editor, Thimble, and rewrote it to use Bramble, our forked version of the Brackets editor, which runs in modern web browsers. You can try it now at

If you're the type who prefers animated pictures to words, I made you a bunch over on the wiki, showing what a few of the features look like in action. You can also check out Luke's great intro video.

If you're the type who likes words, the rest of this is for you.


I started working on this project two years ago. While at MozFest 2013 I wrote about an idea I had for a new concept app that merged Thimble and Brackets; at the time I called it Nimble.

I was interested in merging these two apps for a number of reasons. First, I wanted to eliminate the "ceiling" users had when using Thimble, wherein they would graduate beyond its abilities, and be forced to use other tools. In my view, Thimble should be able to grow and expand along with a learner's abilities, and a teacher's needs.

Second, people were asking for lots of new features in Thimble, and I knew from experience that the best code is code you don't have to write. I wanted to leverage the hard work of an existing community that was already focused on building a great web coding platform. Writing a coding environment is a huge challenge, and our team wasn't equipped to take it on by ourselves. Thankfully the Brackets project had already solved this.

On Brackets

Brackets was an easy codebase to get started on, and the community was encouraging and willing to help us with patches, reviews, and questions (I'm especially thankful for @randyedmunds and @busykai).

Brackets is written in an AMD module system, and uses requirejs, react, CodeMirror, LESS, jQuery, Bootstrap, loadash, acorn, tern, etc. One of the things I've loved most about working with the Brackets source is that it uses so much of the the best of the open web. It's ~1.3 million lines of code offer APIs for things things like:

  • code hinting, static analysis, and linting
  • language parsing and tokenizing (html, css, js, xml, less)
  • file system operations
  • editors
  • live DOM diff'ing and in-browser preview
  • swappable servers
  • layout, widgets, and dialogs
  • localization, theming, and preferences
  • extension loading at runtime, with hundreds already written

In short, Brackets isn't an editor so much as a rich platform for coding and designing front-end web pages and apps. Bracket's killer feature is its ability to render a live preview of what's in your editor, including dynamic updates as you type, often without needing to save. The preview even has an awareness of changes to linked files (e.g., external stylesheets and scripts).

Another thing I loved was that Brackets wasn't trying to solve code editing in general: they had a very clear mandate that favoured web development, and front-end web development in particular. HTML, CSS, and JavaScript get elevated status in Brackets, and don't have to fight with every other language for features.

All of these philosophies and features melded perfectly with our goal of making a great learning and teaching tool for web programming.

But what about X?

Obviously there are a ton of code editing tools available. If we start with desktop editors, there are a lot to choose from; but they all suffer from the same problem: you have to download 10s of megs of installer, and then you have to install them, along with a web server, in order to preview your work. Consider what's involved in installing each of these (on OS X):

Thimble, on the other hand, is ~1M (877K for Bramble, the rest for the front-end app). We worked extremely hard to get Brackets (38.5M if you install it) down to something that fits in the size of an average web page. If we changed how Brackets loads more significantly, we could get it smaller yet, but we've chosen to keep existing extensions working. The best part is that there is no install: the level of commitment for a user is the URL.

In addition to desktop editors, there are plenty of popular online options, too:

The list goes on. They are all great, and I use, and recommend them all. Each of these tools has a particular focus, and none of them do exactly what the new Thimble does; specifically, none of them tries to deal with trees of files and folders. We don't need to do what these other tools do, because they already do it well. Instead, we focused on making it possible for users to create a rich and realistic environment for working with arbitrary web site/app structures without needing to install a and run a web server.

From localhost to nohost

I've always been inspired by @jswalden's httpd.js. It was written back before there was node.js, back in a time when it wasn't yet common knowledge that you could do anything in JS. The very first time I saw it I knew that I wanted to find some excuse to make a web server in the browser. With nohost, our in-browser web server, we've done it.

In order to run in a browser, Bramble has to be more than just a code editor; it also has to include a bunch of stuff that would normally be provided by the Brackets Shell (similar to and node.js. This means providing a:

  • web server
  • web browser
  • filesystem

and glue to connect those three. Bracket's uses Chrome's remote debugging protocol and node.js to talk between the editor, browser, and server. This works well, but ties it directly to Chrome.

At first I wasn't sure how we'd deal with this. But then an experimental implementation of the Bracket's LiveDevelopment code landed, which switched away from using Chrome and the remote dev tools protocol to any browser and a WebSocket. Then, in the middle of the docs, we found an offhand comment that someone could probably rewrite it to use an iframe and postMessage...a fantastic idea! So we did.

Making it possible for an arbitrary web site to work in a browser-based environment is a little like Firefox's Save Page... feature. You can't just deal with the HTML alone--you also have to get all the linked assets.

Consider an example web page:

<!DOCTYPE html>  
   <meta charset="utf-8">
    <title>Example Page</title>
    <link rel="stylesheet”
    <img src="images/cat.png">
    <script src="script.js"></script>
      // Call function f in script.js

In this basic web page we have three external resources referenced by URL. The browser needs to be able to request styles/style.css, images/cat.png, and script.js in order to fully render this page. And we're not done yet.

The stylesheet might also reference other stylesheets using @import, or might use other images (e.g., background-image: url(...)).

It gets worse. The script might need to XHR a JSON file from the server in order to do whatever f() requires.

Bramble tries hard to deal with these situations through a combination of static and dynamic rewriting of the URLs. Eventually, if/when all browsers ship it, we could do a lot of this with ServiceWorkers. Until then, we made do with what we already have cross browser.

First, Bramble's nohost server recursively rewrites the HTML, and its linked resources, in order to find relative filesystem paths (images/cat.png) and replace them with Blobs and URL objects that point to cached memory resources read out of the browser filesystem.

Parsing HTML with regex is a non-starter. Luckily browsers have a full parser built in, DOMParser. Once we have an in memory DOM vs. HTML text string, we can accurately querySelectorAll to find things that might contain URLs (img, link, video, iframe, etc., avoiding a due to circular references) and swap those for generated Blob URLs from the filesystem. When we're done, we can extract rewritten HTML text from our live in-memory DOM via documentElement.outerHTML, obtaining something like this:

<!DOCTYPE html>  
   <meta charset="utf-8">
    <title>Example Page</title>
    <link rel="stylesheet”
    <img src="blob:https%3A//">
    <script src="blob:https%3A//"></script>
      // Call function f in script.js

All external resources now use URLs to cached memory resources. This HTML can then be itself turned into a Blob and URL object, and used as the src for our iframe browser (this works everywhere except IE, where you have to document.write the HTML, but can use Blob URLs for everything else).

For CSS we do use regex, looking for url(...) and other places where URLs can lurk. Thankfully there aren't a lot, and it's just a matter of reading the necessary resources from disk, caching to a Blob URL, and replacing the filesystem paths for URLs, before generating a CSS Blob URL that can be used in the HTML.

Despite what everyone tells you about the DOM being slow, the process is really fast. And because we own the filesystem layer, whenever the editor does something like a writeFile(), we can pre-generate a URL for the resource, and maintain a cache of such URLs keyed on filesystem paths for when we need to get them again in the future during a rewrite step. Using this cache we are able to live refresh the browser quite often without causing any noticeable slowdown on the main thread.

As an aside, it would be so nice if we could move the whole thing to a worker and be able to send an HTML string, and get back a URL. Workers can already access IndexedDB, so we could read from the filesystem there, too. This would mean having access to DOMParser (even if we can't touch the main DOM from a worker, being able to parse HTML is still incredibly useful for rewriting, diff'ing, etc).

Finally, we do dynamic substitutions of relative paths for generated Blob URLs at runtime by hijacking XMLHttpRequest and using our postMessage link from the iframe to the editor in order to return response data for a given filename.

And it all works! Sure, there's lots of things we won't ever be able to cope with, from synchronous XHR to various types of DOM manipulation by scripts that reference URLs as strings. But for the general case, it works remarkably well. Try downloading and dragging a zipped web site template from into the editor. Bramble doesn't claim to be able to replace a full, local development environment for every use case; however, it makes it unnecessary in most common cases. It's amazing what the modern web can do via storage, file, drag-and-drop, parser, and worker APIs.

Origin Sandboxing

I talk about Thimble and Bramble as different things, and they are, especially at runtime. Bramble is an embeddable widget with an iframe API, and Thimble hosts it and provides some UI for common operations.

I've put a simple demo of the the Bramble API online for people to try (source is here). Bramble uses, but doesn't own its filesystem; nor does it have any notion of where the files came from or where they are going. It also doesn't have opinions about how the filesystem should be laid out.

This is all done intentionally so that we can isolate the editor and preview from the hosting app, running each on a different domain. We want users to be able to write arbitrary code, execute and store it; but we don't want to mix code for the hosting app and the editor/preview. The hosting app needs to decide on a filesystem layout, get and write the files, and then "boot" Bramble.

I've written previously about how we use MessageChannel to remotely host an IndexedDB backed filesystem in a remote window running on another domain: Thimble owns the filesystem and database and responds to proxied requests to do things via postMessage.

In the case of Thimble, we store data in a Heroku app using postgres on the server. Thimble listens for filesystem events, and then queues and executes file update requests over the network to sync the data upstream. Published projects are written to S3, and we then serve them on a secure domain. Because users can upload files to their filesystem in the editor, it makes it easier to transition to an https:// only web.

When the user starts Thimble, we request a project as a gzipped tarball from the publishing server, then unpack it in a Worker and recreate the filesystem locally. Bramble then "mounts" this local folder and begins working with the local files and folders, with no knowledge of the servers (all data is autosaved, and survives refreshes).


Now that we've got the major pieces in place, I'm interested to see what people will do with both Thimble and Bramble. Because we're in a full browser vs. an "almost-browser" shell, we have access to all the latest toys (for example, WebRTC and the camera). Down the road we could use this for some amazing pair programming setups, so learners and mentors could work with each other directly over the web on the same project.

We can also do interesting things with different storage providers. It would be just as easy to have Bramble talk to Github, Dropbox, or some other cloud storage provider. We intentionally kept Thimble and Bramble separate in order to allow different directions in the future.

Then there's all the possibilities that custom extensions opens up (did I mention that Bramble has dynamic extension loading? because it does!). I'd love to see us use bundles of extensions to enable different sorts of learning activities, student levels, and instructional modes. I'm also really excited to see what kind of new curriculum people will build using all of this.

In the meantime, please try things out, file bugs, chat with us on irc #thimble on moznet and have fun making something cool with just your browser. Even better, teach someone how to do it.

Let me close by giving a big shout out to the amazing students (current and former) who hacked on this with me. You should hire them: Gideon Thomas, Kieran Sedgwick, Kenny Nguyen, Jordan Theriault, Andrew Benner, Klever Loza Vega, Ali Al Dallal, Yoav Gurevich, as well as the following top notch Mozilla folks, who have been amazing to us: Hannah Kane, Luke Pacholski, Pomax, Cassie McDaniel, Ashley Williams, Jon Buckley, and others.

Planet MozillaES6 for now: Template strings

ES6 is the future of JavaScript and it is already here. It is a finished specification, and it brings a lot of features a language requires to stay competitive with the needs of the web of now. Not everything in ES6 is for you and in this little series of posts I will show features that are very handy and already usable.

If you look at JavaScript code I’ve written you will find that I always use single quotes to define strings instead of double quotes. JavaScript is OK with either, the following two examples do exactly the same thing:

var animal = "cow";
var animal = 'cow';

The reason why I prefer single quotes is that, first of all, it makes it easier to assemble HTML strings with properly quoted attributes that way:

// with single quotes, there's no need to 
// escape the quotes around the class value
var but = '<button class="big">Save</button>';
// this is a syntax error:
var but = "<button class="big">Save</button>";
// this works:
var but = "<button class=\"big\">Save</button>";

The only time you need to escape now is when you use a single quote in your HTML, which should be a very rare occasion. The only thing I can think of is inline JavaScript or CSS, which means you are very likely to do something shady or desperate to your markup. Even in your texts, you are probably better off to not use a single quote but the typographically more pleasing ‘.

Aside: Of course, HTML is forgiving enough to omit the quotes or to use single quotes around an attribute, but I prefer to create readable markup for humans rather than relying on the forgiveness of a parser. We made the HTML5 parser forgiving because people wrote terrible markup in the past, not as an excuse to keep doing so.

I’ve suffered enough in the DHTML days of document.write to create a document inside a frameset in a new popup window and other abominations to not want to use the escape character ever again. At times, we needed triple ones, and that was even before we had colour coding in our editors. It was a mess.

Expression substition in strings?

Another reason why I prefer single quotes is that I wrote a lot of PHP in my time for very large web sites where performance mattered a lot. In PHP, there is a difference between single and double quotes. Single quoted strings don’t have any substitution in them, double quoted ones have. That meant back in the days of PHP 3 and 4 that using single quotes was much faster as the parser doesn’t have to go through the string to substitute values. Here is an example what that means:

  $animal = 'cow';
  $sound = 'moo';
  echo 'The animal is $animal and its sound is $sound';
  // => The animal is $animal and its sound is $sound
  echo "The animal is $animal and its sound is $sound";
  // => The animal is cow and its sound is moo

JavaScript didn’t have this substitution, which is why we had to concatenate strings to achieve the same result. This is pretty unwieldy, as you need to jump in and out of quotes all the time.

var animal = 'cow';
var sound = 'moo';
alert('The animal is ' + animal + ' and its sound is ' +
// => "The animal is cow and its sound is moo"

Multi line mess

This gets really messy with longer and more complex strings and especially when we assemble a lot of HTML. And, most likely you will sooner or later end up with your linting tool complaining about trailing whitespace after a + at the end of a line. This is based on the issue that JavaScript has no multi-line strings:

// this doesn't work
var list = '<ul>
  <li>Buy Milk</li>
  <li>Be kind to Pandas</li>
  <li>Forget about Dre</li>
// This does, but urgh… 
var list = '<ul>\
  <li>Buy Milk</li>\
  <li>Be kind to Pandas</li>\
  <li>Forget about Dre</li>\
// This is the most common way, and urgh, too…
var list = '<ul>' +
'  <li>Buy Milk</li>' +
'  <li>Be kind to Pandas</li>' +
'  <li>Forget about Dre</li>' +

Client side templating solutions

In order to work around the mess that is string handling and concatenation in JavaScript, we did what we always do – we write a library. There are many HTML templating libraries with Mustache.js probably having been the seminal one. All of these follow an own – non standardised – syntax and work in that frame of mind. It’s a bit like saying that you write your content in markdown and then realising that there are many different ideas of what “markdown” means.

Enter template strings

With the advent of ES6 and its standardisation we now can rejoice as JavaScript has now a new kid on the block when it comes to handling strings: Template Strings. The support of template strings in current browsers is encouraging: Chrome 44+, Firefox 38+, Microsoft Edge and Webkit are all on board. Safari, sadly enough, is not, but it’ll get there.

The genius of template strings is that it uses a new string delimiter, which isn’t in use either in HTML nor in normal texts: the backtick (`).

Using this one we now have string expression substitution in JavaScript:

var animal = 'cow';
var sound = 'moo';
alert(`The animal is ${animal} and its sound is ${sound}`);
// => "The animal is cow and its sound is moo"

The ${} construct can take any JavaScript expression that returns a value, you can for example do calculations, or access properties of an object:

var out = `ten times two totally is ${ 10 * 2 }`;
// => "ten times two totally is 20"
var animal = {
  name: 'cow',
  ilk: 'bovine',
  front: 'moo',
  back: 'milk',
  The ${} is of the 
  ${animal.ilk} ilk, 
  one end is for the ${animal.front}, 
  the other for the ${animal.back}
// => 
  The cow is of the 
  bovine ilk, 
  one end is for the moo, 
  the other for the milk

That last example also shows you that multi line strings are not an issue at all any longer.

Tagged templates

Another thing you can do with template strings is prepend them with a tag, which is the name of a function that is called and gets the string as a parameter. For example, you could encode the resulting string for URLs without having to resort to the horridly named encodeURIComponent all the time.

function urlify (str) {
  return encodeURIComponent(str);
urlify ``;
// => ""
urlify `woah$£$%£^$"`;
// => "woah%24%C2%A3%24%25%C2%A3%5E%24%22"
// nesting also works:
var str = `foo ${urlify `&&`} bar`;
// => "foo %26%26 bar"

This works, but relies on implicit array-to-string coercion. The parameter sent to the function is not a string, but an array of strings and values. If used the way I show here, it gets converted to a string for convenience, but the correct way is to access the array members directly.

Retrieving strings and values from a template string

Inside the tag function you can not only get the full string but also its parts.

function tag (strings, values) {
tag `you ${3+4} it`;
/* =>
Array [ "you ", " it" ]

There is also an array of the raw strings provided to you, which means that you get all the characters in the string, including control characters. Say for example you add a linebreak with \n you will get the double whitespace in the string, but the \n characters in the raw strings:

function tag (strings, values) {
tag `you ${3+4} \nit`;
/* =>
Array [ "you ", "  it" ]


Template strings are one of those nifty little wins in ES6, that can be used right now. If you have to support older browsers, you can of course transpile your ES6 to ES5, you can do a feature test for template string support using a library like or with the following code:

var templatestrings = false;
try {
  new Function( "`{2+2}`" );
  templatestrings = true;
} catch (err) {
  templatestrings = false;
if (templatestrings) {
	// …

More articles on template strings:

Tantek Çelikupdated @CSSWG meeting to demo :-moz-ui-invalid, :-moz-ui-valid, and :user-changed polyfilled to work while modifying the input (typing, paste, etc.) before clicking outside. Note that :-moz-ui-invalid already only triggers *after* the user leaves the input, thus acting as a warning to the user that they need to go back and fix something, instead of interrupting them while they're typing. However for the valid case, as soon as the user has entered something valid, you want to give them positive feedback thus letting them know they can take the next step (leave the input, submit the form, etc.). References: * * * * *

updated @CSSWG meeting to demo :-moz-ui-invalid, :-moz-ui-valid, and :user-changed polyfilled to work while modifying the input (typing, paste, etc.) before clicking outside.

Note that :-moz-ui-invalid already only triggers *after* the user leaves the input, thus acting as a warning to the user that they need to go back and fix something, instead of interrupting them while they're typing.

However for the valid case, as soon as the user has entered something valid, you want to give them positive feedback thus letting them know they can take the next step (leave the input, submit the form, etc.).


Anne van KesterenStatement regarding the URL Standard

The goal of the URL Standard is to reflect where all implementations will converge. It should not describe today’s implementations as that will not lead to convergence. It should not describe yesterday’s implementations as that will also not lead to convergence. And it should not describe an unreachable ideal, e.g., by requiring something that is known to be incompatible with web content.

This is something all documents published by the WHATWG have in common, but I was asked to clarify this for the URL Standard in particular. Happy to help!

Planet MozillaMultilingual slides in HTML5 Mozilla Sandstone slidedeck

Edit: You can now preview the changes live. Also, the pull request got accepted!

I just submitted a GitHub PR for adding multilingual support to Mozilla’s HTML5 Sandstone slidedeck. The selection is persistent across slide changes, and in Firefox, the URL bar will update the lang attribute as well.

Pictures are worth thousands of words, so here you go:

Screenshot showing language menu dropdown

Screenshot showing language menu dropdown

To add languages:

  1. Add the style tags to the stylesheet
  2. Modify the language menu
  3. Place your translation within <div> tags with language code class names
Screenshot showing slide after language selection

Slide after language selection

Example code:

<div class=”en-US”>This is English.</div>
<div class=”zh-CN”>这是中文(简体)。</div>
<div class=”zh-TW”>這是中文(繁體)。</div>
<div class=”ja-JP”>これは日本語です。</div>

Screenshot showing the next slide with persistent language selection change

Next slide with persistent language selection change

If you would like to use this now, my changes are on a GitHub fork.

Massive thanks go out to :MattN who greatly helped me out. Thanks Matt!


Updated: .  Michael(tm) Smith <>