Planet MozillaBetter tiles in Fennec

We recently reworked Firefox for Android‘s homescreen to look a little prettier on first-run by shipping “tile” icons and colors for the default sites. In Firefox 33, we’re allowing sites to designate their own tiles images by supporting  msApplication-Tile and Colors in Fennec. So, for example, you might start seeing tiles that look like:

appear as you browse. Sites can add these with just a little markup in the page:

<meta name="msapplication-TileImage" content="images/myimage.png"/>
<meta name="msapplication-TileColor" content="#d83434"/>

As you can see above in the Boston Globe tile, sometimes we don’t have much to work with. Firefox for Android already supports the sizes attribute on favicon links, and our fabulous intern Chris Kitching improved things even more last year. In the absence of a tile, we’ll show a screenshot. If you’ve designated that Firefox shouldn’t cache the content of your site for security reasons, we’ll use the most appropriate size we can find and pull colors out of it for the background. But if sites can provide us with this information directly its 1.) must faster and 2.) gives much better results.

AFAIK, there is no standard spec for these types of meta tags, and none in the works either. Its a bit of the wild wild west right now. For instance, Apple supports apple-mobile-web-app-status-bar-style for designating the color of the status bar in certain situations, as well as a host of images for use in different situations.

Opera at one point supported using a minimized media query to designate a stylesheet for thumbnails (sadly they’ve removed all of those docs, so instead you just get a github link to an html file there). Gecko doesn’t have view-mode media query support currently, and not many sites have implemented it anyway, but it might in the future provide a standards based alternative. That said, there are enough useful reasons to know a “color” or a few different “logos” for an app or site, that it might be useful to come up with some standards based ways to list these things in pages.


Planet MozillaReducing your bandwidth bill by customizing 404 responses.

In this post, you will learn on how to improve and reduce the bandwidth cost for both the user and the server owner. But first we need to understand a bit the issue (but in case you know all about it, you can jump to the tips at the end of the blog post).

Well-Known Location Doom Empire

Starting a long time ago, in 1994, because of a spidering program behaving badly, robots.txt was introduced and quickly adopted by WebCrawler, Lycos and other search engines at the time. Now, Web clients had the possibility to first inspect the robots.txt at the root of the Web site and to not index the section of the Web sites which declared "not welcome" to Web spiders. This file was put at the root of the Web site, http://example.org/robots.txt. It is called a "Well known location" resource. It means that the HTTP client is expecting to find something at that address when doing a HTTP GET.

Since then many of these resources have been created unfortunately. The issues is that it imposes on server owners certain names they might have want to use for something else. Let's say, as a Web site owner, I decide to create a Web page /contact at the root of my Web site. One day, a powerful company decides that it would be cool if everyone had a /contact with a dedicated format. I then become forced to adjust my own URI space to not create conflict with this new de facto popular practice. We usually say that it is cluttering the Web site namespace.

What are the other common resources which have been created since robots.txt?

  • 1994 /robots.txt
  • 1999 /favicon.ico
  • 2002 /w3c/p3p.xml
  • 2005 /sitemap.xml
  • 2008 /crossdomain.xml
  • 2008 /apple-touch-icon.png, /apple-touch-icon-precomposed.png
  • 2011 /humans.txt

Note that in the future if you would like to create a knew well-known resource, RFC 5785 (Defining Well-Known Uniform Resource Identifiers (URIs)) has been proposed specifically for addressing this issue.

Bandwidth Waste

In terms of bandwidth, why could it be an issue? These are files which are most of the time requested by autonomous Web clients. When an HTTP client requests a resource which is not available on the HTTP server, it will send back a 404 response. These response can be very simple light text or a full HTML page with a lot of code.

Google evaluated that the waste of bandwidth generated by missing apple-touch-icon on mobile was 3% to 4%. This means that the server is sending bits on the wire which are useless (cost for the site owner) and the same for the client receiving them (cost for the mobile owner).

It's there a way to fix that? Maybe.

Let's Hack Around It

So what about instead of having the burden to specify every resources in place for each clients, we could send a very light 404 answer targeted to the Web clients that are requesting the resources we do not have on our own server.

Let's say for the purpose of the demo, that only favicon and robots are available on your Web site. We need then to send a specialized light 404 for the rest of the possible resources.

Apache

With Apache, we can use the Location directive. This must be defined in the server configuration file httpd.conf or the virtual host configuration file. It can not be defined in .htaccess.

<VirtualHost *:80>
    DocumentRoot "/somewhere/over/the/rainbow"
    ServerName example.org
    <Directory "/somewhere/over/the/rainbow">
        # Here some options
        # And your common 404 file
        ErrorDocument 404 /fancy-404.html
    </Directory>
    # your customized errors
    #<Location /robots.txt>
    #    ErrorDocument 404 /plain-404.txt
    #</Location>
    #<Location /favicon.ico>
    #    ErrorDocument 404 /plain-404.txt
    #</Location>
    <Location /humans.txt>
        ErrorDocument 404 /plain-404.txt
    </Location>
    <Location /crossdomain.xml>
        ErrorDocument 404 /plain-404.txt
    </Location>
    <Location /w3c/p3p.xml>
        ErrorDocument 404 /plain-404.txt
    </Location>
    <Location /apple-touch-icon.png>
        ErrorDocument 404 /plain-404.txt
    </Location>
    <Location /apple-touch-icon-precomposed.png>
        ErrorDocument 404 /plain-404.txt
    </Location>
</VirtualHost>

Here I put in comments the robots.txt and the favicon.ico but you can adjust to your own needs and send errors or not to specific requests.

The plain-404.txt is a very simple text file with just NOT FOUND inside and the fancy-404.html is an html file helping humans to understand what is happening and invite them to find their way on the site. The result is quite cool.

For a classical mistake, let say requesting http://example.org/foba6365djh, we receive the html error.

GET /foba6365djh HTTP/1.1
Host: example.org

HTTP/1.1 404 Not Found
Content-Length: 1926
Content-Type: text/html; charset=utf-8
Date: Wed, 30 Jul 2014 05:30:33 GMT
ETag: "f7660-786-4e55273ef8a80;4ff4eb6306700"
Last-Modified: Sun, 01 Sep 2013 13:30:02 GMT

<!DOCTYPE html>
…

And then for a request to let say http://crossdomain.xml/foba6365djh, we get the plain light error message.

GET /crossdomain.xml HTTP/1.1
Host: example.org

HTTP/1.1 404 Not Found
Content-Length: 9
Content-Type: text/plain
Date: Wed, 30 Jul 2014 05:29:11 GMT

NOT FOUND

nginx

It is probably possible to do it for nginx too. Be my guest, I'll link your post from here.

Otsukare.

HTML5 DoctorThe Web Manifest specification

By Marcos Cáceres and Bruce Lawson.

Many of us who work on the web are actively working to narrow “the gap” between native applications and web applications. (Disclosure: your humble authors, Marcos Caceres and Bruce Lawson work for browser vendors – Mozilla and Opera respectively – and therefore have mortgage-related reasons to convince you this stuff is a good idea. Please also note that we are describing a technology that is a work in progress. It could all change tomorrow. )

But what is that gap? Just a few years ago, that gap was largely technological. If you wanted access to a device’s GPS, you had to write a native app. Nowadays, the situation is improving somewhat: we can now access devices sensors like GPS, camera, and orientation sensors – though we still have a long way to go. Thanks to recent advances in the web platform we now have a platform that can compete with native applications on a more equal footing.

