Archive for the ‘Open Source’ Category

Inspect User Agent Styles in Firefox DevTools

Friday, June 6th, 2014

User agent styles refer to the styles loaded by the default stylesheets within a browser. Firefox has some basic style rules that get applied to every page – for instance, links are blue and <h1> tags are big and bold with margins.

Sometimes these styles can interact with the styles you add to a page, which is why it is important that you can see them in devtools. I recently added a feature in Firefox 32 (currently Nightly) that lets you inspect these rules. See Bug 935803 for the implementation details.

Within the inspector, these styles behave pretty much like any other style on the page. It lists rules in the order of application, and you can see which rules have been overridden. There are a few ways that devtools distinguishes between the UA styles and normal styles:

  1. They are not editable. Since you can’t change these files, you are not able to edit/disable them within the tools.
  2. They are shown with a slightly different background color.
  3. The links to the stylesheet open a popup window to view the source of a sheet instead of loading the sheet in the Style Editor. There isn’t much purpose for loading these in the style editor (see 1), but seeing the source of the sheet can still be nice for the curious.



Enabling User Agent Styles

This is turned off by default. To enable user agent styles, select the “Show Browser Styles” checkbox from the options panel:



You can open any page and toggle this feature on to see it. But here is a a quick page to try it with:
data:text/html,<blockquote style='color:red;' type=cite><pre _moz_quote=true>fun <a href='foo' style='color:orange'>to</a> inspect</pre></blockquote>

Video Funhouse – Convert Videos In Your Web Browser

Monday, November 11th, 2013

We (Nicole, Aaron, and I) have had a lot of fun doing Node Knockout the past few years. Last year (in 2012), our Missouri-based team got first place in the ‘Completeness’ category for our app asciigram, which converted a webcam stream into ASCII art.

This year we decided to up the game a little bit, and to try and convert any video file into another video format, while allowing filters to be applied to the video – all inside of the browser, without uploading anything. The result is Video Funhouse (here is our devcomo team page). I’m particularly proud of our project and team this year, since it was a very busy weekend all around.

Obviously, we knew we wouldn’t be able to do this in a weekend on our own without relying on great libraries and tools. There is a project called Emscripten, which is an LLVM to JavaScript compiler, so we figured we could try building FFmpeg or avconv into JavaScript to do the heavy lifting for the project. Here’s a demo video of the result (keep reading further to see more technical information):

Again, here is the link to the application if you’d like to play with it, and here is a link to the team page.


I have open sourced the build utilities and the ffmpeg.js file that we are using in the project as: videoconverter.js.

Building these projects with Emscripten was a little tricky, but actually quite simple when you consider what it was doing for us. What is also amazing about these tools is that I have little experience with build systems like this, and the tools generally just worked after a bunch of trial and error.

Why Would You Compile FFmpeg Into JavaScript?

Mostly just to see if it would work. Also, it seemed like it would be a fun project.

So, How Do You Compile FFmpeg Into JavaScript?

Here are some of notes I made while doing this, for future reference:

Compiling avconv seemed more promising at first, but when running it we bumped into some weird runtime errors with swscaler. Couldn’t figure it out quickly, so focused on FFmpeg. We pulled down the latest Emscripten, and the latest FFmpeg:

git clone
git clone git:// ffmpeg

You may need to also get the SDK to make sure Emscripten will work. The have documentation on their site about getting this to work. Here are the basic configuration options we ended up using. Most of the configuration options are actually disabling features that either don’t make sense, or are there to save space. After a lot of trial and error, here is the minimal amount of flags to pass into emconfigure: --disable-ffplay --disable-ffprobe --disable-ffserver --disable-asm --enable-pic.

The first time we got a successful build it was a 100MB JS file. By removing a bunch of the other stuff, we get it down to 25MB. It could actually get smaller as well – we were unable to minify the script because the closure compiler process ran out of memory. The following commands are updated after we figured out some better options. The demo as it is right now doesn’t run any optimizations on the JS file, and it is about double the size. We can’t update the demo, as the weekend is over, but this commit is promising: ffmpeg.js: 190 additions, 1463201 deletions not shown.

