Share this:

Like this:

Some great news for BackstopJS users – Screenshot paths are now configurable!

This update enables two highly requested use-cases…

1) BackstopJS now plays nice with source control
Pointing your reference file paths to a location that GIT or SVN can pick it up means that reference data generated across branches will always stay in sync.

Share this:

Like this:

Two new features

Announcing a TremulaJS version update, 1.1.0. This version adds two important features, first, Mocha.js tests and second, by popular request, native crossAxis event passing.

About crossAxis event passing

The TremulaJS scroll axis is configurable as horizontal or vertical. Internally, this is referred to as the scrollAxis while the orthogonal axis is termed the crossAxis.

To the browser, any TremulaJS DOM object looks like a plain old static page element. (These are manipulated around at 60 frames per second for our UX benefit). When a native touchmove or scrollwheel micro-event happens, the default browser behaivior in many cases is to move the viewport contents around. This also includes our parent TremulaJS instance which in our case, is not (always) what we want.

In prior versions, all micro-events are shunted by TremulaJS — thus preventing any counteractive native behaivior. TremulaJS is mainly concerned with a macro-event stream emitted by the awesome Hammer.js library. This delegation strategy works great if you have a Tremula view which occupies the entire page. But what if you have content stacked before and/or after one or more TremulaJS modules? In the past you’d be stuck with no way to scroll to other page level content on the crossAxis.

In 1.1.0 this is resolved. TremulaJS now assigns each micro-event a directionality ratio. Events that move (more or less) perpendicular to the scrollAxis are trapped while events moving along the crossAxis are passed — and passed events are free to bubble up the DOM in a native kind of way.

So, to the developers requesting this feature, please give it a try — espically for iOS applications. I hope the response feels natural to you, even in cases where the user is not quite scrolling perfectly side-to-side or up-and-down.

So, the above runs when a call comes in for data. On the PhantomJS side we have this… ./phantom/phantom_job.js which runs in the Phantom context. Since you can’t share objects directly, all communication is done with events.

There is a lot of room for iteration here — for starters, you may have noticed the 2 second bootstrap time for Phantom. In general though, there is a lot of activity in this server-side DOM rendering space. I think SleepyHollow is a novel approach worth looking at for those of us working on the Node-PhantomJS problem.

Put another way, TremulaJS can be thought of as an extremely bad-ass image slider.

While there are some monumental physics-based JS animation frameworks out there — most notably, famo.us, gsap and velocity.js — TremulaJS was built with a very specific end in mind: to enable the kind of long-running, low-friction user interactions one might enjoy when navigating large sets of visual data.