Nowadays, the primary gaps between native and web is not so much technological. It’s user experience. User simply love installing apps, which live snugly on the homescreen (or the desktop) waiting to be tickled into life with the tap of a finger or the click of a mouse.

Furthermore, installed apps work offline by default, and integrate with the facilities provided by the underlying operating system: consider being able to see installed applications in the task switcher. Or being able to control an app’s privacy settings in the same place as apps installed from an app store. In browser land, we are still fumbling around trying to find opened tabs and having to type long and boring URLs to get anything done.

What we need is a method of “installing” web apps so they are indistinguishable from any other app installed on a user’s device. But at the same time, we don’t want to lose the powerful features that are central to the web platform: linkability, view source, and the ability to host our own stuff.

What is “installation”?

At its most basic, “installation” of a web app means “bookmarking” the web application to the homescreen or adding it to an application launcher. There are some pretty obvious things that you, as a developer, would need to provide to the browser so that it can treat your website as an app: the name, icons, etc. There are then more advanced features that you would need, like being able to indicate the prefered orientation and if you want your app to be fullscreen.

The Manifest specification aims to give you a standardised way to do this using JSON.

Application name

The application needs a real name or set of names (which is usually not the same as the title element of a document). For this you use the name and the short_name properties.

{
name: “My totally awesome photo app”
short_name: “Photos”
}

The short_name serves as the name for the application when displayed in contexts with constrained space (e.g., under an icon on the homescreen of a phone). The name can then be a bit longer, fully capturing the name of the application. This also provides an alternative way for users to search your app on their phone. So, typing ‘awesome’ or ‘photo’ would find the application on a user’s device.

If you omit the name, the browser just falls back to using <meta name=”application-name”>, and failing that, the <title> element.

Icons

There needs to be an icon associated with a web app, rather than the browser’s icon. To handle this, the manifest has an icons property. This takes a list of icons and their sizes, format, and target screen density. Having these optional properties makes icon selection really powerful, because it provides a responsive image solution for icons – which can help avoid unnecessary downloads and helps to make sure your icons always look great across a range of devices and screen densities.

{
   "icons": [{
        "src": "icon/lowres",
        "sizes": "64x64",
        "type": "image/webp"
      }, {
        "src": "icon/hd_small",
        "sizes": "64x64"
      }, {
        "src": "icon/hd_hi",
        "sizes": "128x128",
        "density": "2"
      }]
}

If you omit the icons, the browser just falls back to looking for <link rel=”icon”>, the favicon.ico or, failing that, may even use a screenshot of your website.

Display modes and orientation

Apps need to be able to control how they are to be displayed when they starts-up. If it’s a game, it might need to be in full-screen and possibly in landscape mode. In order to do this, the manifest format provides you with two properties.

{
 "display": "fullscreen",
 "orientation": "landscape"
}

For the display modes, the options that you have are:

  • fullscreen: take over the whole screen.
  • standalone: opens the app with a status bar.
  • minimal-ui: like on iOS, the app is fullscreen, but certain actions can cause the navigation bar and back/forward buttons to reappear.
  • browser: opens your app with normal browser toolbars and buttons.

The nice thing with orientation is that it serves as the “default orientation” for the scope of the application. So, as you navigate from one page to another, your app stays in the correct orientation. You can override the default orientation using the Screen Lock API.

Start URL

Sometimes you want to make sure that when the user starts up an app, they always go to a particular page first. The start_url property gives you a way of indicating this.

{
 start_url: “/start_screen.html”
}

“Scope” of the app

Native applications have clear “boundaries”: as a user, you know when you open a native application that it won’t suddenly open a different application without you noticing. When switching from one native application to another is often pretty clear that you’ve switched applications. These visual cues are often provided by the underlying operating system (think of bringing up the task manager and picking a different application – or pressing “command/alt-tab” on your desktop machine).

The web is very different: it’s a huge hypertextual system where web applications can span multiple domains: you can seamlessly jump from “gmail.com” to “docs.google.com” and as a user have no idea that you’ve jumped form one “origin” to another. In fact, the whole idea that there are boundaries to an application is totally foreign on the Web as, in reality, a web application is just a series of HTML documents (think, “a series of tubes”… no, don’t think that!).

On the web, the only reason we know that we’ve left the scope of one application and entered into another application is because the web designers have been kind enough to make their websites look uniquely different. In case where they haven’t, a lot of users have also been tricked by sites masquerading as another site (the ol’ “phishing attack”).

The manifest format assist with this problem by allowing you to specify a “URL scope” for your application. This scope sets a boundary for an app. It can either be a domain or a directory within that domain.

{
    “scope”: “/myapp”
}

Service Workers

You might have heard of service workers already. If you haven’t heard about them, a service worker is a script that allows an application to handle asynchronous events, like receiving a push notification (even after the application has been shut down). They can also be used to manage interactions between your application and a server – allowing for graceful error recovery, and hence for the ability to create applications that work offline without requiring the use of the much-disliked AppCache.

Using the “service_worker” property, the manifest spec allows you to specify a service worker for your application. The service_worker property lets you specify the url for the service worker and the URL scope to which the service worker applies.

{
service_worker: { src: “app.js”, scope: “/myapp” }
}

If you need to, you can add additional service workers through scripts in individual pages of your app.

How can I detect if the user “installed” my app?

As a developer, you really should not have to worry about this – the browser will take care of it for you. Firstly, bugging users to install your app is annoying. We’ve all seen this happen in iOS with sites asking users to “add my app to the homescreen”.

Instead, the approach that we take with the manifest is that “installing” is a progressive enhancement. Focus on creating the optimum experience based on what “display mode” the application is in. You will be able to detect and style this with CSS.

@media all and (display-mode: standalone){ ...}

You can use JavaScript matchMedia to test that media query in JavaScript.

What’s wrong with <meta> tags?

During the specification discussions, it was hotly debated whether to use <meta> tags in HTML rather than make a new format. After all, the Chrome implementation of Add to Homescreen uses <meta> tags, and this has been the natural home for proprietary flimflam since the web began.

The reasons for including a separate file are

  • it saves loading every page of an installable app/site with tons of header info
  • once downloaded, the file sits in the browsers’s HTTP cache.
  • Marcos loves JSON because he’s totally rad

Who is implementing this

Early implementations are underway in both Blink and Gecko – and there are positive signals from Microsoft too.

Statement of Intent

Don’t start coding for this stuff yet; it’s still in flux and subject to change. We draw it to your attention as it’s a statement of intent: Firefox, Opera and Google have been discussing this because we want the web to be able to compete with proprietary app platforms. The open web may not be too big to fail – but it’s too important to fail.

<aside id="author-bio" style="margin-left:-165px;">

This article was co-written by Marcos Cáceres. Marcos is a web platform engineer and standardista at Mozilla. He writes technical specifications, prototypes ideas, and generally fiddles with Web related things. You can find him on GitHub and Twitter.

</aside>

The Web Manifest specification originally appeared on HTML5 Doctor on July 29, 2014.

Planet MozillaServiceWorkers in Firefox Update: July 26, 2014

(I will be on vacation July 27 to August 18 and unable to reply to any comments. Please see the end of the post for other ways to ask questions and raise issues.)
It’s been over 2 months since my last post, so here is an update. But first,
a link to a latest build (and this time it won’t expire!). For instructions on
enabling all the APIs, see the earlier post.

Download builds

Registration lifecycle

