incaseofstairs

Recently heard about the relatively new jsPerf service that Mathias Bynens has created and after spending some time playing around with this on my own machine I can honestly say that I love this service. Rather than a few gushing tweets on the subject, I felt like this deserves a blog entry covering it’s coolness.

The thing that I found the most striking about the site (and most likely the reason that I am writing this now) is that it broke many of my previous assumptions about performance of specific statements and relative performance of different platforms. Is innerHTML faster than DOM manipulation when generating a DOM tree? Not for a specific (relatively simple) construct under Chrome (OS X v5). Is array.join(”) the fastest way to concat a string. On my test platforms (OS X Firefox, Safari, Opera, Chrome release versions), nope.

Being a public playground, the community benefits from the collective knowledge. Scanning through the test list I saw many of the problems that I have run into before as well as some I had never considered such as the multiple methods of performing a Math.floor operation. While some of these honestly scare me and remind me of Kernel code, it’s good to know they exist.

jsPerf has full support for mobile browsers as well, meaning that you can test performance test the various algorithm options on device and have a realistic view of how it will behave on the device. In running some of the tests on a webOS device there were some quite distinct differences between comparable environments on a desktop class machine.

As with any performance testing I would recommend running these tests multiple times on your target device(s) before selecting a particular path to use as there are many things that could cause a single test to provide inaccurate results for a given execution, particularly on the more resource constrained environments.

Great job Mathias and can’t wait to see what features are added to this as well as the content that the community creates!

Facebook Add Tag Interface

Yesterday we released Facebook for webOS 1.2.5 Beta which brings many improvements to our photo functionality including tagging support. Now that the release is out the door, I’d like to take some time to discuss the cooler aspects of the implementation particularly the Add Tag UI.

Design

The core layout of the Add Tag UI is an overlay container containing a fixed position header and a scrolling list below that. The entire screen is covered by these two elements, with the header section maintain its height and the content section expanding to cover the remainder.

This fixed header layout is fairly common throughout the app, the most common example being the navbar used in the majority of the application’s scenes, and is fairly easy to solve if the header is a fixed height and the content scrolls under the header. All that needs to be done is to position the header control using position: fixed and apply a margin-top to the list such that the first element in the list appears at the bottom of the fixed element.

I’ve never really like this solution as it requires that the header height be fixed and the list section be “aware” of the header rather than being only concerned about it’s own layout. With this in mind (and also wanting to play around with some of the cool things that WebKit offers but I have not been able to use on projects due to the IE factor), I decided to try out the flexible box layout type in webOS.

Flexible Box Layout

To provide some background, one of the key goals of the flexible box layout module is the ability to specify the size and growth of an element relative to both it’s siblings and it’s parent. While this was previously possible by using percentage layouts, each of the elements had to be aware of the size that their siblings expected and all elements needed to use the same relative system.

This is not the case with this layout scheme. Rather than defining a percentage of the container size, elements are defined with an affinity for the excess space in the container. This means that the layout first attempts to fit everything as it would normally layout, then adjusts each element based on the difference in size between the children and the parent. In practice this can generate much more stable, but still fluid layouts when creating applications in HTML+CSS.

The box-flex (-moz-box-flex, -webkit-box-flex) is used to define the resize affinity.

Values here can range from zero to any positive decimal value. When the value is zero, the element will not change size based on extra or lack of space in its parent. When this value is larger than zero the element is considered flexible. This means that when the layout engine determines that the parent box is either overflowed or underflowed these elements will expand or shrink such that all of the children fill the container. The differences in magnitudes of this value determines how the flexible elements are resized.

As an example a vertically oriented flexible box with 3 children whose flex values are 0, 1, and 2 and has 60px of open space will add 20px to the second element, 40px to the third element and leave the height of the first unchanged. On the other end of the spectrum if there is an overflow of 60px, the elements will be shrunk by the same dimensions above.

