Tag Archives: firefox

Talking about Web Audio in WeCodeSign Podcast

I recorded an episode for the WeCodeSign podcast. It’s in Spanish!

You can download / listen from their website.

We actually talked about more than Web Audio; there’s a list of links to things we mentioned during the episode. From progressive enhancement to Firefox’s Web Audio editor, to the old PCMania tracking stories, to Firefox for iOS… lots of things!

I was really pleased with the experience. The guys were really good at planning, and did a great job editing the podcast as well (and they use Audacity!).

Totally recommended—in fact I suggested that both my fantastic colleague Belén and the very cool Buriticá are interviewed at some point in the future.

I’d love to hear what they have to say!

Throwback to the last time I recorded a podcast in Spanish–at least this time I wasn’t under a massive cold! 🙃

Web Animations: why and when to use them, and some demos we wrote

There’s been much talk of Web Animations for a long time but it wasn’t quite clear what that meant exactly, or even when could we get that new thing working in our browsers, or whether we should actually care about it.

A few weeks ago, Belén, Sam and me met to brainstorm and build some demos to accompany the Firefox 48 release with early support for Web Animations. We had been asked with very little time, but we reckoned we could build at least a handful of them.

We tried to look at this from a different, pragmatic perspective.

Most graphic API demos tend to be very technical and abstract, which tends to excite graphics people but mean nothing to web developers. The problem web developers face is not making circles bounce randomly on the screen, it is to display and format text on screen, and they have to write CSS and work with designers who want to play a bit with the CSS code to give it as much ‘swooosh’ as they envision. Any help we can provide to these developers so they can evaluate new APIs quickly and decide if it’s going to make their work easier is going to be highly appreciated.

So our demos focused less on moving DIVs around and more on delivering value, either to developers by offering side by side comparisons (JS vs CSS code and JS vs CSS performance) or to end users with an example of an style guide where designers can experiment with the animation values in situ, and another example where the user can adjust the amount of animation to their liking—we see this as a way of using the API for improving accessibility.

You can also download all the demos from the repo:

git clone https://github.com/mozdevs/Animation-examples.git

And should you use CSS or should you use JS? The answer is: it depends.

Let’s look at the same animation defined with CSS and JS, taken straight from the CSS vs JS demo:


.rainbow {
    animation: rainbow 2s alternate infinite;

@keyframes rainbow {
    0% { background: #ff004d; }
    20% { background: #ff77ab; }
    50% { background: #00e756; }
    80% { background: #29adff; }
    100% { background: #ff77ab;}


let el = document.querySelector('.rainbow');
    { background: '#ff004d', offset: 0 },
    { background: '#ff77ab', offset: 0.20 },
    { background: '#00e756', offset: 0.5 },
    { background: '#29adff', offset: 0.80 },
    { background: '#ff77ab', offset: 1 }
], {
    duration: 2000,
    direction: 'alternate',
    iterations: Infinity

As you can see, this is fairly similar.

CSS’s syntax for animations has been with us for a while. We know how it works, there is good support across browsers and there is tooling to generate keyframes. But once the keyframes are defined, there’s no going back. Modifying them on the fly is difficult unless you start messing with strings to build styles.

This is where the JS API proves its worth. It can tap into live animations, and it can create new animations. And you can create animations that are very tedious to define in CSS, even using preprocessors, or just plain impossible to predict: imagine that you want custom colour animations starting from an unknown colour A and going to another unknown colour B. Trying to pregenerate all these unknown transitions from the beginning would result in an enormous CSS file which is hard to maintain, and would not even be as accurate as a newly created animation could be.

There’s another advantage of using the Web Animations API versus animating with a library such as tween.js—the API is hardware accelerated and also runs on the compositor thread, which means incredibly smooth performance and pretty much perfect timing. When you animate DOM elements using JavaScript you have to create lots of strings to set the style property of these DOM elements. This will eventually kick a pretty massive Garbage Collector, which will make your animations pause for a bit: the dreaded jank!

Finally another cool feature of these native animations is that you can inspect them using the browser developer tools. And you can scrub back and forth, change their speed to slow them down or make them faster, etc. You cannot tap into JS-library-defined animations (e.g. tween.js) unless there’s support from the library such an inspector, etc.

Essentially: Web Animations cheat by running at browser level. This is the best option if you want to animate DOM elements. For interpolating between plain values (e.g. a three.js object position vector x, y, z properties) you should use tween.js or similar.

If you want to know more here’s an article at Hacks talking about compositors, layers and other internals, and inspecting with DevTools. And with plenty of foxes!

The full API isn’t implemented in any browser yet, but both Firefox and Chrome stable have initial support already. There’s no excuse: start animating things already! I’m also excited that both browsers shipped this early support more or less simultaneously—makes things so much easier for developers.

With mega thanks to Belén for pushing this forward and to Sam for going out of his internship way to help us with this 🙌🏼

Score another one for the web!

Last week I made a quick trip to Spain. It was a pretty early flight and I was quite sleepy and so… I totally forgot my laptop! I indeed thought that my bag felt “a bit weird”, as the laptop makes the back flat (when it’s in the bag), but I was quite zombified, and so I just kept heading to the station.

I realised my laptop wasn’t there by the time I had to take my wallet out to buy a train ticket. You see, TFL have been making a really big noise about the fact that you can now use your Oyster to travel to Gatwick. But they have been very quiet about requiring people to have enough credit in their cards to pay the full amount of the ticket. And since I use “auto top up”, sometimes my card might have £18. Sometimes it won’t, as in this case.

Anyway, I didn’t want to go back for the laptop, as I was going on a short holidays trip, and a break from computers would be good. Except… I did have stuff to do, namely researching for my next trip!

I could use my phone, but I quite dislike using phones for researching trips: the screen is just too small, the keyboard is insufferable, and I want to open many tabs, look at maps, go back and forth, which isn’t easy on a phone, etc. I could also borrow some relative’s laptop… or I could try to resuscitate and old tablet that I hadn’t used since 2013!

It had become faulty at the beginning of 2013, but I thought I had fixed it. But months after, it decided to enter its mad loop of “restart, restart, restart and repeat” during a transatlantic flight. I had to hide it in my bag and let it expire its battery. And then I was very bored during both the rest of the flight, and the flight back, as all my carefully compiled entertainment was on it. Bah! And so I stopped using it and at some point I brought it to Spain, “just in case”.

Who would have guessed I’d end up using it again!?

I first spent about 30 minutes looking for a suitable plug for the charger. This tablet requires 2A and all the USB chargers I could find were 0.35A or 0.5A. The charger only had USA style pins, but that part could be removed, and revealed a “Mickey mouse” connector, or C7/C8 coupler if you want to be absolutely specific. A few years ago you could find plenty of appliances using this connector, but nowadays? I eventually found the charger for an old camera, with one of these cables! So I made a Frankenchargenstein out of old parts. Perfect.

The tablet took a long time to even show the charging screen. After a while I could finally turn it on, and oh wow, Android has changed a lot for the better since 3.1. But even if this tablet could be updated easily, I had no laptop and no will to install developer tools on somebody else’s laptop. So I was stuck in 3.1.

The Play Store behaved weirdly, with random glitches here and there. Many apps would not show any update, as developers have moved on to use newer versions of the SDK in order to use new hardware features and what not, and I don’t blame them, because programming apps that can work with different SDKs and operating system versions in Android is a terribly painful experience. So the easiest way to deal with old hardware or software versions is just not supporting them at all. But this leaves out people using outdated devices.

One of these “discriminatory apps” I wanted to install for my research was a travel app which lets you save stuff you would like to visit, and displays it on a map, which is very convenient for playing it by ear when you’re out and about. Sadly, it did not offer a version compatible with my device.

But I thought: Firefox still works in Android 3.1!

I got it updated to the latest version and opened the website for this app/service, and guess what? I could access the same functionalities I was looking for, via the web.

And being really honest, it was even better than using the app. I could have a tab with the search results, and open the interesting ones in a different tab, then close them when I was done perusing, without losing the scrolling point in the list. You know… like we do with normal websites. And in fact we’re not even doing anything superspecial with the app either. It’s not like it’s a high end game or like it works offline (which it doesn’t). Heck, it doesn’t even work properly when the network is a bit flaky… like most of the apps out there 😛

So sending a huge thanks to all the Firefox for Android team for extending the life of my ancient device, and a sincere message to app makers: make websites, not apps 😉

No more tap tap tap sounds: yay!

A few days ago the fantastic Fritz from the Netherlands told me that my Hands On Web Audio slides had stopping working and there was no sound coming out from them in Firefox.

Which is pretty disappointing for a slide deck that is built to teach you about Web Audio!

I noticed that the issue was only on the introductory slide which uses a modified version of Stuart Memo’s fantastic THX sound recreation-the rest of slides did play sound.

I built an isolated test case (source) that used a parameter-capable version of the THX sound code, just in case the issue depended on the number of oscillators, and submitted this funnily titled bug to the Web Audio component: Entirely Web Audio generated sound cuts out after a little while, or emits random tap tap tap sounds then silence.

I can happily confirm that the bug has been fixed in Nightly and the fix will hopefully be “uplifted” to DevEdition very soon, as it was due to a regression.

Paul Adenot (who works in Web Audio and is a Web Audio spec editor, amongst a couple tons of other cool things) was really excited about the bug, saying it was very edge-casey! Yay! And he also explained what did actually happen in lay terms: “you’d have to have a frequency that goes down very very slowly so that the FFT code could not keep up”, which is what the THX sound is doing with the filter frequency automation.

I want to thank both Fritz for spotting this out and letting me know and also Stuart for sharing his THX code. It’s amazing what happens when you put stuff on the net and lots of different people use it in different ways and configurations. Together we make everything more robust 🙂

Of course also sending thanks to Paul and Ben for identifying and fixing the issue so fast! It’s not been even a week! Woohoo!

Well done everyone! ??

Notes on FOSDEM 2015

FOSDEM finished a few hours ago and I’m almost literally fusing with the couch from where I’m writing this, bad body posture and all. It’s the best I can do.

I presented the latest project I’ve been working on, node-firefox, at the Mozilla track today. I was screencasting my talk but there were mechanical difficulties (namely the VGA plug disconnected), and Quicktime went bananas with the resolution change, so you’ll have to wait until the recordings for 2015 are published to watch the talk. By the way, kudos to Ioana Chiorean for her well researched introductory notes for each speaker. She never ceases to amaze me 🙂

It was really challenging to give this talk because there was people getting in and out of the room all the time, other people speaking out loud, and others playing games on a tablet (with sound effects!) and it was all so distracting that at some point I said something like “sorry, I’m really distracted”. I don’t know if that’s a “speaker faux pas“, but it was the truth! Ahhh! At least neither my live demos or Nightly crashed, so there’s that 😉

I will write a post on node-firefox soon–probably for the Mozilla Hacks blog.

I spent most of Saturday finishing code + the talk so I only had the chance to watch a few talks by other Mozilla colleagues, and they were really interesting. Probably my favourite was Marco Zehe’s plea for rethinking the way we approach accessibility: it should not be an afterthought or a “nice to have” feature, it should be built-in from day zero. And it’s not only about blindness, it’s about motor impairment, cognitive impairment, color blindness… It’s not only about being able to “tab” between elements, but also about being able to understand their meaning. So many things we take for granted! We need to build for the people, but I feel we need to change our front-end culture of chasing the shiniest and nicest framework in order to get there.

I also wasn’t really thrilled about getting into the event itself. I found on Saturday that it didn’t have a code of conduct, or rather, it had a “social conduct policy” that verged on the antisocial:

The FOSDEM organisers were surprised to hear that harassment is a common problem at open source conferences around the world…

For an event this size, I expected them to have a code. I didn’t even bother to check! Even more, Mozilla is supposed to not to sponsor or attend events without a Code of Conduct. This was really disappointing. A year ago, I decided to never attend another conference without them. And there I was in Brussels and with a talk on my hands. What do I do? Do I just give up or just go ahead and do it?

I decided to do it anyway.

I sometimes go to places I don’t really feel like going to, so that someone else won’t feel like they’re the only one “not man”. It helps normalising the fact that women do exist in this field. It also puts a strain on me, but I want to think/hope that it will be less straining over time, as more and more diverse attendees join me.

Then on my way in, there was a group of Spaniards discussing out loud how German women are or not attractive. I’m highlighting “Spaniards” here because I am a native Spanish speaker, and I can be pretty sure there was no “misunderstanding” or cultural barrier here. I perfectly understood what they said. And when I hear that, I start wondering if they’re going to be discussing the rest of women they see at the event, the type of thoughts that are going through their minds, and that makes me uncomfortable.

Walking down the halls, I got those looks I hadn’t got in a few years—more specifically, since I stopped attending heavily sexist demoscene parties: “Oh, a woman!”. My colleagues that attended FOSDEM before had assured me it was a great event and it was all OK, but they are all men and their perception surely doesn’t include getting treated as an anomaly of sorts.

Thankfully, many attendees have called for a proper code of conduct. FOSDEM has replied, in a convoluted way, what many interpret as “we will have a code of conduct”:

Code of Conduct, message received. Booklet statement not evolved for 3 years, our way of handling issues has and will continue to improve. #

Some other attendees had made a fool of themselves declaring that CoC are not needed and “women are actually not interested in technology and engineering”. Pau, your behaviour is a good reason why women won’t apply to speak at FOSDEM. Have you stopped and considered that perhaps, maybe perhaps, women have less opportunities to change plans on a month’s notice and that’s why they can’t attend? Gah…

This “incident” aside, I had difficulty enjoying the event because of its busyness. The fact that it was all free and open for anyone to attend meant there was A LOT of people around, and while there were limits on the number of people inside a room for security reasons, there was no limit on the number of people circulating or just being on the halls. It was noisy and hot and damp, and as we say in Spanish “it smells like humanity” 😛 . So if you have issues with crowded places, perhaps FOSDEM is not a place you want to be in.

I certainly won’t go back until they sort out their Code of Conduct and inclusiveness issues.