The patches related to ServiceWorker registration have landed in Nightly
builds! unregister() still doesn’t work in Nightly (but does in the build
above), since Bug 1011268 is waiting on review.
The state mechanism is not available. But the bug is easy to fix and
I encourage interested Gecko contributors (existing and new) to give it a shot.
Also, the ServiceWorker specification changed just a few days ago,
so Firefox still has the older API with everything on ServiceWorkerContainer.
This bug is another easy to fix bug.

Fetch

Ben Kelly has been hard at work implementing Headers and some of them have
landed in Nightly. Unfortunately that isn’t of much use right now since the
Request and Response objects are very primitive and do not handle Headers.
We do have a spec updated Fetch API, with
Request, Response and fetch() primitives. What works and what doesn’t?
  1. Request and Response objects are available and the fetch event will hand
    your ServiceWorker a Request, and you can return it a Response and this will
    work! Only the Response(“string body”) form is implemented. You can of
    course create an instance and set the status, but that’s about it.
  2. fetch() does not work on ServiceWorkers! In documents, only the fetch(URL)
    form works.
  3. One of our interns, Catalin Badea has taken over implementing Fetch while
    I’m on vacation, so I’m hoping to publish a more functional API once I’m
    back.

postMessage()/getServiced()

Catalin has done a great job of implementing these, and they are waiting for
review
. Unfortunately I was unable to integrate his patches into the
build above, but he can probably post an updated build himself.

Push

Another of our interns, Tyler Smith, has implemented the new Push
API
! This is available for use on navigator.pushRegistrationManager
and your ServiceWorker will receive the Push notification.

Cache/FetchStore

Nothing available yet.

Persistence

Currently neither ServiceWorker registrations, nor scripts are persisted or available offline. Andrea Marchesini is working on the former, and will be back from vacation next week to finish it off. Offline script caching is currently unassigned. It is fairly hairy, but we think we know how to do it. Progress on this should happen within the next few weeks.

Documentation

Chris Mills has started working on MDN pages about ServiceWorkers.

Contributing to ServiceWorkers

As you can see, while Firefox is not in a situation yet to implement
full-circle offline apps, we are making progress. There are several employees
and two superb interns working on this. We are always looking for more
contributors. Here are various things you can do:
The ServiceWorker specification is meant to solve your needs. Yes, it
is hard to figure out what can be improved without actually trying it out, but
I really encourage you to step in there, ask questions and file
issues
to improve the specification before it becomes immortal.
Improve Service Worker documentation on MDN. The ServiceWorker spec introduces
several new concepts and APIs, and the better documented we have them, the
faster web developers can use them. Start
here
.
There are several Gecko implementation bugs, here ordered in approximately
increasing difficulty:
  • 1040924 - Fix and re-enable the serviceworker tests on non-Windows.
  • 1043711 - Ensure ServiceWorkerManager::Register() can always
    extract a host from the URL.
  • 1041335 - Add mozilla::services Getter for
    nsIServiceWorkerManager.
  • 982728 - Implement ServiceWorkerGlobalScope update() and
    unregister().
  • 1041340 - ServiceWorkers: Implement [[HandleDocumentUnload]].
  • 1043004 - Update ServiceWorkerContainer API to spec.
  • 931243 - Sync XMLHttpRequest should be disabled on ServiceWorkers.
  • 1003991 - Disable https:// only load for ServiceWorkers when Developer Tools are open.
  • Full list
Don’t hesistate to ask for help on the #content channel on irc.mozilla.org.

Planet Mozilla[Video+Transcript]: The web is dead? – My talk at TEDx Thessaloniki

Today the good folks at TEDx Thessaloniki released the recording of my talk “The web is dead“.

Christian Heilmann at TEDx

I’ve given you the slides and notes earlier here on this blog but here’s another recap of what I talked about:

  • The excitement for the web is waning – instead apps are the cool thing
  • At first glance, the reason for this is that apps deliver much better on a mobile form factor and have a better, high fidelity interaction patterns
  • If you scratch the surface of this message though you find a few disturbing points:
    • Everything in apps is a number game – the marketplaces with the most apps win, the apps with the most users are the ones that will get more users as those are the most promoted ones
    • The form factor of an app was not really a technical necessity. Instead it makes software and services a consumable. The full control of the interface and the content of the app lies with the app provider, not the users. On the web you can change the display of content to your needs, you can even translate and have content spoken out for you. In apps, you get what the provider allows you to get
    • The web allowed anyone to be a creator. The curb to mount from reader to writer was incredibly low. In the apps world, it becomes much harder to become a creator of functionality.
    • Content creation is easy in apps. If you create the content the app makers wants you to. The question is who the owner of that content is, who is allowed to use it and if you have the right to stop app providers from analysing and re-using your content in ways you don’t want them to. Likes and upvotes/downvotes aren’t really content creation. They are easy to do, don’t mean much but make sure the app creator has traffic and interaction on their app – something that VCs like to see.
    • Apps are just another form factor to control software for the benefit of the publisher. Much like movies on DVDs are great, because when you scratch them you need to buy a new one, publishers can now make software services become outdated, broken and change, forcing you to buy a new one instead of enjoying new features cropping up automatically.
    • Apps lack the data interoperability of the web. If you want your app to succeed, you need to keep the users locked into yours and not go off and look at others. That way most apps are created to be highly addictive with constant stimulation and calls to action to do more with them. In essence, the business models of apps these days force developers to create needy, bullying tamagotchi and call them innovation

Transcript



You might have realized I’m not from here and I’m sorry for the translators because I speak fast, but it’s a good idea to know that life is cruel and you have to do a job.

Myself, I’ve been a web developer for 17 years like something like that now. I’ve dedicated my life to the web. I used to be a radio journalist. I used to be a travel agent, but that’s all boring because you saw people today who save people’s lives and change the life of children and stand there with their stick and do all kind of cool stuff.

I’m just this geek in the corner that just wants to catch this camera… how cool is that thing? They also gave me a laser pointer but it didn’t give me kitten. This is just really annoying.

I want to talk today about my wasted life because you heard it this morning already: we have a mobile revolution and you see it in press all over: the web is dead.

You don’t see excitement about it anymore. You don’t see people like, “Go to www awesome whatever .com” Nobody talks like this anymore. They shouldn’t have talked like that in the past as well but nobody does it anymore.

The web is not the cool thing. It’s not: “I did e-commerce yesterday.” Nobody does that, instead it is, “Oh, I’ll put things on my phone.”

This is what killed the web. The mobile phone factor is just not liking itself to the web. It’s not fun to type in TEDxThessaloniki.com with your two thumbs and forgetting how many S’s are there in Thessaloniki and then going to some strange website.

We text each other all the time, but typing in URL it feels icky, it feels not natural for a phone, so we needed to do something different that’s why we came up with the QR codes – robot barf as I keep calling it – because that didn’t work either. It’s beautiful isn’t it? You go there with your phone and you start scanning it and then two and a half minutes later with only 30% of your battery left, it goes to some URL.

Not a single mobile operating system came out with the QR reader out of the box. It’s worrying, so I realized there has to be a chance and the change happened. The innovation, the new beginning, the new dawn of the internet was the app.

“There’s an app for that,” was the great talk.

“There’s an app for everything. They’re beautiful. Apps are great.” I can explain it to my … well, not my mom but other people’s moms: “There’s an icon, you click on it, you open it and this is the thing and you use that now. There’s no address bar, there’s nothing to understand about domains, HTTP, cookies, all kind of things. You open it, you play with it and they’re beautiful.”

The interaction between the hardware and software with apps is gorgeous. On iOS, it’s beautiful what you can do and you cannot do any of that on the web with iOS because Apple … Well, because you can’t.