The flexible box model is supported by Safari 3+, Chrome 3+, Firefox 3+, and of course webOS. As covering the entirety of the specification was out of the scope of this post I would recommend reading some of the other excellent sources on this topic as well as the specification itself.

Implementation

For the Add Tag UI, we take advantage of the flexible overflow case outlined above. This allows the upper section to layout at it’s natural size using -webkit-box-flex: 0 and the user list section to expand to fill the remainder of the page using -webkit-box-flex: 1. By defining the list section to be a Scroller with an embedded List, we can maintain fixed behavior for the upper section and still allow for an arbitrary number of users.

Implemented this looks something like the following:

<div class="tag-selector">
  <div class="tag-selector-panel">
    <div x-mojo-element="TextField"></div>
    <div class="form-wrapper">
      <div x-mojo-element="Button"></div>
      <div x-mojo-element="Button"></div>
    </div>
  </div>
  <div class="tag-scroller" x-mojo-element="Scroller">
    <div x-mojo-element="List"></div>
  </div>
</div>

With the CSS doing most of the heavy lifting:

.tag-selector {
  position: absolute;
  top: 0;
  left: 0;
  bottom: 0;
  right: 0;

  z-index: 1000;

  display: -webkit-box;
  -webkit-box-orient: vertical;
}

.tag-scroller {
  position: static !important;
  -webkit-box-flex: 1;
}

A live demo for Firefox and Safari/Chrome available is available here. Note that the demo is running a modified version to handle desktop and cross-browser differences. These are mostly experimental prefix concerns i.e. display: -webkit-box becomes

    display: -webkit-box;
    display: -moz-box;
    display: box;

Although there are a few hacks in place to force common layout under both WebKit and Gecko (See Bug 570036). Such is life developing with CSS3 :)

Future Posts

As a final note, I’d like to start a series of these posts. Are there any sections of the Facebook app that you would like me to provide an overview of their implementation? Feel free to comment on this post or drop me a line at kpdecker@gmail.com.

This article covers the techniques used to implement the local file access feature that is included, along with tiling support, alternate styling, and parameter optimization, in the most recent push to border-image-generator.

One of the biggest short comings that I felt like border-image-generator was that all files had to be posted on a HTTP server due to restrictions on the access to the file:// protocol. In my personal workflow this was somewhat of a pain, so I set out to find a way around this issue.

During the design of this feature, I quickly decided that all data must remain on the client as I did not want to upgrade my hosting service to include more bandwidth, felt like responsiveness could be a concern, and do not want to tangle with the potentially messy privacy issues that could arrise from storing user generated images on my server.

While this sounded like a daunting task, it turns out that this was possible, in sufficiently advanced browsers, using a variety of HTML5 techniques, including Data URIs, the File API and the Web Storage API.

Display

The problem of displaying the image was the easiest to solve as all of the targeted browsers support data URIs as part of the border-image property. This allowed the application to generate URLs like the following

    border-width: 46px;
    border-image: url("data:image/png;base64,iVBORw0KGgoAAA....") 46 stretch;

And operate as expected. Data URIs have been covered fairly extensively elsewhere, so I will leave this to the reader to investigate.

Reading

With the actual display issue solvled, there was still the non-trivial issue of actually loading the content. My initial investigations involved Flash, which provides FileReference.load API which allowing for this functionality, but under the version I was testing on this API is only usable if invoked in response to user input. Being a HTML guy and lacking functional knowledge of the Flash development process I quickly ruled this technique out.

Continuing my research I came across an article on MDC that covered this exact use case, using the draft File API specification. This worked like a charm, even exposing the ability to read the image contents directly into a data URI.

The API is very clean for use cases such as this:

function loadFile(file) {
    var reader = new FileReader();
    reader.onload = function(event) {
         updateImageURI(file.name, reader.result);
     };
     reader.readAsDataURL(file);
}

Where the file variable above is a File object retrieved from a

<input type="file">

