Decoded chats the fifth: Ada Rose Edwards on Progressive Web Apps

A few weeks after I pestered Ada Rose Edwards to write her first Smashing Magazine article on Progressive Web Apps I did a Skype call with her to talk about the same topic.

You can see the video and get the audio recording of our chat over at the Decoded blog:

ada video interviww

Ada is a great talent in our market and I am looking forward to pestering her to do more of these good things.

Here are the questions we covered:

  1. Ada, you just wrote on Smashing Magazine about “The building blocks of progressive web apps”. Can you give a quick repeat on what they are?
  2. We’ve had a few attempts at using web technology to build app like experiences. A lot of them left end users disappointed. What do you think were the main mistakes developers did?
  3. Is the “app shell” model a viable one or is this against the idea of “content first” web sites turning into apps?
  4. You worked on one of the poster-child web-technology based apps in the past – the Financial Times app. What were the main challenges you faced there?
  5. It seems that in the mobile space it is OK to abandon platforms that arent’ used much any longer, should that be something to consider for the web and browsers, too?
  6. Progressive Web apps do away with the concept of a need of an app store. This is more convenient, but it also poses a UX challenge. Users aren’t expecting a web site to work offline. What can we do to break that assumption?
  7. The wonderful thing about PWAs is that they are progressive, which means that platforms that don’t support ServiceWorkers should still have a good experience and fall back to a classic “add to homescreen” scenario. What can we do to avoid people forgetting about this and build “this app needs Chrome on latest Android” apps instead?
  8. Are responsive interfaces a unique skill of web developers? Is it something we learned simply because of the nature of the platform?
  9. The distribution model of PWAs is the hyperlink. You pointed out rightfully in your article that there needs to be a way to share this link and send it to others. Hardliners of the web also argue that a URL should be visible and “hackable”. Do you think this is a valid need?
  10. What about Instant Apps on Android? Aren’t they a threat to Progressive Web Apps?
  11. What can we do to avoid PWAs becoming the new “”? The average web site it too big and slow to become and app. How high are your hopes that this new approach could help the web as a whole become slimmer?

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Progressive Web Apps and our regressive approach

Tractor at airport
Custom made, cute, but not reusable

In the weeks following Google IO there was a lot of discussion about progressive web apps, Android instant Apps and the value and role of URLs and links in the app world. We had commentary, ponderings, Pathos, explanation of said Pathos after it annoyed people and an excellent round-up on where we stand with web technology for apps.

My favourite is Remy Sharp’s post which he concludes as:

I strongly believe in the concepts behind progressive web apps and even though native hacks (Flash, PhoneGap, etc) will always be ahead, the web, always gets there. Now, today, is an incredibly exciting time to be build on the web.

PWAs beat anything we tried so far

As a card-carrying lover of the web, I am convinced that PWAs are a necessary step into the right direction. They are a very important change. So far, all our efforts to crack the advertised supremacy of native apps over the web failed. We copied what native apps did. We tried to erode the system from within. We packaged our apps and let them compete in closed environments. The problem is that they couldn’t compete in quality. In some cases this might have been by design of the platform we tried to run them on. A large part of it is that “the app revolution” is powered by the age old idea of planned obsolesence, something that is against anything the web stands for.

I made a lot of points about this in my TEDx talk “The Web is dead” two years ago:

We kept trying to beat native with the promises of the web: its open nature, its easy distribution, and its reach. These are interesting, but also work against the siren song of apps on mobile: that you are in control and that you can sell them to an audience of well-off, always up-to-date users. Whether this is true or not was irrelevant – it sounded great. And that’s what we need to work against. The good news is that we now have a much better chance than before. But more on that later.

Where to publish if you need to show quick results?

Consider yourself someone who is not as excited about the web as we are. Imagine being someone with short-term goals, like impressing a VC. As a publisher you have to make a decision what to support:

  • iOS, a platform with incredible tooling, a predictable upgrade strategy and a lot of affluent users happy to spend money on products.
  • Android, a platform with good tooling, massive fragmentation, a plethora of different devices on all kind of versions of the OS (including custom ones by hardware companies) and users much less happy to spend money but expecting “free” versions
  • The web, a platform with tooling that’s going places, an utterly unpredictable and hard to measure audience that expects everything for free and will block your ads and work around your paywalls.

If all you care about is a predictable audience you can do some budgeting for, this doesn’t look too rosy for Android and abysmal for the web. The carrot of “but you can reach millions of people” doesn’t hold much weight when these are not easy to convert to paying users.

To show growth you need numbers. You don’t do that by being part of a big world of links and resources. You do that by locking people in your app. You do it by adding a webview so links open inside it. This is short-sighted and borderline evil, but it works.

And yes, we are in this space. This is not about what technology to use, this is not about how easy it is to maintain your app. This is not about how affordable developers would be. The people who call the shots in the app market and make the money are not the developers. They are those who run the platforms and invest in the companies creating the apps.

The app honeymoon period is over

The great news is that this house of cards is tumbling. App download numbers are abysmally low and the usage of mobiles is in chat clients, OS services and social networks. The closed nature of marketplaces works heavily against random discovery. There is a thriving market of fake reviews, upvotes, offline advertising and keyword padding that makes the web SEO world of the last decade look much less of the cesspool we remember. End users are getting tired of having to install and uninstall apps and continuously get prompts to upgrade them.

This is a great time to break into this model. That Google finally came up with Instant Apps (after promising atomic updates for years) shows that we reached the breaking point. Something has to change.

Growth is on mobile and connectivity issues are the hurdle

Here’s the issue though: patience is not a virtue of our market. To make PWAs work, bring apps back to the web and have the link as the source of distribution instead of closed marketplaces we need to act now. We need to show that PWAs solve the main issue of the app market: that the next users are not in places with great connectivity, and yet on mobile devices.

And this is where progressive web apps hit the sweet spot. You can have a damn small footprint app shell that gets sweet and easy to upgrade content from the web. You control the offline experience and what happens on flaky connections. PWAs are a “try before you buy”, showing you immediately what you get before you go through the process of adding it to your home screen or download the whole app. Exactly what Instant Apps are promising. Instant Apps have the problem that Android isn’t architected that way and that developers need to change their approach. The web was already built on this idea and the approach is second nature to us.

PWAs need to succeed on mobile first