Apps are focused. That’s a really good thing about them, the problem with the web was that we’re like little rabbits. We’re running around like kittens with the laser pointer and we’re like, “Oh, that’s 20 tabs open.” Your friend is uploading something and there’s downloading something in the background and it’s multi-tasking.

With apps, you do one thing and one thing well. That is good because the web interfaces that we built over the last years were just like this much content, that much ads and blinking stuff. People don’t want that anymore. They want to do something with an app and that’s what they are focused and they make sense.

In order not to be unemployed and make my father not proud because he said, “The computer thing will never work out,” anyways, I thought it’s a good plan to start my own app idea. I’m going to pitch that to you tonight. I know there’s this few VC people in the audience. I’m completely buy-able. A few million dollars, I’m okay with that.

When I did my research, scientific research by scientists, I found out that most apps are used in leisure time. They’re not used during their work time. You will be hard pushed to find a boss that says like, “Wilkins, by lunch break you have to have a new extra level in Candy Crush or you’re fired.” It’s not going to happen. Most companies, I don’t know – some startup maybe.

We use them in our free time and being a public speaker and traveling all the time, I find that people use apps the most where you are completely focused and alone, in other words: public toilets. This goes so far that with every application that came out, the time spent in the facilities becomes longer and longer. At Snake, it was like 12 minutes and Angry Birds who are about 14, but Candy Crush and with Flappy Bird…

It happens. You sit there and you hear people inside getting a new high score and like, “Yeah, look what I did?” You’re like, “Yeah, look what I want to do.” That’s when I thought, “Why leave that to chance? Why is there no app that actually makes going to the public facilities, not a boring biological thing but makes it a social thing?”

I’m proposing the app called, “What’s Out.” What’s Out is a local application much like FourSquare and others that you can use to good use while you’re actually sitting down where you do things that you know how to do anyways without having to think about them.

You can check in, you can become the mayor, you can send reviews, you can actually check in with your friends and earn badges like three stalls in a row.All these things that make social apps social apps – and why not? You can actually link the photo that you took of the food in Instagram to your check in on What’s Out and that gets shared on the internet.

You can also pay for the full version and it doesn’t get shared on your Facebook account.

You might think I’m a genius, you might think that I have this great idea that nobody had before, but the business model is already in use and has been tested for years successfully in the canine market. The thing is dogs don’t have a thumb so they didn’t tweet about it. They also can’t write so they didn’t put a patent on it so I can do that.

Seriously now though, this is what I hate about apps. They are a hype, they’re no innovation, they’re nothing new. We had software that was doing one thing and one thing well before, we call it Word and Outlook. We called it things that we had to install and then do something with it.

The problem with apps is that the business model is all about hype. WhatsApp was not bought because it’s great software. WhatsApp was bought because millions of people use it. It’s because it actually allowed people to send text messages without paying for it.

Everybody now sees this as the new thing. “We got to have an app, you got to have an app.” For an app to be successful, it has to play a massive numbers game. An app needs millions of users continuously. Twitter has to change their business model every few months just to show more and more and more and more numbers.

It doesn’t really matter what the thing does. What the app does is irrelevant as long as it gets enough people addicted to using it continuously. It’s all about the eyeballs and you put content in these apps that advertisers can use that people can sell to other people. You are becoming the product inside a product.

That even goes into marketplaces. I work on Firefox OS and we have a marketplace for the emerging markets where people can build their first app without having to spend money or have a good computer or download a massive SDK, but people every time when I go to them like, “How many apps do you have in the marketplace?” “I don’t know. The HTML5 apps, they could be anything.”

“If it’s not a few million, the marketplace isn’t good.”

I go to a baker if they have three good things. I don’t need them to have 500 different rolls, but the marketplaces have to full. We just go for big numbers. That’s to me is the problem that we have with apps. I’m not questioning that the mobile web is the coming thing and is the current thing.

The desktop web is dying, it’s on decline, but apps to me are just a marketing model at the moment. They’re bringing the scratchability of CDs, the breaking of clothes, the outdated looking things of shoes into software. It’s becoming a consumer product that can be outdated and can look boring after a while.
That to me is not innovation. This is not bringing us further in the evolution of technology because I’ve seen the evolution. I came from radio to the internet. Out of a sudden, my voice was heard worldwide and not just in my hometown without me having to do anything extra.

Will you download a Christian Heilmann app? Probably not. Might you put my name in Google and find millions of things that I put in there over the last 17 years and some of them you like, probably and you can do that as well.
For apps to be successful, they have to lock you in.

The interoperability of the internet that made it so exciting, the things that Tim showed like I can use this thing and then I can do that, and then I use that. Then I click from Wikipedia to YouTube and from YouTube to this and I translate it if I need to because it’s my language. Nothing of that works in apps unless the app offers that functionality for a certain upgrade of $12.59 or something like that.

To be successful, apps have to be greedy. They have to keep you in themselves and they cannot talk to other apps unless they’re massively other successful apps. That to me doesn’t allow me as a publisher to come up with something new. It just means that the big players are getting bigger all the time and the few winners are out there and the other just go away and a lot of money has been wasted in the whole process.

In essence, apps are like Tamagotchi. Anybody old enough to remember Tamagotchi? These were these little toys for kids that were like a pet that couldn’t afford pets like in Japan, impossible. These little things were like, “Feed me, play with me, get me a playmate, do me these kind of things, do me this kind of thing.” After a few years, people were like, “Whatever.” Then rusting somewhere in the corner and collect dust and nobody cares about them any longer.

Imagine the annoyance that people have with Tamagotchi with over a hundred apps on your phone. It happens when your Android apps, for example, you leave your Android phone with like 600 updates like, “Oh please, I need a new update because I want to show you more ads.” I don’t even have insight of what updates do to the functionality of the app, it’s just I have to download another 12 MB.

If I’m on a contract where I have to pay per megabyte, that’s not fun. How is that innovative? How is that helping me? It’s helping the publisher. We’re making the problem of selling software our problem and we do it just by saying it’s a nicer interface.

Apps are great. Focus on one thing, one thing well, great. The web that we know right now is too complex. We can learn a lot from that one focus thing, but we shouldn’t let ourselves be locked into one environment. You upload pictures to Instagram now, have you read the terms and conditions?

Do you know who owns these pictures? Do you know if this picture could show up next to something that you don’t agree with like a political party because they have the right to show it? Nobody cares about them. Nobody reads that up.
What Tim showed, the image with the globe with the pictures, that was all from Flickr. Flickr, I was part of that group, licensed everything with Creative Commons. You knew that data is yours. There’s a button for downloading all your pictures. If you don’t want it anymore, here’s your pictures, thank you, we’re gone.

With other services, you get everything for free with ads next to it and your pictures might end up on like free singles in your area without you having to do anything with it. You don’t have insight. You don’t own the interface. You don’t own the software.

All in all, apps to me are a step back to the time that I replaced with the internet. A time when software came in a consumable format without me knowing what’s going on. In a browser, I can highlight part of the text, I can copy it into your email and send it to you. I can translate it. I can be blind and listen to a website. I can change things around. I can delete parts of it if it’s too much content there. I can use an ad blocker if I don’t like ads.
On apps, I don’t have any of that. I’m just the slave to the machine and I do it because everybody else does it. I’ve got 36,000 followers on Twitter, I don’t know why. I’m just putting things out there, but you see for example, Beyonce has 13.3 million followers on Twitter and she did six updates.