or the dataTransfer object passed to the drop html event.

        $("body").bind("dragenter dragover", function(event) {
            // We have to cancel these events or we will not recieve the drop event
            event.preventDefault();
            event.stopPropagation();
        });
        $("body").bind("drop", function(event) {
            event.preventDefault();
            event.stopPropagation();
            var dataTransfer = event.originalEvent.dataTransfer,
                file = dataTransfer.files[0];

            loadFile(file);
        });
        $("#localImage").bind("change", function(event) {
            var file = this.files[0];

            loadFile(file);
        });

This unfortunately is not without it’s issues. The File API is very much bleeding edge at this point and support is somewhat limited. As of this writing Firefox is the only browser which features this in production (Version 3.6). Support landed in the WebKit trunk literally earlier this month and can be used in their nightlies, but so far has not made it into any production releases.

The site is currently designed to progressively enhance as it detects support for the File API, so no need to worry about being left out of the site as a whole if you are not on one of these browsers yet.

History

After loading the content using the File API, the original implementation utilized the same #hash storage method for the data URIs, but this proved to be problematic as these strings can become quite large and interacting with these URLs was unwieldily. Needing another data store and being forced to maintain a cache of all local images due to the security model employed by the File API, we were left the options of storing all data in Javascript space or using the new Web Storage APIs implemented as part of HTML5.

Examining both options it seemed the the best course was to utilize the sessionStorage object when available and fail over to the javascript data model when not.

    // Check for browser support of session storage and that it is accessible
    // This may be inaccessible under certain contexts such as file://
    function supportsSessionStorage() {
        try {
            return !!window.sessionStorage;
        } catch (err) {
            return false;
        }
    }
    var localDataBinding = (function() {
        if (supportsSessionStorage()) {
            // If they support FileReader they really should support storage... but who knows (With the exception of file://)
            return {
                storeImage: function(name, data) {
                    var entryId = (parseInt(sessionStorage["imageList-count"])||0)+1;
                    sessionStorage["imageList-count"] = entryId;
                    sessionStorage["imageList-src-" + entryId] = data;
                    sessionStorage["imageList-display-" + entryId] = name;
                    return entryId;
                },
                getImage: function(entryId) {
                    return { src: sessionStorage["imageList-src-" + entryId], displayName: sessionStorage["imageList-display-" + entryId] };
                }
            };
        } else {
            // Fail over to plain js structures, meaing that refresh, etc will cause failures.
            var cache = [];
            return {
                storeImage: function(name, data) {
                    cache.push({ src: data, displayName: name });
                    return cache.length-1;
                },
                getImage: function(entryId) {
                    return cache[entryId];
                }
            };
        }
    })();

Working with this API it seems as though it is still somewhat rough. The vendor documentation all state that supported datatypes are only string values (Mozilla, WebKit), but the spec implies that this will change be final release and allow for storage of a much broader set of datatypes.

A consequence of this design is that boomark and URL sharing for local files is not a possibility. For users who need to share or store application states the image in question will need to be stored on a HTTP server and accessed by this route.

These changes as well as some incremental changes have been pushed live on border-image.com and are available in the github repository.

When developing for a platform that relies on asynchronous APIs, such as webOS, the application logic frequently will need to block on a given operation prior to executing other dependent components. This may include anything from loading user data after authentication to saving data after initialization of a given data structure among others.

One method of handling this problem is to make the blocker component explicitly aware of the dependent components and the unique interface to each component, which works for simple cases or situations where the dependent to blocking relationship is one-to-one, but this quickly becomes complicated as a number of dependent components grows. In the extreme cases the blocker may have to be aware of significant portions of the system, leading to maintenance concerns.

Alternatively the blocker call can allow dependent components to register their interest in the completion of the operation and upon completion the blocker can simply notify the components on this list in a generic fashion. This allows that components to remain loosely coupled and has the added benefit of allowing for run-time conditional relationships without requiring that the blocker be aware of the state of the dependent.

Implementing such a notification system is fairly straightforward in Javascript: Simply collect waiting callbacks in an array or other structure then executing each upon completion of the blocking call.