The idea that a PWA is progressively enhanced and means that it could be a web site that only converts in the right environment is wonderful. We can totally do that. But we shouldn’t pretend that this is the world we need to worry about right now. We can do that once we solved the issue of web users not wanting to pay for anything and show growth numbers on the desktop. For now, PWAs need to be the solution for the next mobile users. And this is where we have an advantage over native apps. Let’s use that one.

Open questions

Of course, there are many issues to consider:

  • How do PWAs work with permissions? Can we ask permissions on demand and what happens when users revoke them? Instant apps have that same issue.
  • How do I uninstall a PWA? Does removing the icon from my homescreen free all the data? Should PWAs have a memory management control?
  • What about URLs? Should they display or not? Should there be a long-tap to share the URL? Personally, I’d find a URL bar above an app confusing. I never “hacked” the URL of an app – but I did use “share this app” buttons. With a PWA, this is sending a URL to friends, and that’s a killer feature.
  • How do we deal with the issue of iOS not supporting Service Workers? What about legacy and third party Android devices? Sure, PWAs fall back to normal HTML5 apps, but we’ve seen them not taking off in comparison to native apps.
  • What are the “must have” features of native apps that PWAs need to match? Those people want without being a hurdle or impossible to implement?

These are exciting times and I am looking forward to PWAs being the wedge in the cracks that are showing in closed environments. The web can win this, but we won’t get far if we demand features that only make sense on desktop and are in use by us – the experts. End users deserve to have an amazing, form-factor specific experience. Let’s build those. And for the love of our users, let’s build apps that let them do things and not only consume them. This is what apps are for.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Offline Web Apps on GitHub Pages

Service Workers are a response to the problems of Application Cache, and they’re a powerful and elegant way to offline your web app. But they’re also more complex to implement and maintain.

Meanwhile, GitHub Pages is a great, simple static host for offline-first apps. But deploying apps to GitHub Pages requires manual configuration, especially if you develop with a team, utilize some variant of the GitHub Flow, and want to set up continuous deployment.

Oghliner is an npm package that simplifies both offlining an app with Service Workers and deploying the app to GitHub Pages (including continuous deployment using Travis CI). Oghliner’s goal is to make it as simple as possible to offline and deploy a web app.

To start using Oghliner, install it globally:

> npm install --global oghliner

If you have an existing app in a GitHub repository, invoke the integrate command to configure it. That command copies an offline-manager.js script (which registers the service worker) into your app and reminds you to load that script in your app’s page(s)/template(s) (one of the few steps that Oghliner doesn’t yet automate).

> oghliner integrate
Integrating Oghliner into the app in the current directory…

? Copying offline-manager.js to ./… done!

Oghliner has been integrated into the app!

The app needs to load the script offline-manager.js in order to register
the service worker that offlines the app. To load the script, add this line to 
the app's HTML page(s)/template(s):

<script src="offline-manager.js"></script>

And commit the changes and push the commit to the origin/master branch:

git commit -m"integrate Oghliner" --all
git push origin master

Then you can offline and deploy the app using the offline and deploy commands.

? For more information about offlining and deployment, see:

If you don’t yet have an existing app, start a new app by creating a new repository on GitHub, cloning it to your local machine, and invoking the bootstrap command from its working directory.

> git clone
Cloning into 'offline-app'...
> cd offline-app/
> oghliner bootstrap
Bootstrapping current directory as Oghliner app…

Your app's configuration is:

Name: offline-app
Description: A template app bootstrapped with oghliner.
License: Apache-2.0

Would you like to change its configuration (y/N)? 

Creating files…
? Creating
? Creating .gitignore
? Creating gulpfile.js
? Creating package.json
? Creating app/favicon.ico
? Creating app/fonts
? Creating app/index.html
? Creating app/robots.txt
? Creating app/images/apple-touch-icon-114x114.png
? Creating app/images/apple-touch-icon-120x120.png
? Creating app/images/apple-touch-icon-144x144.png
? Creating app/images/apple-touch-icon-152x152.png
? Creating app/images/apple-touch-icon-57x57.png
? Creating app/images/apple-touch-icon-60x60.png
? Creating app/images/apple-touch-icon-72x72.png
? Creating app/images/apple-touch-icon-76x76.png
? Creating app/images/favicon-128x128.png
? Creating app/images/favicon-16x16.png
? Creating app/images/favicon-196x196.png
? Creating app/images/favicon-32x32.png
? Creating app/images/favicon-96x96.png
? Creating app/images/mstile-144x144.png
? Creating app/images/mstile-150x150.png
? Creating app/images/mstile-310x150.png
? Creating app/images/mstile-310x310.png
? Creating app/images/mstile-70x70.png
? Creating app/scripts/main.js
? Creating app/scripts/offline-manager.js
? Creating app/styles/stylesheet.css

? Creating files… done!
? Installing npm dependencies… done!

Your app has been bootstrapped! Just commit the changes and push the commit
to the origin/master branch:

git add --all && git commit -m"initial version of Oghliner app"
git push origin master

Then you can build, offline, and deploy the app using gulp commands.

? For more information about building, offlining and deployment, see:

Finally, commit the changes to complete the configuration.

> git add --all && git commit -m"initial version of Oghliner app"

Now that your app is configured, you can build, offline, and deploy it. Bootstrapped apps include a gulpfile.js build script. To build them, install Gulp globally:

> npm install --global gulp

Then simply invoke gulp:

> gulp

To offline your app, invoke the offline command to generate the service worker that offlines your app, specifying the directory containing the files to offline.

> oghliner offline dist/
Offlining dist/ to dist/offline-worker.js…

? Caching "dist/favicon.ico" (384 B)
? Caching "dist/images/apple-touch-icon-114x114.png" (278 B)
? Caching "dist/images/apple-touch-icon-120x120.png" (285 B)
? Caching "dist/images/apple-touch-icon-144x144.png" (321 B)
? Caching "dist/images/apple-touch-icon-152x152.png" (320 B)
? Caching "dist/images/apple-touch-icon-57x57.png" (242 B)
? Caching "dist/images/apple-touch-icon-60x60.png" (242 B)
? Caching "dist/images/apple-touch-icon-72x72.png" (247 B)
? Caching "dist/images/apple-touch-icon-76x76.png" (247 B)
? Caching "dist/images/favicon-128x128.png" (298 B)
? Caching "dist/images/favicon-16x16.png" (216 B)
? Caching "dist/images/favicon-196x196.png" (380 B)
? Caching "dist/images/favicon-32x32.png" (232 B)
? Caching "dist/images/favicon-96x96.png" (269 B)
? Caching "dist/images/mstile-144x144.png" (323 B)
? Caching "dist/images/mstile-150x150.png" (316 B)
? Caching "dist/images/mstile-310x150.png" (411 B)
? Caching "dist/images/mstile-310x310.png" (610 B)
? Caching "dist/images/mstile-70x70.png" (246 B)
? Caching "dist/index.html" (3.08 kB)
? Caching "dist/robots.txt" (102 B)
? Caching "dist/scripts/main.js" (151 B)
? Caching "dist/scripts/offline-manager.js" (1.1 kB)
? Caching "dist/styles/stylesheet.css" (107 B)
Total precache size is about 10.41 kB for 24 resources.