Twitter and other apps give you the idea that you have a social life that you don’t have. We stop having experiences and we talk about experiences instead. You go to concerts and you got a guy with an iPad in front of you filming the band like, “That’s going to be great sound and thank you for being in my face. I wanted to see the band, that’s what I came here for.” Your virtual life is doing well right? Everybody loves you are there. You don’t have to talk to real people. That would be boring”. Let’s not go back in time. Let’s not go back where software was there for us to just consume and take in.

I would have loved Word to have more functionality in 1995. I couldn’t get it because there wasn’t even add-ons. I couldn’t write any add-on. With the web, I can teach any of you in 20 minutes how to write your first website. HTML page, HTML5 app give me an hour and you learn it.

The technologies are decentralized. They’re open. They’re easy to learn and they’re worldwide. With apps, we go back to just one world that has it. What’s even worse is that we mix software with hardware again. “Oh you want that cool new game. You’re on Android? No, you got to wait seven months. You got to have an iPhone. Wait, do you have the old iPhone? No you got to buy the new one.”
How is that innovation? How is that taking it further? Software and technology is there to enrich our lives, to make it more magical, to be entertaining, to be beautiful. Right now, the model how we build apps right now, the economic model means that you put your life into apps and they make money with it. Something has gone very, very wrong there. I don’t think it’s innovation, I think it’s just dirty business and making money.

I challenge you all to go out and not upload another picture into an app or not type something into another closed environment. Find a way to put something on the web. This could be a blog software. This could be a comment on a newspaper.

Everything you put on that decentralized, beautiful, linked worldwide network of computers, and television sets, and mobile phones, and wearables, and Commodore 64s that people put their own things in, anything you put there is a little sign and a little sign can become a ripple and if more people like it, it become a wave. I’m looking forward to surfing the waves that you all generate. Thanks very much.

Bruce LawsonReview: JavaScript & JQuery by Jon Duckett

Disclosure stuff: I was sent a free copy of this by the publishers. From 2000-2002 I worked with its author. I currently work with Mathias Bynens, the book’s technical reviewer (but didn’t know this until after reading it).

Don’t tell anyone, but I’m not very confident with my JavaScript – I learned to program in COBOL, FORTRAN, BASIC, 6502, Z80 and DCL which are all procedural, so I was looking forwards to a book that starts at the very beginning and treats me kindly, before clubbing me over the head because I polluted the global namespace and laughing at me for extending my prototypical object literal constructors into my callbacks.

The book’s blurb says “We’ll not only show you how to read and write JavaScript, but we’ll also teach you the basics of computer programming in a simple, visual way” and is the follow-up to Duckett’s hugely successful HTML and CSS Book which sold over 150,000 copies. (In tech book terms, that’s practically Harry Potter; in this industry, 5,000 is a successful book.)

The book looks beautiful. High quality paper, colour images, with real care and attention lavished on the layout and the words. I’m no quivering aethete designer, but I found it pleasurable to read even though it’s a weighty 600 page tome. Each page (or spread) is its own discrete infolump so it’s easy to out down and come back to.

It starts light – defining events, objects, methods and properties, showing the relationship between HTML, CSS and JS, and with a section on Progressive Enhancement (hoorah). However, I was slightly peturbed that the first worked example uses document.write. I can see why you’d do this – it allows you to show something, but without having to muck about appending to the DOM or using getElementById and innerHTML but it didn’t feel particularly good practice (especially as getElementById and innerHTML are introduced soon after, anyway.) In the author’s defence, he does note that this is Considered Naughty.

Elsewhere, we see lots of workarounds and IE-specific aspects of the DOM. I’m comfortable with these being there; we have to live in the real world, and I think that a book that ignores this does a disservice to its readers – it’s right to equip someone to make pages work on IE.wtf or understand what’s happening in older/ inherited scripts.

The book moves briskly after the traditional introduction to loops, variables and other syntax. By page 270 we’re looking at event listeners, including IE5-8, event delegation, mutation events (with a note that mutation observers are coming, but no more than that.)

Chapter 7 begins with jQuery. Again, there are times when jQuery is entirely appropriate. What’s good is that this book teaches JS concepts first, and always keeps the two separate. (I get tired of “JS” tutorials that are actually about jQuery.)

The rest of the book romps through “HTML5″ APIs, JSON, common UI widgets and – usefully – debugging. Attention is paid to pointing out what’s standard and what isn’t, what’s vanilla JS and what isn’t. Progressive enhancement, accessibility and separation of concerns is are kept in mind throughout. This is good. You can see the table of contents.

When I’m reading, I often don’t care if I’m reading a paper book or a Kindle. But in this case, I was glad I was reading the full-colour, attractive book. I’ve railed about the shoddy quality and general unattractiveness of most computer books before. When so much information is available on the web, publishers must provide some sort of extra value. This book has it – the information is thought-through, beautifully presented and clearly explained. While I guess that the majority of my regular readers won’t need an explanation of what a loop or variable is, I believe this would be an excellent book for someone wanting to start with JavaScript, and learn it well. It doesn’t cover Promises, Mutation Observers, but I don’t really think they’re right for a beginners’ book, anyway.

Oh – and it made me realise that I’m not nearly as crap at JavaScript as I thought I was. Which is nice.

Planet MozillaWebVTT Released in Firefox 31

If you haven't seen the release notes WebVTT has finally been released in Firefox 31. I'm super excited about this as it's the culmination of a lot of my own and countless others' work over the last two years. Especially since it has been delayed for releases 29 and 30.

That being said, there are still a few known major bugs with WebVTT in Firefox 31:

  • TextTrackCue enter, exit, and change events do not work yet. I'm working on getting them done now.
  • WebVTT subtitles do not show on audio only elements yet. This will probably be what is tackled after the TextTrackCue events (EDIT: To clarify, I meant audio only video elements).
  • There is no support for any in-band TextTrack WebVTT data yet. If your a video or audio codec developer that wants in-band WebVTT to work in Firefox, please help out :-).
  • Oh, and there is no UI on the HTML5 Video element to control subtitles... not the most convenient, but it's currently being worked on as well.
I do expect the bugs to start rolling in as well and I'm actually kind of looking forward to that as it will help improve WebVTT in Firefox.

Bruce Lawson“Native experience” vs styling select boxes

I mused about this on stage at Fronteers 2013, and was reminded of it when reading Stephanie Reiger’s excellent slidedeck The future of media queries?, specifically slide 42 which I reproduce with Stephanie’s permission.

Stephanie suggests a mechanism of telling a user agent to render a navigation list as a native component, so it looks native across a range of devices, because it is native. (We could bikeshed about the markup and whether it should be in the CSS, but that doesn’t matter.)

I get that developers want their sites to appear native on the host device. Presumably users like native feel, too; there’s a reason why users show a huge preference for native apps over web apps, and one of those reasons is that native apps

allow the user to use device-specific hand gestures. Android and iOS are gradually developing different conventions for interaction, and a native app responds the way its user expects. User Experience Stack Exchange

So Stephanie’s idea makes perfect sense to me.

But what puzzles me is the fact that for ages designers and developers have also desperately tried to style away native controls. For example, recently Nicholas Zakas said

<script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>

and was retweeted hundreds of times. Nicholas isn’t wrong to want this, and this wish isn’t new; when Safari first came out, designers were close to burning their moleskines because they couldn’t make buttons in corporate orange and heliotrope. When I first started showing HTML5 form controls at conferences, without fail I’d be asked how they can be styled. There are endless articles and scripts that painstakingly take real selects, hide them more or less accessibly, then recreate them so they don’t look native on any device.