Library

While simple to implement, my experience onFacebook for webOS has shown that a library to implement this behavior is worth the initial effort as manually writing nearly identical for loops over callbacks for the umpteenth time becomes tedious and error-prone.

To this end, we developed and open sourced the OperationQueue class which provides a common implementation that doesn’t require far too many for loops :)

Usage

To use the OperationQueue class you simply need to enqueue your dependent operations using the queue API.

queue can accept a single function which will be called upon successful completion.

    opQueue.queue(function(result) {
        // Do something with the data that we were waiting for!
        console.log("Blocking Operation Completed!");
    });

It also accepts an object with any combination of onSuccess and onFailure fields who will be called for each respective event.

    opQueue.queue({
        onSuccess: function(result) {
            // Do something with the data that we were waiting for!
            console.log("Blocking Operation Completed!");
        },
        onFailure: function(result) {
            console.log("Blocking Operation Failed");
        }
    });

These calls may occur at anytime. If the blocking operation has already completed then calls to queue will result in immediate execution of the queued operation. In this case the result object will not be included.

For the blocking call itself the getSuccessHandler and getFailureHandler generators will return callback functions that may be used to directly on completion or may be passed as callback handlers to the async API. These methods also accept a function parameter which will be called prior to their completion.

Used directly:

(opQueue.getSuccessHandler())();

As a callback:

ServiceRequestWrapper.request('palm://com.palm.preferences/systemProperties', {
        method:"Get",
        parameters:{"key": "com.palm.properties.nduid" },
        onSuccess: opQueue.getSuccessHandler(function(response) {
                Mojo.Log.info("Device ID: %j", response);
            }),
        onFailure: opQueue.getFailureHandler()
    });

For more complicated use cases, the reset function allows for enabling and disabling queuing at any time. For example, if you need to initially allow all operations to proceed and then block only while a given operation is in progress, the getSuccessHandler API may be called immediately after instantiation of the queue and then reset called prior to execution of the blocking operation.

Source:

Operation queue is available in the webos-samples repository on github, within the tipsAndTricks subproject.

One final note: While this was written for a webOS application, it does not depend on any webOS-specific constructs and may be used in any Javascript environment. To see it in action, check out the demo in any browser!

Update: border-image-generator is not hosted on border-image.com. The previous URLs are configured to redirect to this url.

The CSS3 border-image property allows for some very cool and efficient design but after implementing them in both Mozilla for the Firebug search panel and WebKit for the Palm Facebook notifications badge, I’ve learned that they can be quite frustrating to properly tweak by hand.

Background

For those who have not been exposed to this property, it allows a single image to be used to style the borders and background of a particular element. In the example above, each section will map to a different border, corner, or the content background, allowing for a single element and image to provide styling the previously required significantly more of each.

Using these properties the following element can be rendered using simple semantic HTML and CSS.

<div class="stylishContent">Some stylish content</div>