To deploy the app (including the service worker) to GitHub Pages, invoke the deploy command, again specifying the directory containing your app’s files.

> oghliner deploy dist/
Deploying "initial version of Oghliner app" to GitHub Pages…

? Cloning into .gh-pages-cache… done!
? Cleaning… done!
? Fetching origin… done!
? Checking out origin/gh-pages… done!
? Removing files… done!
? Copying files… done!
? Adding all… done!
? Committing… done!
? Pushing… done!

All Oghliner commands are also available via a module interface, so you can integrate them into your Node-based build scripts using tools like Grunt and Gulp. If you bootstrapped your app using Oghliner, its gulpfile.js already has offline and deploy tasks (which you can also use as an alternative to the previous commands).

Finally, invoke the configure command to configure an app to automatically deploy to GitHub Pages using Travis CI whenever you merge a change into your app’s master branch (provided the build completes successfully and tests pass, of course!).

> oghliner configure

Configuring Travis to auto-deploy to GitHub Pages…

Your repository has a single remote, origin.
Ok, I'll configure Travis to auto-deploy the origin remote (mykmelez/offline-app).

To check the status of your repository in Travis and authorize Travis to push
to it, I'll create GitHub personal access tokens, for which I need your GitHub
username and password (and two-factor authentication code, if appropriate).

? For more information about GitHub personal access tokens, see:

Username: mykmelez

× Checking credentials… error!

You're using two-factor authentication with GitHub.
Please enter the code provided by your authentication software.

Auth Code: 123456

? Checking credentials… done!
? Creating temporary GitHub token for getting Travis token… done!
? Getting Travis token… done!
? Deleting temporary GitHub token for getting Travis token… done!
  Creating permanent GitHub token for Travis to push to the repository…
? Creating permanent GitHub token for Travis to push to the repository… done!

? You had an existing token for this app, so we deleted and recreated it.

? Checking the status of your repository in Travis… done!

Good news, your repository is active in Travis!

? Encrypting permanent GitHub token… done!
? Writing configuration to .travis.yml file… done!

? You didn't already have a .travis.yml file, so I created one for you.
  For more information about the file, see:

You're ready to auto-deploy using Travis!  Just commit the changes
in .travis.yml and push the commit to the origin/master branch:

git add .travis.yml
git commit -m"configure Travis to auto-deploy to GitHub Pages" .travis.yml
git push origin master

Then visit to see the build status.

Travis will then deploy successful builds (on the master branch):

Travis auto-deploys to GitHub Pages

A few caveats to note:

  • Deployments sometimes take a few minutes to show up on GitHub Pages.
  • Service Workers require that you load the app over an encrypted (HTTPS) connection. All GitHub Pages can be loaded over such a connection, even though GitHub does not officially support it.
  • Service Workers are available in Chrome, Opera, and the Developer Edition of Firefox. They’ll ship in Firefox 44.

Mozilla’s Web App Developer Initiative engineering team built Oghliner because we think Service Workers are a great way to offline web apps, and GitHub Pages are a great way to deploy them, so we wanted to see how much better the combination could be.

We’ve used Oghliner in our own projects, like this presentation and Platatus, and we hope you find it delightful. So learn more about it, try it out, and let us know how it works for you!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Building RTL-Aware Web Apps & Websites: Part 2

Pushing the Web forward means making it better for developers and users alike. It means tackling issues that our present Web faces; this is especially true for making responsive RTL design and development easier to achieve.

Before we move on to bleeding edge RTL topics, here’s a video tutorial with a practical example to refresh your mind on how to code RTL properly today:


Picking up where we left off in our last post, it’s time to dive into some advanced topics around Right-To-Left UI implementation. In Part 1 we covered the basics of RTL. In this second post we will cover how-tos for bidirectional (BIDI) user interfaces on the bleeding edge. This is the alpha state of the Web, and we can take a look at what the future of RTL holds in store.

RTL on the bleeding edge

The core of RTL UI design and development on the Web is found in CSS properties and, as with every other aspect of web development, these properties keep improving over time.

Here are the CSS properties you can start using today in alpha versions of several modern browsers. (This information is likely to change as browser updates are released.):

Text alignment: In the past we used to explicitly set the horizontal alignment of text with text-align left or right (e.g. text-align: left). We now have start and end values that can be used instead. For instance, text-align: start will give a different result depending on whether the content is set to RTL or LTR. start indicates left in LTR and right in RTL, and vice versa for end.

Example using left/right:

#content {
  text-align: left:
html[dir="rtl"] #content {
  text-align: right;

Example using start/end:

#content {
  text-align: start;

With start/end, there’s no need for an RTL rule.
Browser support: Chrome 1.0+, Safari 3.1+, Firefox 3.6+, Android, iOS. Not supported by Internet Explorer at this time.

Padding, margin, and border: there are a couple of improvements regarding these properties.
Each of them now can take an additional suffix of -inline-start or -inline-end, for example you can write padding-inline-end or margin-inline-start. These new keywords give the same result as start and end in text alignment: padding-inline-start equates to padding-left in LTR and is padding-right in RTL. margin-inline-end gives the effect of margin-right in LTR and margin-left in RTL.

Example using left/right:

#content {
  padding-left: 12px:
  margin-right: 20px;
html[dir="rtl"] #content {
  padding-left: 0;
  padding-right: 12px;
  margin-left: 20px;
  margin-right: 0px;

Example using start/end:

#content {
  padding-inline-start: 12px:
  margin-inline-end: 20px;

Again, there’s no need for an RTL rule; margin-inline-end will act as margin-right in LTR and act as margin-left for RTL, for example.
Browser support: Firefox 41+ only.

Absolute positioning: left and right are CSS properties that have always been key to absolute positioning, but very soon you’ll be writing much smarter CSS for your users with the new offset-inline-start and offset-inline-end properties.