But why this urge to re-style page elements that end-users are familiar with? You’ll be shocked to learn that I’m not actually trained as a designer – so what am I failing to understand? Or is it that we love native look and feel, except when we don’t?

UPDATE 21 July 2014: Aaron Gustafson wrote an interesting response to my post: The “Native” vs. “Stylable” Tug of War.

Steve Faulkner et alHTML5 accessibility implementation support in browsers

HTML5 I have been testing and tracking browser accessibility implementation support for a range of new HTML features since 2010. Data can be found on HTML5accessibility.com. Over the last week I also undertook a more formal, targeted testing of the normative implementation requirements in the WAI-ARIA section of the HTML5.0 specification which is currently on its way to becoming a W3C Recommendation.

<script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>

Understanding the testing results

HTML5 contains normative requirements (things a browser MUST implement) to be considered to support HTML5. In order for HTML5.0 to become a W3C Recommendation the normative requirements must be implemented interoperably (i.e. in at least 2 independent browsers). One of the methods used to decide whether a given HTML feature is implemented interoperably is to create tests and test the assertions in the specification in browsers. Details of the requirements are in the Model CR Exit Criteria (Public Permissive version 3).

In the case of accessibility semantics implementation the assertions are framed in terms of ARIA roles, states and properties as implicit ARIA semantics. For example:

HTML feature Implicit ARIA semantics
button element button role

Another step is required

ARIA semantics in this case are used as an abstract indicator of the platform specific requirements. To find out and test what browsers are actually required to implement to conform to the above requirement we have to refer to the ARIA implementation guide, which describes the implementation requirements for ARIA semantics in terms of the platform accessibility API mappings

MSAA + UIA Express role (IE on windows) MSAA + IAccessible2 role andother IAccessible2 features (Firefox chrome on windows) ATK/AT-SPI role (firefox on linux) Mac OS XAXRole
AXSubrole
AXRoleDescription
(Safari, Chrome, Firefox on OSX)
PUSHBUTTON PUSHBUTTON PUSH_BUTTON AXButton
<nil>
‘button’

So from this information it can be assessed whether a browser passes or fails the assertion that the button element has a button role by looking at what role the browser exposes via the platform accessibility API(s) it has implemented (noted browser/platform in table headers) . We can look at the accessibility information (roles and properties) by using an object inspection tool, such as aViewer inspect.exe or a11y-probe.

For example, using aViewer it can be confirmed that Firefox 29 on Windows exposes the correct role for the button element:

button element information exposed in MSAA and Iaccessible2 by Firefox 29 is role of button.

The results of testing all the assertions within the WAI-ARIA section of the HTML5.0 Last Call Working Draft specification are available: Implementation status for HTML5 element/attribute accessibility mappings

Notes

The accessibility requirements specified in the HTML5.0/5.1 specifications are only a subset of browser accessibility implementation requirements. Much of what is needed is simply not specified in any HTML specification. Work is continuing on a HTML accessibility mapping and related specifications to fully define the requirements on browsers to support HTML and SVG accessibility.

The testing conducted is for the purposes of checking HTML5 Last Call Working Draft specification support, these are a subset of the requirements contained in the (still in development) HTML 5.1 specification,  features that do not have at least 2  implementations  are absent from HTML5.0 (e.g. dialog element).

W3C Team blogThis week: #i18n Personal names around the world, #HTML elements, #Web2024, etc.

This is the 4-11 July 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

And, on the lighter side

Open Web & net neutrality

W3C in the Press (or blogs)

5 articles since the 4-Jul Digest; a selection follows. You may read all articles in our Press Clippings page.

Planet MozillaMy 2009 yearly report


I am not great at blogging in English and communicating about my work so I thought that publishing my yearly report would compensate that ;)

All in all, it has been a busy year, nobody in the localization drivers team and among our localization teams had time to get bored, lots of product releases, lots of pages, lots of travel and events too. I am listing below what I have been directly leading and/or participating in, not some other projects where I was just giving a minor help (usually to my colleagues Stas and Delphine).

Products:

  • 2 major releases: Firefox 3.5 and Thunderbird 3 (with a new multilingual Mozilla Messaging website)
  • 26 other releases (maintenance, beta and RC releases)

Mozilla Europe website(s):

  • 3 new locales: Serbian, Bulgarian, Swedish, our geographic coverage of Europe is now almost complete
  • New content for 3.5 release, minor releases and many side projects
  • major cleanups of content and code for easier maintenance (especially maintenance releases) and more features (html5 support, per locale menu navigation, visits now with referrer hints for better locale detection...)
  • Site now sharing same metrics application as other mozilla sites
  • More per country news items than previous years (events, new community sites, community meetings...)
  • 46 blog posts written by our European community on blogs.mozilla-europe.org
  • Our events management web application was used for 10 European events (I created it back in summer 2008)

Mozilla.com website

  • We now have a localized landing page for our 74 locales on top of up to date in-product pages
  • Geolocation page for all locales
  • 3.0 and 3.5 major updates offered for all locales
  • Localized beta download pages to incitate beta-testing of non-English versions of Firefox
  • Better code for our localized pages (better right-to-left, language switching, simpler templates...)
  • Whatsnew/Firstun pages now warn the user in his language if his Flash plugin is outdated  (for better security and stability)
  • Lots of content, css, graphics updates all along the year, everywhere
  • Firefox 3.6 in-product pages (firstrun, whatsnew, major update) localization underway, pluginscheck page localization almost technically ready for localization
  • Fennec pages being localized for 1.0 final

Marketing Sites made multilingual

Mozilla Education:

  • Gave a lecture at the Madrid university about opensource, the mozilla project and community management.
  • MMTC Madrid one week sprint in July, gave Mozilla classes with Paul Rouget and Vivien Nicolas to 30 students (evaluation TBD)
  • Organized CoMeTe project at Evry university, France,  in October with Fabien Cazenave and Laurent Jouanneau as teachers

Community work

  • Found new localizers for a dozain locales, helped some creating blogs, community sites and local events
  • Many community meetings, IRC or IRL
  • Participated in Firefox 3.5 party in Madrid
  • I am since May on twitter, communicating about my work and Mozilla in Europe
  • Organized a theming contest in collaboration with the Dotclear project for our community blog, won by Marie Alhomme
  • Created with Julia a Mozilla Planet for French Speakers
  • Lots of Web l10n QA with Delphine plus some personal QA work on 3.6 looking for Linux specific Firefox bugs
  • Went to 21 events (7 of them internal Mozilla events) like Fosdem, MozCamps Chile + Prague, Ubuntu parties, Solutions Linux, W3C event, Firefox 5 year anniversary, Firefox 3.5 party Madrid, JDLL, Geneva Community meetup... Lots of time abroad and travelling.
  • Blogging in French about the Mozilla project and its place in the FLOSS ecosystem, current focus on Mozilla QA and how to get involved in the project.

Other

  • Some documentation work (mostly on QA of localized pages)
  • Many updates to the webdashboard
  • Helped Delphine setting up Womoz website and general advices on community building
  • Several press interviews for Spain as well as conferences given about the Mozilla project
  • Started this week with Stas and Patrick the localization work needed for the Browser Choice Screen in Windows for Europe
  • Lots of technical self teaching while building projects, I even did my first Jetpack extension this week, Yay!
  • A new expresso machine :)

Happy new year 2010 to all mozillians and FOSS lovers in the world :)