.stylishContent {
    display: inline-block;
    border-width: 27px 27px 27px 27px;
    -moz-border-image: url(http://www.w3.org/TR/css3-background/border.png) 27 27 27 27; -webkit-border-image: url(http://www.w3.org/TR/css3-background/border.png) 27 27 27 27;
    border-image: url(http://www.w3.org/TR/css3-background/border.png) 27 27 27 27;
}

For more detail, John Resig has published an excellent writeup on the Mozilla implementation.

App

As noted above there is a bit of tweaking involved in getting these settings right. To ease some of this pain I’ve created the border-image-generator project, which allows for WYSIWYG editing of these properties. Rather than manually adjusting each parameter, border-image-generator allows the various parameters involved to be changed visually with instant preview of what these changes will look like in the current browser.

Seen in action demonstrating Resig’s examples here and here.

Features

• WYSIWYG editing of border-image properties
• Cross-browser border-image CSS generation
• URL-based State (History + Preview in multiple browsers)

It can be accessed through any of the following URLs:

• border-image
• github/kpdecker/border-image-generator

Any issues or suggestions for improvements can be sent to myself or logged in the github issue tracker.

Warning

As a preliminary warning this is currently a vendor experimental feature but it is currently set to be included in the CSS3 specification. There are some significant differences between the vendor implementations and the W3C candidate, so some caution should be used. Border-image-generator attempts to handle these cases as defined by the spec, but many things could change between the current implementations and the release of CSS3 implementations in the wild.

Related Links:

• MDC -moz-border-image Property
• ADC -webkit-border-image Documentation
• W3C Standard Documentation
• John Resig’s article
• Suburban Glory’s article

After more than a year of development I am absolutely ecstatic to announce the 1.0 release of Firediff. There were quite a few hiccups due to personal commitments in this development cycle, but I feel like this release is quite solid and brings quite a few must have features.

As noted in the previous alpha and beta announcements, this release adds many key features to the 0.2.1 release:

• Revert Changes
• Save Snapshot
• Save Diff
• Document Formatters
• Search
• Activation Data Handling Improvements
• Style attribute change handling

At this point I have achieved the majority of my initial goals for Firediff and feel as though it fits most of the realistic needs that I originally envisioned when I set out on this project. From this point onward the community is even more vital in defining the future direction of Firediff as I am looking for additional features that can be implemented.

The following features and fixes are currently under consideration for future releases but we are looking for more to implement.

• Filtering of the changes view
• Stack trace
• Free Edit Diffing
• Entire tree diffs on insertion or removal
• Improved handling of inline stylesheets
• Iframe Support
• Parity changes with Firebug enhancements

Any input from the community in terms of feature request or code contributions that will help improve the quality of the project. If you have a cool feature that you would like to see implemented in Firediff, please feel free to file bugs or enhancement requests with the fbug project or contact me directly.

Version 1.0 is available on here and has been seeded to AMO (Under review as of this writing).

The first feature complete beta for Firediff 1.0 has just landed here. This release allows for customization of the format saved by the save snapshot and diff features. Also included are some minor bug fixes and official support for Firefox 3.6 and Firebug 1.5.

This release has also been registered on Babelzilla (along with Firefocus) and any translators are welcome to provide their input.

Bugs may be filed with the fbug issue tracker.

As part of my day job I recently needed to debug focus handling within a AJAXy web app and found that logging and visualizing of this was quite difficult. To assist with this task I spent some of my personal time developing Firefocus, a Firebug extension for tracking keyboard focus at the HTML node level within Firefox.

Firefocus provides the ability to log all focus and blur events to the console as well displaying the element which currently has focus on the HTML panel, particularly helpful for tracking down the nuisance element that managed to inject themselves in the tab order but are not displaying the focus status properly.

This extension supports Firebug 1.4 and higher and is available here.

Firediff recently hit a major milestone, with the implementation of major portions of the save snapshot and save diff features. These as well as the revert and search features are available in the most recent alpha.

As a somewhat preemptive warning, the save diff feature is not likely to generate a line for line match that can be applied directly to the source files. This is due a number of reasons, including performance optimizations in Firefox that cull information that is not vital to the final rendering of the page and the large number of coding styles that exist in the wild.

We are currently investigating the options that we have to improve this, although the current iteration should be treated as a  a serialized version of the page state that the designer or developer can use to manually update the source files, rather than something that can be automatically applied to the source using patch or another method.

Feel free to comment on this post or email me at kpdecker AT gmail.com with any input on these features or any of the other Firediff features.

Due an a conflict between one of the libraries used by Firediff and just about everything else, I have pushed the Firediff release schedule forward some and rolled a 0.2.1 release.

This release includes fixes for the extension conflict, a new text diffing algorithm that will hopefully give better results as well as provide the basis of the unified diff feature that is planned for 0.1, and a few minor bug fixes to the Snapshot UI.

Thank you to all of those who notified me of this conflict.