emconfigure ./configure --cc="emcc" --disable-ffplay --disable-ffprobe --disable-ffserver --disable-asm --enable-pic --disable-doc --disable-devices --disable-pthreads --disable-w32threads --disable-network --enable-small --disable-hwaccels --disable-parsers --disable-bsfs --disable-debug --disable-zlib
emmake make;
emcc -O2 -s VERBOSE=1 -s ASM_JS=0 -s ALLOW_MEMORY_GROWTH=1 -v libavutil/*.o libavcodec/*.o libavformat/*.o libavdevice/*.o libswresample/*.o libavfilter/*.o libswscale/*.o *.o -o ../ffmpeg.js --pre-js ../ffmpeg_pre.js --post-js ../ffmpeg_post.js


The FFmpeg process runs inside of a web worker to prevent locking up the UI. This was the first optimization, as it was necessary for doing any testing on the project at all. Data is piped back from stdout and stderr to the frontend of the demo app, which is listening for these and logging them to a pre tag. This logging could be limited or removed to limit the impact on the DOM, as a lot of data can be generated by the system.

We experimented with firing up 2 different workers, one for the metadata probe and actual processing, and one for taking screenshots of a video right after receiving it. But we noticed some general instability when both were running at once (many times a tab or browser would crash), so we removed the screenshotting functionality. I’m sure we could have traced it down and improved the performance if we had more than a weekend for the project.

The processing itself is a little slow, but I haven’t done benchmarks to compare with native. I generally avoided processing videos of much size. Also, our demo app prints a lot of logs which may not be helping matters. We are looking into how to set up performance tests, but if anyone wants to help with this please let me know or submit a PR on the videoconverter.js project.

I believe this could be quite a bit faster – it couldn’t actually use asm.js because it is explicitly disabled when ALLOW_MEMORY_GROWTH is defined. It would be worth experimenting to see if we could set a large max memory size and enable asm to see what kind of speedup we saw.

I’m interested to see if we can get some sort of performance benchmarking set up to compare how fast it runs in different JavaScript environments, and to see how it compares with native performance.

Potential Uses

  • This could be extended to bundle other encoding libraries. I wasn’t able to figure out how to get the linking to work for libvpx, x264, libtheora, zlib, etc over the weekend, so certain formats cannot be encoded. It would be neat to have this functionality, as it would allow conversion into web friendly video, which could then allow further previewing and processing. As performance improves and FileSystem API support improve it may be possible to build a web-based video or audio editing tool using this.
  • Compile the other utilities – there are other programs that ship with FFmpeg that we are excluding right now. ffprobe in particular seems like it could be better for gathering the metadata after the initial load of the file.
  • As mentioned previously, this could be useful as a benchmarking tool.
  • Probably other things I haven’t thought of as well.

console.log helper function

Thursday, April 4th, 2013

I have often found it tricky to get a ‘just-right’ console.log wrapper in JavaScript. I would prefer to just type log, but writing a wrapper function is a little trickier than at first glance. A variation of this used to exist in the HTML5 Boilerplate plugin.js but is now missing.

I have two versions – one is bigger, and is intended for an application – it stubs out console methods when they don’t exist, and exposes a log function to the window. The second is portable – it is meant for use inside of plugins.

The neat thing about this technique is that this preserves the original line of code inside of the console.log statement, rather than the line in which the log function is declared.

The code is in a gist, which is also embedded below:

Devtools Colorpicker Palette

Saturday, February 2nd, 2013

I’m still trying to figure out how to get a list of all the colors in use on a page from within devtools, but I’ve been hacking together a little demo with a custom Web Inspector frontend that loads a color palette on the side.

When you click one of the swatches, it sets the current color of the element. The idea is that it would include all the colors in your page, maybe ordered by most used. Possibly could even get more advanced and suggest a set of complementary or analagous colors based on your current selection.

A prototype implementation of a palette using color swatches within devtools

A prototype implementation of a palette using color swatches within devtools

jQuery UI 1.9 Boilerplate

Wednesday, October 17th, 2012

jsbin has made having to remember some of these links less important. However, with jQuery UI 1.9 coming out, there are some CDN links that aren’t working. Here is the updated boilerplate I use to quickly test out a jQuery UI project. If all goes well, you should have a dialog that you can drag around and resize.

<!doctype html>
  <link rel="stylesheet" href="">
  <script type="text/javascript" src=""></script>
  <script src="" type="text/javascript"></script>
  <style type="text/css">
    #modal {
	 background: orange;
  <script type='text/javascript'>
    $(function() {
        $("#modal").dialog({ title: "It works" })
<div id='modal'>jQuery UI!</div>

As a bonus, here is the markup in jsbin.

TinyColor On npm

Wednesday, September 12th, 2012

I have published my TinyColor package to the npm repository – Unfortunately it is called tinycolor2 since tinycolor was already taken.

After running

npm install tinycolor2

You can use tinycolor like so:

var tinycolor = require("./tinycolor");

See the project homepage or the README for more info.

Devtools Colorpicker

Monday, July 2nd, 2012

It is great that so many important platforms that we use on the web are open source, and open to contributions from anyone.

It took a lot of work, but it was worth it. I’ve been doing some web design work recently, and love how much easier it is to play with different colors in a design.

Now I’m thinking of different ways that design work could be further improved with the colorpicker. A couple of ideas right now: (a) an eyedropper to select a color from the screen and (b) a color palette consisting of currently used and recommended colors.


Friday, June 1st, 2012

I have been working on updating the FileReader.js JavaScript file reading library lately to help out with a few different projects. This library has provided a quick way to get started with reading files on a few different projects, like and Instant Sprite.

One thing I noticed was that there is a FileReaderSync API, meant for loading files synchronously.

You might wonder why on earth would you want to load a file synchronously in your browser – that seems like it could block the entire UI until the file is loaded! It turns out you can’t, at least not in the normal window context. FileReaderSync only exists inside of the context of a WebWorker:


View a A working JS Fiddle using FileReaderSync.

I also wrote about how to load web workers without a JavaScript file, but this technique works just fine using a normal external reference.


<input type='file' id='files' multiple onchange='handleFileSelect()' />

page javascript

function processFiles(files, cb) {
    var syncWorker = new Worker('worker.js');
    syncWorker.onmessage = function(e) {
    };, function(file) {
function handleFileSelect() {
    var files = document.getElementById('files').files;
    processFiles(files, function(src) {
        var img = new Image();
        img.src = src;


self.addEventListener('message', function(e) { 
    try { 
        var reader = new FileReaderSync(); 
            result: reader.readAsDataURL(data)
   } catch(e){ 
}, false);

The jsFiddle demo is a little more complicated than this, since it handles checking for support and an inline worker.


Something that was a little weird is that since you can’t detect support from the main window, I need to spawn off a worker to post the message of whether it supports FileReaderSync. See a jsFiddle to detect FileReaderSync support. There may be a better way to do this, but I don’t know of it.

This can be pretty complicated, but I have been tying it all into the filereader.js plugin, to make reading with FileReaderSync just an option along with the standard FileReader


It’s hard for me to accurately measure the performance. On one hand, the FileReaderSync seems to load the images in a slower time per image (measured in milliseconds). I assume that this is due to the overhead and message passing with the worker, or possibly because it is a newer implementation.

However, on large images and videos, it definitely feels like the UI does not lock up as much when processing the files.


I feel like maybe part of the point of this API is when you want to some heavy lifting with the file after it is loaded but still inside the worker, which isn’t currently supported in FileReader.js. I could imagine ways this use case could be supported though (maybe by passing in a process() function as a string that the worker could call?

Check out the FileReader.js demo and see if you can tell a difference! I’d love to get any kinks worked out and get some feedback – I have been thinking of setting up a js-file-boilerplate project on Github to tie together a bunch of this functionality in a sample project.

Load Web Workers Without A JavaScript File

Friday, May 25th, 2012

Ever want to load a JavaScript Web Worker without specifying an external JavaScript file? There are a couple of different ways to do this by creating a blob and object URL – I wrapped this functionality up into a little plugin to share.

Here is the code. Or checkout out a working jsfiddle demo

// makeWorker is a little wrapper for generating web workers from strings
function makeWorker(script) {
    var URL = window.URL || window.webkitURL;
    var Blob = window.Blob;
    var Worker = window.Worker;
    if (!URL || !Blob || !Worker || !script) {
        return null;
    var blob = new Blob([script]);
    var worker = new Worker(URL.createObjectURL(blob));
    return worker;
<div id='log'></div>
<script type='text/worker' id='worker-script'>
    self.addEventListener('message', function(e) { 
        postMessage( / 2); 
<script type='text/javascript'>
// Load a worker from a string, and manually initialize the worker
var inlineWorkerText = 
    "self.addEventListener('message', function(e) { postMessage( * 2); } ,false);"
var inlineWorker = makeWorker(inlineWorkerText);
inlineWorker.onmessage = function(e) {
    document.getElementById('log').innerHTML += '<br />Inline: ' +;
// Load a worker from a script of type=text/worker, and use the getWorker helper
var scriptTagWorker = makeWorker(
scriptTagWorker.onmessage = function(e) {
        document.getElementById('log').innerHTML += '<br />Script Tag: ' +;

Drag Out Images and Canvas With Filenames

Thursday, May 10th, 2012

It can be annoying that when you drag out images of a browser window, they are named png.png (or something equally useless). I was playing around with fixing this – it is a little inconvenience in my CSS Sprite Generator that would be nice to have working (naming the file based on their input). Here is what I came up with (no library dependancies):

function dragoutImages() {
    if (!document.addEventListener) {
    document.addEventListener("dragstart", function(e) {
        var element =;
        var src;
        if (element.tagName === "IMG" && element.src.indexOf("data:") === 0) {
            src = element.src;
        if (element.tagName === "CANVAS") {
            try {
                src = element.toDataURL();
            catch(e) {  }
        if (src) {
            var name = element.getAttribute("alt") || "download";
            var mime = src.split(";")[0].split("data:")[1];
            var ext = mime.split("/")[1] || "png";
            var download = mime + ":" + name + "." + ext + ":" + src;
            e.dataTransfer.setData("DownloadURL", download);   
    }, false);

You just need to specify the alt attribute on the image or canvas to specify your name (along with the draggable attribute on canvas elements) and the script should handle the rest.

Browser Support

I am not 100% sure on browser support. This used to be Chrome only according to this HTML5rocks article, but maybe other browsers have picked it up by now. It is a neat little addition when available though.


See the full demo: drag out images with custom file name. This shows the ability to drag out both image and canvas tags.

On this page, you should be able to drag out the following colorpicker screenshot, which will be called spectrum.png.