Planet Mozilla[video+slides] FirefoxOS – HTML5 for a truly world-wide-web (Sapo Codebits 2014)

Chris Heilmann at SAPO codebits
Today the good people at Sapo released the video of my Codebits 2014 keynote.

In this keynote, I talk about FirefoxOS and what it means in terms of bringing mobile web connectivity to the world. I explain how mobile technology is unfairly distributed and how closed environments prevent budding creators from releasing their first app. The slides are available on Slideshare as the video doesn’t show them.

There’s also a screencast on YouTube.

Since this event, Google announced their Android One project, and I am very much looking forward how this world-wide initiative will play out and get more people connected.

Photo by José P. Airosa ‏@joseairosa

Steve Faulkner et alWhat’s Happenning at The Paciello Group?

In addition to client work we do at The Paciello Group we like to keep our clients and colleagues abreast of our contributions to the international accessibility and web standards work. I’m personally very proud of our team and their individual contributions as we continue to drive accessibility and raise the bar in quality of user experience for people with disabilities!

Summary of some of our recent activity:

Tips for Creating Accessible SVG by Léonie Watson

Scalable Vector Graphics (SVG) exists in a quantum state of accessibility. Which is to say that SVG is both accessible and inaccessible at the same time…

Measuring the harm of flawed academic papers by Karl Groves

For several years I’ve been interested in finding and reading academic work in the field of web accessibility. I have a very strong belief that the things we say regarding web accessibility must be based on a significant amount of rigor…

Thoughts on professional accreditation in digital accessibility by David Sloan

I’ve been working (more or less) full time in digital accessibility for quite some time now, so naturally I’ve watched with great interest the unfolding developments in recent years… towards establishing the International Association of Accessibility Professionals (IAAP)

Building an Accessible Disclosure Button – using Web Components by Cédric Trévisan

Web components are the next step in building modern web applications and a great way to prototype accessible widgets. Today we are going to build a disclosure widget, by extending the native HTML button element…

HTML5 accessibility implementation support in browsers by Steve Faulkner

Over the last week I also undertook a more formal, targeted testing of the normative implementation requirements in the WAI-ARIA section of the HTML5.0 specification which is currently on its way to becoming a W3C Recommendation.

Accessibility Research Methods with Jonathan Lazar by Sarah Horton

Accessibility research can help us better understand how people with disabilities use the web and what we in product design and development can do to make that experience more successful and enjoyable…

<html5-h> heading custom element by Matthew Atkinson, Cedric Trevisan and Steve Faulkner

Custom heading element intended to replace <h1> to <h6> with a single heading element (yup just like XHTML promised land) and the promise of the HTML5 outline…

Using ARIA in HTML by Steve Faulkner

ARIA (WAI-ARIA if you want to be formal) is a set of attributes that you can add to HTML elements. These attributes communicate role, state and property semantics to assistive technologies via the accessibility APIs implemented in browsers…

#ID24 A GAAD Hit! Thanks to All Speakers by Mike Paciello