It is also worth mentioning that top and bottom can be substituted by offset-block-start and offset-block-end.

Example using left/right:

#content {
  position: absolute;
  left: 5rem;
html[dir="rtl"] #content {
  left: auto;
  right: 5rem;

Example using start/end:

#content {
  offset-inline-start: 5rem;

Once again, the start/end concept has saved us a rule in our CSS file.
Browser support: Firefox 41+ only.

Floats: float: left and float: right have been around and used for a long time, but very soon you will be able to use float: inline-start and float: inline-end in Firefox Nightly. inline-start will float your element left in an left-to-right (LTR) layout, and right in a right-to-left (RTL) layout.

Example using start/end:

#content {
  float: left;
html[dir="rtl"] #content {
  float: right;

Using start/end:

#content {
  float: inline-start;

Browser support: Firefox 44 (soon to land in Firefox Nightly).

Firefox OS gives you a great opportunity to try some of the very latest CSS property implementations — there is a reference page on the Mozilla Wiki for all the new BIDI-relevant CSS properties and values.

Web components: Web components are reusable user interface widgets (see MDN for more information). If you’ve worked with web components you’ll know that CSS styles defined inside the shadow DOM are scoped, so by default you can’t get the direction of the overall page from the component’s scoped CSS using html[dir=”rtl”]. However, the shadow DOM introduces a new selector called :host-context(), which can be used to select a shadow host element based on a matching parent element.

Let’s make this clearer with an example — say you have an element inside your shadow DOM tree with a class name called back. In a normal situation where there isn’t a shadow DOM you would just use html[dir=”rtl”] .back {}, however you can’t use this syntax from inside a web component. Scoped and encapsulated, remember? The equivalent selector when .back is inside a web component scope would look like this:

.back:host-context(html[dir="rtl"]) { }

The exact browser support status of this syntax is not clear currently, however you can use this polyfill to plug holes in support.

Want to use a polyfill for shadow CSS but still want to play around with RTL in web components in browsers that already support it such as Firefox (currently hidden behind the dom.webcomponents.enabled flag) and Google Chrome? You can do this using Mutation Observers by observing the document.documentElement.dir property. Code for the observer would look similar to this example:

var dirObserver = new MutationObserver(updateShadowDir);
dirObserver.observe(document.documentElement, {
  attributeFilter: ['dir'],
  attributes: true

Also don’t forget to initialize your function for the first time once the page loads, right after the observer logic:


Your updateShadowDir() function would look something like this:

function updateShadowDir() {
  var internal = myInnerElement.shadowRoot.firstElementChild;
  if (document.documentElement.dir === 'rtl') {
    internal.setAttribute('dir', 'rtl');
  } else {

That’s all you should be doing on the JavaScript side — now, since the first child element of your web component has a changing dir attribute, your CSS will depend on it as a selector instead of the HTML element. Say you are using a span — your selector would look like this:

span[dir="rtl"] rest-of-the-selectors-chain { … }

This might look a little hacky, but fortunately the future is brighter, so let’s take a look at what the W3C has in store for us in the future regarding Right-To-Left.

The future of RTL on the Web

Informing the server of text direction: Currently in text inputs and text areas, when a form is submitted, the direction of the page/form elements is lost. Servers then have to come up with their own logic to estimate the direction of the text that was sent to them.

To solve this problem and be more informative about the text being sent as well as about its direction, W3C has added a new attribute to the HTML5 forms spec called dirname, which browser vendors will be implementing in the future.

As the spec states, including the dirname “on a form control element enables the submission of the directionality of the element, and gives the name of the field that contains this value during form submission. If such an attribute is specified, its value must not be the empty string.”

Translation: Adding this attribute to your <input> or <textarea> makes their direction get passed along with the GET or POST string that is sent to the server. Let’s see a real-world example — first, say you have this form:

<form action="result.php" method="post">
<input name="comment" type="text" dirname="comment.dir"/>
<button type=submit>Send!</button>

After submitting the form, the POST string sent to the server will include a field called comment, and another called comment.dir. If the user types Hello into the text area and submits it the result string will be:

But if they type “?????” it will look like this:


Read the spec here.

Note: In order for Arabic characters to be displayed correctly in URLs in your browser the characters are encoded in UTF-8 and each Arabic letter now uses 4 characters and is separated in the middle with a % sign.

For example, if you have this link:

When you visit it, the link in your browser will be transformed to

Better ways to manage backgrounds and images in RTL: Tired of using transform: scaleX(-1) to mirror your background images? The W3C is introducing a new CSS keyword called rtlflip, which is used like so:

background-image: url(backbutton.png) rtlflip;

This keyword saves you the hassle of manually mirroring your images through the transform: scaleX(-1) property.
It can also be used to style list item markers like this:

list-style-image:url('sprite.png#xywh=10,30,60,20') rtlflip;

The spec page also states that this keyword can be used along with all of the other possible ways that an image can be specified in CSS3 Images, e.g. url, sprite, image-list, linear-gradient, and radial-gradient.

Internationalization APIs

We covered the JavaScript Internationalization APIs before in an introductory post. Let’s recap the important lesser-known parts relevant in the context of working on right-to-left content.

Internationalization API support covers a wide variety of languages and their derivatives. For example it not only supports Arabic as a language, but also Arabic-Egypt, Arabic-Tunisia, and the whole list of other variations.

Using Eastern Arabic numerals instead of Western Arabic: In some Arabic variants, Eastern Arabic numerals (???) are used instead of the Western Arabic (123). The International APIs allow us to specify when to show ??? and when to show 123.

console.log(new Intl.NumberFormat('ar-EG').format(1234567890));

This states that we want to format 1234567890 to Arabic-Egypt numbers.
Output: ?????????????

console.log(new Intl.NumberFormat('ar-TN').format(1234567890));

Here we’re saying we want to output the same number in Arabic Tunisia format; since Tunisia uses Western Arabic, the output is: 1234567890

Showing dates in the Hijri/Islamic calendar instead of the Gregorian: During the Ramadan month, Google made to show content related to the occasion. One of the essential pieces of information shown was the day of the month in the Hijri calendar. Google used a polyfill to get this information. With the Internationalization APIs you can extract the same information with one line of JavaScript instead of a whole JavaScript library.
Here’s an example:

console.log(new Intl.DateTimeFormat("fr-FR-u-ca-islamicc").format(new Date()));
This line states that we want to format the current date to the Islamic Calendar date and show it in fr-FR numerals (Western Arabic). Output: 16/12/1436
console.log(new Intl.DateTimeFormat("ar-SA-u-ca-islamicc").format(new Date()));
This is doing the same thing, but formatted for display in the Arabic-Saudi-Arabia locale which uses Eastern Arabic numerals.
Output: ???/???/????

Final words

In this article, we wrap up our in-depth look at doing RTL on the Web the right way. We hope this has been helpful in encouraging you to get started adding RTL support to your websites/products! If you are a Firefox OS contributor this will be your guide to for adding RTL to Gaia.

As always, let us know in the comments below if you have any questions!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Building RTL-Aware Web Apps & Websites: Part 1

Making the web more accessible to more people, in more languages, is an ongoing effort and a mission we take very seriously at Mozilla.

This post is the first of a series of articles to explain one of the most neglected and least well-known corners of web development: RTL (right-to-left) development. In a web development context it means making your web content compatible with RTL languages like Arabic, Hebrew, Persian, and Urdu, which are all written from right to left.

This area is often neglected by developers because of the lack of teaching resources. In this series, we hope to provide enough information to allow developers to make content that’s accessible to a broader global audience using the RTL capabilities that most web browsers currently provide.

What actually is RTL?

To make things clear, there is a difference between a language and its script. A script is the text or written form — while the language refers to the spoken form. So technically, right-to-left describing the script in which a language is written, comparable to left-to-right scripts, like English or French, more familiar to many Western readers.

For example, “Marhaban” – which means hello – is a word written in the English script, but has Arabic as its language, while “?????” is both Arabic script and Arabic language.

On the web, as we said earlier, the term Right-To-Left indicates more than just a script for writing. It stands for all facets of developing web apps and websites that do not break or become unreadable when used with Arabic, Urdu or any other RTL script.

Before continuing, let’s just clear up some misconceptions about RTL.

First, RTL is not about translating text to Arabic: It means more than translating your website into Arabic and calling it a day. It’s about making every aspect the UI and layout RTL-friendly. And as I always say – and can’t stress it enough – do RTL right or don’t bother! Doing it halfway will lose your audience and credibility.

Second, RTL is more than just “flip all the things”: I’m not sure if this issue has been fixed yet or not, but setting your locale to Arabic in Gnome will cause the time to be shown as PM 33:12 instead of 12:33 PM.

Well, that is not how it works. I’m a native Arabic speaker but that doesn’t mean I tell time backwards. There are some exceptions and things to pay attention to about numbers, and we will cover them in this series.

Why should I care about RTL?

You might have the impression that RTL is hard, scary, and will add a great deal of work to your project! Really, it’s not that difficult. Once you comprehend the basics, the extra effort required is not that great.

You should really care about adding right-to-left support to your web app or website for many, many reasons. There are over 410 million native RTL speakers around the world as of 2010 (That’s a lot of people! Note: The assessment is based on Wikipedia’s list of all the languages.) It’s also millions of potential users and a huge potential market for your app or website. Most companies now add RTL support to their software (e.g. Windows, iOS, Android) and websites, so native RTL speakers expect your website to meet their expectations regarding RTL support. Without this support visitors to your web application may not become repeat users.

In the case of Firefox OS, we only started shipping devices to the Middle East when we had RTL support fully implemented in the system, and thus our partner Orange was able to sell devices with the OS on it. This obviously opens up a whole new market of users to Firefox OS.

Best practices for RTL

Here are some general rules of thumb to keep in mind when developing RTL-aware websites and web apps:

  • Think from the right: In a region with an RTL script and language, books open from the right-hand side. Thus, most UI elements related to readability are going to be mirrored.
  • Hardware legacy UI is a thing: In MENA (Middle East and North Africa) and other regions where RTL languages are spoken, people use gadgets too. Audio hardware has the same control layout as anywhere else in the world. So buttons like Play, Fast Forward, Next, Previous have always been the same. And because of that, it’s not a good idea to mirror any of those buttons. Please don’t RTL the media player buttons. Another example of hardware legacy is the physical feature phone keyboard; before there were Blackberries and similar keyboards for handhelds, there was the simple physical numpad — until very recently it was widely popular in MENA countries. For this reason, It is strongly advised to *not* mirror the number keys. A good example of this is Firefox OS. As its initial target was developing countries, we made sure not to make the dialer mirrored in RTL.
  • Firefox OS Contacts AppThinking Right-To-Left is not thinking left-handed: Remember not to confuse developing RTL UIs with southpaw-first ones. In RTL regions of the world, right-handed people are a majority, just like in the rest of the world. So anything that is not related to how the user reads the actual content on the page should not be mirrored. An example of this is the Firefox OS A-Z scrollbar (image to the right) in the Contacts App. It is placed on the right because it’s easier to scroll through with the right hand, so such a thing should not go on the other side when your page is in RTL mode.

Down to business: How to RTL content

The first step towards making a web page RTL is adding the code dir="rtl" to the <html> tag:

<html dir="rtl">

dir stands for direction and setting its value to rtl defaults the horizontal starting point of elements to the right instead of the left.

To target an element with CSS only when the page is RTL:

  1. Create a copy of any regular CSS rules that target it.
  2. Add a html[dir="rtl"] attribute selector onto the front of the selector chain.
  3. Next, whenever you find a property or a value that represents horizontal positioning of some kind in the RTL rule, use its opposite. For example, if you find `float: left` you should change it to float: right.

As an example, if the original rule is as follows —

.someClass {
    text-align: left;
    padding: 0 10px 0 0;
    text-decoration: underline;

we would paste a copy of it after the original and update it as follows:

html[dir="rtl"] .someClass {
    text-align: right;
    padding: 0 0 0 10px;

Notice that the text-decoration: underline; declaration has been removed. We don’t need to override it for the RTL version because it doesn’t affect any direction-based layout elements. Thus, the value from the original rule will still be applied.

Here’s an even more detailed example you can hack on directly:

See the Pen dYGKQZ by Ahmed Nefzaoui (@anefzaoui) on CodePen.

Of course, real-life cases won’t be quite as simple as this. There are applications with a huge number of CSS rules and selectors, and there are multiple strategies you could adopt. Here is one recommended approach:

  1. Copy and clean up: First, copy the content of your stylesheet to another file, add html[dir="rtl"] to all the rules, then clear out any properties that do not relate to horizontal direction setting. You should end up with a more lightweight file that deals purely with RTL.
  2. Mirror the styles: Change all of the properties left in the new file to their opposites: e.g. padding-left becomes padding-right, float: right becomes float: left, etc. Note: if you originally had padding-left and you changed it to padding-right, remember that the original padding-left still exists in the original rule. You must add padding-left: unset alongside padding-right, otherwise the browser will compute both properties: the padding-left from the original CSS rule and the new padding-right in the RTL rule. The same is true for any property that has multiple direction variants like the margin-left|right, border-left|right
  3. Paste back: After you’ve completed the previous steps, paste the newly created rules back into the original file, after the originals. I personally like to add a little comment afterwards such as: /* **** RTL Content **** */ for the sake of easier differentiation between the two parts of your style file.

A better way: isolating left/right styles completely

Sometimes you will find yourself facing edge cases that produce code conflict. This involves properties inheriting values from other properties, meaning that sometimes you won’t be sure what to override and what not to. Maybe you’ve added the margin-right to the RTL rule but are not sure what to set as the value for the original margin-left? In all real-world cases it is advisable to adopt another approach, which is better in general but more long-winded. For this approach we isolate direction-based properties completely from the rules for both the LTR and the RTL cases. Here’s an example: say we have .wrapper .boxContainer .fancyBox listed like this:

.wrapper .boxContainer .fancyBox {
    text-align: left;
    padding-left: 10px;
    text-decoration: underline;
    color: #4A8CF7;

Instead of adding another property for RTL with both padding-left and padding-right, you can do this:

.wrapper .boxContainer .fancyBox {
    text-decoration: underline;
    color: #4A8CF7;

html[dir="ltr"] .wrapper .boxContainer .fancyBox {
    text-align: left;
    padding-left: 10px;

html[dir="rtl"] .wrapper .boxContainer .fancyBox {
    text-align: right;
    padding-right: 10px;

This solution consists of 3 parts:

  1. The original rule/selector with only non-direction based properties, because they are shared by the LTR and the RTL layout.
  2. The left to right case — html[dir="ltr"] — with only the direction-based CSS properties included, their values set to match your LTR layout.
  3. The right to left case — html[dir="rtl"] — with the same properties as the LTR case, only with their values set according to what you want in your RTL layout.

Notice that in the second rule we had padding-left only and in the third one we had padding-right only. That’s because each one of them is exclusive to the direction that was given to them in the dir attribute. This is a nice, clean approach that doesn’t require unsetting of properties. This is the exact approach we use when adding RTL support to Firefox OS. (Note: the unset keyword isn’t supported in all browsers. For the best compatibility you may need to explicitly re-declare the desired value for any properties you want to unset.)

How do we get and set the direction of the page using JavaScript?

It’s fairly easy, and requires only one line of code: document.documentElement.dir
You can assign this line to a variable, and have it outputted to the console to see for yourself:  

var direction = document.documentElement.dir; console.log(direction);

Or try this example:

See the Pen WQxWQQ by Ahmed Nefzaoui (@anefzaoui) on CodePen.

To set the direction of the page, just use the following:
document.documentElement.dir = "rtl"

And here’s an example of both getting and setting the direction value for a web page:

See the Pen gaMyPN by Ahmed Nefzaoui (@anefzaoui) on CodePen.

Automatic RTL solutions

Enough talk about manual ways to do RTL. Now let’s take a look at some automated approaches.


Twitter has developed a solution to automate the whole process and make it easier for bigger projects to implement RTL. They have open sourced it and you can find it on Github.

This NPM plugin covers pretty much all the cases you could find yourself facing when working on RTL, including edge cases. Some of its features include:

  • no-flip: To indicate to the mirroring engine that you don’t want a certain property flipped, just add /* @noflip*/ at the beginning of the property. So, for example, if you write /* @noflip*/ float: left, it will stay as float: left after css-flip is run.
  • @replace: When you have background images that differ between LTR and RTL, you can specify a replacement image by including /*@replace: url(my/image/path) before the original property. Let’s say you have background-image: url(arrow-left.png). If you update the line to
    /*@replace: url(arrow-rightish.png) */ background-image: url(arrow-left.png);
    You will end up with background-image: url(arrow-rightish.png); in the RTL layout.

You can use css-flip through the command line by executing
css-flip path/to/file.css > path/to/file.rtl.css or by requiring css-flip in your page. More about that on their github repo. css-flip is being actively used on Twitter properties.


Another option for automatic conversion is a tool from Mohammad Younes called rtlcss — this is also available on github and provides some pretty nifty features. With this one engine you can:

  • Rename rule names (e.g. renaming #boxLeft to #boxRightSide).
  • Completely ignore rules from the mirroring process.
  • Ignore single properties.
  • Append/prepend new values.
  • Insert new property values in between other property values.

Basic usage is via the command line — you can create your RTL CSS equivalent by the running the following in the same directory your original CSS is available in:

rtlcss input.css output.rtl.css

And of course you can just require it in your page. More details are available on github.

This project is very popular and is being used by several projects including WordPress.

Final words

While there is still a lot to cover, this article aims to provide you with enough knowledge to start exploring RTL confidently. In the next article we’ll cover more advanced topics around RTL.

Be sure to ask any questions you may have around RTL in the comments section and we will try to answer them here or in the next post!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Webapplate – Maintainable web app template for Firefox OS and Chrome Apps

There are many powerful tools and technologies surrounding the Web, and we can reuse them to develop cross platform mobile and desktop apps, especially in light of installable apps appearing on platforms such as Firefox OS. This article looks at the best way to do this, and presents Webapplate, a powerful new template to help facilitate this.

Why invent the wheel (for the new frontier)

As is the nature of the whole web, web apps are simple to write but hard to get done right. Even though the Web doesn’t provide an SDK or simple ready-to-use templates like other mobile platforms, you can still come out with a workable web app from candidates like Mozilla Open Web Apps, Chrome Apps, or Apache Cordova. But developers who want to quickly build a web app usually take longer time than say, an iOS developer.

Here is the state of web app support by those candidates:

  • Firefox (desktop), Firefox OS, Firefox for Android support hosted web apps. Those web apps could be hosted on a static or dynamic web server just like normal web sites. Hosted web apps don’t allow some certified web APIs such as the TCP socket API because of security concerns.
  • Firefox OS and Chrome (desktop) support packaged web apps with different APIs for different purposes, because currently they focus on different types of devices.
  • Cordova provides device adapters for many platforms, including Android, iOS and Firefox OS.
  • Google has its Cordova variant to adapt Chrome App’s specific APIs to run on Android devices.

In quick summary, the web app concept is not totally unified yet, but powerful enough to compete with native apps. Currently packaged web apps are mainstream because of the security concerns with new web API’s. Mozilla is mainly focusing on exposing new web APIs to mobile devices, Google is developing new web APIs for desktop. Apache Cordova is a good container to expose web APIs to different platforms.

To make things harder, provided examples are often focused on teaching you how to pick up new web APIs rather than utilizing proper web app concepts with your development process.

I’ve had the chance to join the development of an evolving web app project called Gaia, the Firefox OS user interface. The Gaia project contains the very first Mozilla installable web app implementation, including apps for music, photo gallery, e-mail, calendar and much more. According to GitHub’s pulse monthly, there are about 850 commits per month to the Gaia web apps. In the Gaia project, Mozilla developers and community members devoted lots of time and effort to bring it from the prototype stage to a shippable product within 2 years, and iteratively make it a competitive option for smartphone consumers. As a living large web app project, there are many lessons that can be learned from it, and applied to general web app development.

Introducing webapplate

Like other software projects, there are many things beside commiting code to develop a web app, such as:

  • How to organize the source code
  • How to handle library dependencies
  • How to keep the coding style in convention
  • How to optimize web app load performance
  • How to unit/integrate test your web app
  • How to localize your web app
  • How to automate those processes

Those are topics that need to be resolved to develop a quality web app. In Gaia we have addressed these issues by utilizing a bunch of build scripts (Makefiles).

You may wonder why we didn’t use Grunt or gulp for building? The answer: at the time Firefox OS was started, these tools didn’t exist. And the module owner wanted to make the core build process run in a Firefox extension one day.

For general web app development, we didn’t have to follow those constraints. And we could do some experiments rapidly by reusing 3rd-party tools and libraries. From 2013, I’ve initiated a side project called webapplate, the open-sourced web app template that attempts to make Gaia’s solutions compatible with emerging toolkits like npm, Grunt and Bower. It also tries to transport good practices from Gaia to make new web apps more maintainable.

How to setup webapplate

Webapplate utilizes many powerful tools. With node.js, Grunt, Bower, Karma, Mocha and l20n, we come out with a maintainable full stack and self-contained web app template with JavaScript. So you could just copy or download the webapplate from Github, and develop and deploy to a hosting server or correspondent web app store.

You need to install node.js in your desktop first. With Node.js installed, you’ll have the npm tool to manage Node.js modules. Now run this command:

$ npm install -g grunt-cli bower karma

to install the primary tools.

Grunt is a JavaScript task runner tool (like Make) and grunt-cli is its command interface. Gruntfile.js file is similar to Makefile, but written in Javascript.

Bower is a management tool for the front-end libraries. It helps developer manage different library versions. In webapplate, Bower will download client side libraries into the public/vendor folder when you run

$ bower install


Karma is the test runner that runs test code for each of the browsers. karma.conf.js defines the detail settings to specify how the test runner goes.

Next, enter the webapplate folder and run:

$ npm install

npm will reference package.json to install all dependent node modules. The command will trigger Bower to install client-side library dependencies as well.

Then you are all set! What you get is:

  • Pre-commit lint checking
  • Firefox and Chrome web app-compatible templates
  • Library dependency management
  • Client-side localization framework
  • Unit test and mock framework
  • Deployable web server

If you use Firefox nightly, you could open the webapplate/public folder as a packaged app in the WebIDE developer tool.

WebIDE allows you to edit, debug or execute your web app in the Simulator or on the device, with your favorite Firefox Developer Tools.

With the Chrome Apps & Extensions developer tool, you can import the webapplate/public folder as a Chrome App and check the UI on desktop.

webapplate on Chrome devtool

Pre-commit lint checking

The very first good practice that Gaia and webapplate provide is git pre-commit lint checking.

Since in Gaia every commit needs to get reviewed and verified by the module owner before the code is checked in, we have followed the Google JavaScript style conventions. At that time we used gjslint to test it. It sounds good but actually forcing people to follow the exact same discipline manually is hard; asking the reviewer to pick through those style errors is another waste of time. So some genius introduced a git pre-commit hook to check several kinds of lint errors when the developer tries to commit their code, and provide a whitelist for the code that isn’t fully lint-free but should be allowed. Currently in Gaia we have pre-commit checks for JavaScript, CSS and JSON! This is a big relief.

Currently webapplate utilizes code quality and style checking for JavaScript, JSON via JSHint, JSCS and JSONLint.

It has exactly the same settings as Gaia for JSHint and also comes with the whitelist. Gaia is also planning to migrate to jscs to replace gjslint. If you use git for version control, run:

$ grunt githooks

to bind the git pre-commit code style check to your development process.

Firefox OS- and Chrome App- compatible templates

Webapplate uses HTML5 mobile boilerplate as the template base, and adds web app install helpers, icon links and usemin annotation for web app optimization on top. The main web app source is located in the public/ folder. You could check the webapplate wiki to see the full webapplate structure.

Currently, Firefox web apps use manifest.webapp and Chrome Apps use manifest.json as the manifest file. The syntaxes are mutually compatible, except the localization part (we’ll address this issue later).

After you edit one of these files, use:

# firefox to chrome
$ grunt f2c


# chrome to firefox
$ grunt c2f

to overwrite manifest.webapp with manifest.json, or viceversa.

To generate a Firefox OS packaged app or Chrome App, run this command:

$ grunt pack

to package your web app to an uploadable zip file. With the default settings, webapplate-generated packaged web apps could be uploaded to the Firefox Marketplace and the Chrome App store.

Library dependency management

For Gaia we manage development tools via npm and generally don’t use many 3rd-party client side libraries. We host commonly-used libraries between apps in a shared/ folder, and then copy them in at build time via a build script.

webapplate defines these libraries in package.json, uses npm to require build tools, and doesn’t assume any app framework (e.g. Backbone or Angular.js, or a UI framework such as Bootstrap.) Client-side libraries could be managed via Bower in bower.json.

Client side localization framework

Since web apps might be run without an Internet connection, we can’t count on the server to detect multiple languages. Currently Firefox OS uses navigator.mozL10n and Chrome Apps uses chrome.i18n for localization. Both of them are non-standard.

In webapplate we take the l20n library to address the client-side localization issue. l20n is crafted by Mozilla and the developers are currently working on enhancing the Firefox OS localization framework as well.

Check out index.html; the localization syntax looks exactly like what we used in Gaia:

<h1 data-l10n-id="hello">Hello WebApplate</h1>

The locale file however is in a different format, locales.en.l20n:

<projectName "WebApplate">
<hello "Hello {{ projectName }}">

Also, check out the Multiple Language Support Framework section for how l20n is integrated with webapplate.

Unit test and mock framework

Gaia uses its own test-agent to trigger unit tests on Firefox. Gaia uses the Mocha test framework, Chai assertion library and the Sinon test helper library for unit tests.

Webapplate uses the above unit test libraries plus the Karma test runner to run unit tests on all mainstream browsers.

Deployable web server

For developing Firefox OS hosted web apps, we need a working web server and maybe some dynamic web server support. Now that’s what we call the 21st century: it is possible to write server-side code in JavaScript as well.

Running the command:

$ grunt server

will trigger the Express-powered server with django-like Swig template support. It’s been pre-configured for performance. Measure with YSlow and you’ll get a pretty good grade for your web site.

Webapplate has been tested on some free dynamic web page hosting providers such as openshift, heroku and appfog. Check the deployment section to find out more details.

If you like to host your web apps on a static web server, run:

$ grunt static

to generate optimized web pages for hosting.

If you want to deploy your web app on a GitHub page (as a free static hosting server), run:

$ grunt github

Start your new web app project with webapplate!

Webapplate is the web app template that borrows good practices for web app maintenance from the Gaia project. It provides ready-to-use Firefox OS and Chrome App support, an integrated toolbox to optimize your web app and maintain quality, and uses JavaScript through client/server side build/test frameworks. If you are about to make a web app or want to see how to maintain a web app, webapplate is a good start.


View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

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

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

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

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

A channel for Open Web Apps

We have now just opened another feedback channel on UserVoice about Open Web Apps, available at

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

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

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

Contributing is very easy!

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

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

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

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

What do you want the web to be like?

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

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

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

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Firefox OS Apps run on Android

At Mozilla we believe that apps and browsing are best viewed as cooperative and symbiotic, each better when working together. We are working to strengthen that relationship by building an apps ecosystem that is built using the Web technologies that so many developers are already familiar with.

We built Firefox OS as a mobile OS that puts the Web and Open Web Apps at the centre of the mobile experience. The efforts to reduce the performance gaps between the Web and native are paying rich dividends and our work on exposing device capabilities to the Web via WebAPIs, have made web first app development a viable alternative to native platforms.

Build Open Web Apps, run out-of-the-box on Android

Now, with Firefox for Android 29, Mozilla is extending this open Open Web Apps ecosystem to Android. Over the past few months, we have been working on providing a “native experience” for Open Web Apps. What this means is that as a user, you can now manage your web app just like you would a native app. You can install/update/uninstall the app and the app will also show up in the App Drawer as well as the Recent Apps list.

As a developer, you can now build your Open Web App for Firefox OS devices and have that app reach millions of existing Firefox for Android users without having to change a single line of code!

Check out the video to see an Open Web App in action on an Android device,

Better yet, if you have installed Firefox for Android try one or build an app and submit it to the Marketplace.

We also recommend reading Testing Your Native Android App.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Open Web Apps – a talk at State of the Browser in London

state of the browser panel

On my birthday, 26th of April 2014, I was lucky enough to once again be part of the State of the Browser conference. I gave the closing talk. In it I tried to wrap up what has been said before and remind people about what apps are. I ended with an analysis of how web technologies as we have them now are good enough already or on the way there.

The slides are available on Slideshare:

The video recording of the talk features the amazing outfit I wore, as originally Daniel Appelquist said he’ll be the best dressed speaker at the event.

Open web apps – going beyond the desktop from London Web Standards on Vimeo.

In essence, I talked about apps meaning four things:

  • focused: fullscreen with a simple interface
  • mobile: works offline
  • contained: deleting the icon deletes the app
  • integrated: works with the OS and has hardware access
    responsive and fast: runs smooth, can be killed without taking down the rest of the OS

The resources I talked about are:

Make sure to also watch the other talks given at State of the Browser – there was some great information given for free. Thanks for having me, London Web Standards team!

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Introducing TranslationTester and localization support for Open Web Apps

When building Open Web Apps, one important factor is to make your content available to as many possible, and one way to do that is to make it available in more than one language. Therefore we want to make it as easy as possible for you, both with a complete code repository to get started and updated documentation and possibilities to get translations for your apps.

We are now also offering a way to have your app set up and to get connected to localizers directly!

Presenting TranslationTester

Based on the great work and content by Jason in Localizing Firefox OS Apps and Christie in Localizing the Firefox OS Boilerplate App, I’ve been working on simplifying the set-up for localization.

Above articles describe many facets and possibilities available, and to complement that, I wanted to be able to offer the most basic code and structure for most use cases: basically, just add translations and you’re good to go!

This lead to the creation of the TranslationTester code repository, available on GitHub.

From no translation to localized app in less than 4 minutes!

Based on the TranslationTester, Will Bamberg has put together a nice and short screencast showing the exact process of going from no translations to having support in just a few minutes!

In the app-l10n-example repository you have versions of the before and after stages in this screencast, and all of the localization process is described on MDN.

How to localize an app

These are the things needed to localize an app. All of them are included in the TranslationTester repository, but included here to show easy it is to get started, or continue to build on the TranslationTester platform for your app.

Mark up the HTML

For any element that you want to have its text localized, add a data-l10n-id attribute to the desired element. For example:

<p data-l10n-id="winter-for-real">Winter for real</p>

Create translations

In the locales directory, you have a directory for each language, and can just add new ones for new languages. In each language directoy you create an file which will contain all your translations for that language (optionally you can also create a file for the name and description of the app, unless you edit it in the main manifest.webapp for your app).

Include l10n.js

By including the l10n.js file, the translations for respective language’s file will be applied to element with the corresponding data-l10n-id attribute.

Add “name” and “description” translations

The translations for the name and description for your app could be added to the main manifest.webapp file, or in an optional under each locale’s directory.

How to view different locales

To view your app with a different locale, change the language in Firefox/App Manager:

All platforms
Set the desired locale to test in JavaScript, e.g:

App Manager/Firefox OS
Language setting in the Settings app
Choose language under Preferences > Content > Languages. More information in Set content language in Firefox

Get help with translations

We have a Mozilla localization app pilot offered through the Transifex service. As part of that, we’re offering you to add your apps as part of this pilot, to be connected to localizers and quickly offer your app in more languages, to more people.

Please apply in the Localize My Firefox App form to get started!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)