in celebration of Global Accessibility Awareness Day (GAAD), TPG with support from YOU and our co-sponsors, Adobe Systems Inc., pulled off one of the greatest online accessibility events ever – Inclusive Design 24 (#ID24). Twenty-four hours of non-stop, international accessibility webinars FREE to the entire world. WOW!! Many thanks to all our friends who made #ID24 a huge success. The final, fully captioned versions of those sessions are nearly complete and will be posted for all to enjoy!

JavaScript touch/pointer events research notes: screenreaders, faked mouse events, touchscreens by Patrick Lauke

Over the last two years I’ve been dabbling with various aspects related to the handling of touch events and pointer events – specifically trying to determine which events are being dispatched by browsers as a result of touchscreen interactions, and what the repercussions of this are considering the increasing number of multi-input devices

 

Planet MozillaBringing SIMD to JavaScript

In an exciting collaboration with Mozilla and Google, Intel is bringing SIMD to JavaScript. This makes it possible to develop new classes of compute-intensive applications such as games and media processing—all in JavaScript—without the need to rely on any native plugins or non-portable native code. SIMD.JS can run anywhere JavaScript runs. It will, however, run a lot faster and more power efficiently on the platforms that support SIMD. This includes both the client platforms (browsers and hybrid mobile HTML5 apps) as well as servers that run JavaScript, for example through the Node.js V8 engine.

https://01.org/blogs/tlcounts/2014/bringing-simd-javascript

Bruce LawsonApps For All: Coding Accessible Web Applications – book review

(I was sent a free ebook of this title. That hasn’t influenced my review. This ebook is published by Smashing Magazine and costs €10.95. There’s a sample chapter available. I have no financial connection with the publisher or author.)

When I read about this book I was excited to read it. I don’t need Yet Another Accessibility Book (I co-wrote one a long time ago) but wanted something that delves deeply into WAI-ARIA and how it interacts with HTML5 and assistive technologies. As this book’s blurb says “the underlying theme of this book is about making the interactivity of web applications include keyboard and screen reader users”, it seemed like the book for me. It’s also tech-reviewed by Steve Faulkner who’s my go-to Bogan for practical accessibility information, so I was pretty sure I could trust it.

WAI-ARIA is one of the vital specifications for making the web accessible. There are three problems with using it, though: firstly, the spec is hard to read and understand, even in the context of specs’ inherent indigestibility; secondly, it’s hard to understand how its concepts intertwine with other specs like HTML and, thirdly, most developers don’t use assistive technologies so are unable to understand or test the output of their ARIA pages.

Therefore, I greatly appreciated that author Heydon Pickering is a developer, so keeps the book practical. ARIA is used, in conjunction with markup and script in situations that you’d really encounter. The problem to be solved is elucidated, and the output is clearly explained. It goes deep, too; I learned a great deal and plan to re-read it soon.

It’s a short book (but quite dense) and Heydon’s prose style is clear and occasionally humorous. But don’t let that fool you; this is an important book because it’s the only one that thoroughly explains the technical merits and use of ARIA (and doesn’t browbeat the reader about accessibility).

Without hyperbole: every developer should read this book, and put its techniques into practice. Now.

Planet MozillaHave we lost our connection with the web? Let’s #webexcite

I love the web. I love building stuff in it using web standards. I learned the value of standards the hard way: building things when browser choices were IE4 or Netscape 3. The days when connections were slow enough that omitting quotes around attributes made a real difference to end users instead of being just an opportunity to have another controversial discussion thread. The days when you did everything possible – no matter how dirty – to make things look and work right. The days when the basic functionality of a product was the most important part of it – not if it looks shiny on retina or not.

Let's get excited

I am not alone. Many out there are card-carrying web developers who love doing what I do. And many have done it for a long, long time. Many of us don a blue beanie hat once a year to show our undying love for the standard work that made our lives much, much easier and predictable and testable in the past and now.

Enough with the backpatting

However, it seems we live in a terrible bubble of self-affirmation about just how awesome and ever-winning the web is. We’re lacking proof. We build things to impress one another and seem to forget that what we do sooner than later should improve the experience of people surfing the web out there.

In places of perceived affluence (let’s not analyse how much of that is really covered-up recession and living on borrowed money) the web is very much losing mind-share.

Apps excite people

People don’t talk about “having been to a web site”; instead they talk about apps and are totally OK if the app is only available on one platform. Even worse, people consider themselves a better class than others when they have iOS over Android which dares to also offer cheaper hardware.

The web has become mainstream and boring; it is the thing you use, and not where you get your Oooohhhs and Aaaahhhhs.

Why is that? We live in amazing times:

  • New input types allow for much richer forms
  • Video and Audio in HTML5 has matured to a stage where you can embed a video without worrying about showing a broken grey box
  • Canvas allows us to create and manipulate graphics on the fly
  • WebRTC allows for Skype-like functionality straight in the browser.
  • With Web Audio we can create and manipulate music in the browser
  • SVG is now an embed in HTML and doesn’t need to be an own document which allows us scalable vector graphics (something Flash was damn good in)
  • IndexedDB allows us to store data on the device
  • AppCache, despite all its flaws allows for basic offline functionality
  • WebGL brings 3D environments to the web (again, let’s not forget VRML)
  • WebComponents hint at finally having a full-fledged Widget interface on the web.

Shown, but never told

The worry I have is that most of these technologies never really get applied in commercial, customer-facing products. Instead we build a lot of “technology demos” and “showcases” to inspire ourselves and prove that there is a “soon to come” future where all of this is mainstream.

This becomes even more frustrating when the showcases vanish or never get upgraded. Many of the stuff I showed people just two years ago only worked in WebKit and could be easily upgraded to work across all browsers, but we’re already bored with it and move on to the next demo that shows the amazing soon to be real future.

I’m done with impressing other developers; I want the tech we put in browsers to be used for people out there. If we can’t do that, I think we failed as passionate web developers. I think we lost the connection to those we should serve. We don’t even experience the same web they do. We have fast macs with lots of RAM and Adblock enabled. We get excited about parallax web sites that suck the battery of a phone empty in 5 seconds. We happily look at a loading bar for a minute to get an amazing WebGL demo. Real people don’t do any of that. Let’s not kid ourselves.

Exciting, real products

I remember at the beginning of the standards movement we had showcase web sites that showed real, commercial, user-facing web sites and praised them for using standards. The first CSS layout driven sites, sites using clever roll-over techniques for zooming into product images, sites with very clean and semantic markup – that sort of thing. #HTML on ircnet had a “site of the day”, there was a “sightings” site explaining a weekly amazing web site, “snyggt” in Sweden showcased sites with tricky scripts and layout solutions.

I think it may be time to re-visit this idea. Instead of impressing one another with codepens, dribbles and other in-crowd demos, let’s tell one another about great commmercial products aimed not at web developers using up-to-date technology in a very useful and beautiful way.

That way we have an arsenal of beautiful and real things to show to people when they are confused why we like the web so much. The plan is simple:

  • If you find a beautiful example of modern tech used in the wild, tweet or post about it using the #webexcite hash tag
  • We can also set up a repository somewhere on GitHub once we have a collection going

W3C Team blogThis week: input APIs collaborations, W3C TAG by-election, etc.

This is the 27 June – 4 July 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

And, on the lighter side

  • Markup pun galore in Twitter thread (via @tenderlove)
  • “In W3C, browser devs consult the reference copy of the CSS spec that’s kept in a humidity-controlled glass case” [image (via @brucel)]

Open Web & net neutrality

W3C in the Press (or blogs)

6 articles since the 27-Jun Digest; a selection follows. You may read all articles in our Press Clippings page.

Bruce LawsonReading List

Planet MozillaImplementing Scroll Animations Using Web Animations

It's fashionable for apps to perform fancy animations during scrolling. Some examples:

  • Parallax scrolling
  • Sticky headers that scroll normally until they would scroll out of view and then stop moving
  • Panels that slide laterally as you scroll vertically
  • Elements that shrink as their available space decreases instead of scrolling out of view
  • Scrollable panels that resist scrolling as you get near the end

Obviously we need to support these behaviors well on the Web. Also obviously, we don't want to create a CSS property for each of them. Normally we'd handle this diversity by exposing a DOM API which lets developers implement their desired behavior in arbitrary Javascript. That's tricky in this case because script normally runs on the HTML5 event loop which is shared with a lot of other page activities, but for smooth touch tracking these scrolling animation calculations need to be performed reliably at the screen refresh rate, typically 60Hz. Even for skilled developers, it's easy to have a bug where once in a while some page activity (e.g. an event handler working through some unexpected large data set) blows the 16ms budget to make touch dragging less than perfect, especially on low-end mobile devices.

There are a few possible approaches to fixing this. One is to not provide any new API, hope that skilled developers can avoid blowing the latency budget, and carefully engineer the browser to minimize its overhead. We took this approach to implementing homescreen panning in FirefoxOS. This approach sounds fragile to me. We could make it less fragile by changing event dispatch policy during a touch-drag, e.g. to suppress the firing of "non-essential" event handlers such as setTimeouts, but that would add platform complexity and possibly create compatibility issues.

Another approach would be to move scroll animation calculations to a Worker script, per an old high-level proposal from Google (which AFAIK they are not currently pursuing). This would be more robust than main-thread calculations. It would probably be a bit clumsy.

Another suggestion is to leverage the Web's existing and proposed animation support. Basically we would allow an animation on an element to be use another element's scroll position instead of time as the input to the animation function. Tab Atkins proposed this with declarative CSS syntax a while ago, though it now seems to make more sense as part of Web Animations. This approach is appealing because this animation data can be processed off the main thread, so these animations can happen at 60Hz regardless of what the main thread is doing. It's also very flexible; versions of all of the above examples can be implemented using it.

One important question is how much of the problem space is covered by the Web Animations approach. There are two sub-issues:

  • What scrolling effects depend on more than just the scroll position, e.g. scroll velocity? (There certainly are some, such as headers that appear when you scroll down but disappear when you scroll up.)
  • For effects that depend on just the scroll position, which ones can't be expressed just by animating CSS transforms and/or opacity as a function of the scroll position?
If people are aware of scrolling effects in either of those two categories, it would be very useful to hear about them.

Planet MozillaMicrosoft nominated me as a Most Valuable Professional

mvp

You read well; Microsoft nominated me, and I’m now a MVP, a Most Valuable Professional about Internet Explorer. For those of you that don’t know, it’s an important recognition in the Microsoft ecosystem: it’s given to professionals with a certain area of expertise, around Microsoft technology or technology Microsoft use, for their work in the community.

So why Microsoft gave me recognition for Internet Explorer? In the end, I’m working at Mozilla. Well, I see this as a good news for everything I was doing while I was there (like Make Web Not War), and everything I’m doing right now: it’s another proof that Microsoft is more, and more open. As I’ve always said, it’s not perfect, but it’s going in the right direction (MS Open Tech is a great example). In my case, this award is less about Internet Explorer itself, than about the Web, and it’s lovely technology that is HTML5. They recognize the work I’m doing in that sense, either with Open Source, with communities in Montreal or with talks I’m doing about the Web. At first, it may seem weird for you, but I think it makes a lot of sense that Microsoft recognize someone like me, even if I’m working in a company making a competing product. Microsoft is doing a better job since Internet Explorer 9, and the browser is getting better, and better. No matter if you don’t use it, but other people do, and by making a better browser, which respect more the standards, they are helping the web to move forward. It’s also a good thing for us, developers, as we can more easily build great experiences for any users, no matter the browser they use. On that note, I was happy to see a bit more transparency about IE with the platform status website.

So, I salute the openness of Microsoft to nominate someone like me (they even hired me in the past). By being part of that MVP program, I’m looking forward to seeing how I can continue to work on the Mozilla mission while helping Microsoft to be more open with web technologies.


--
Microsoft nominated me as a Most Valuable Professional is a post on Out of Comfort Zone from Frédéric Harper

Footnotes

Updated: .  Michael(tm) Smith <mike@w3.org>