The only comment I have is: the default selection of the inclusion rule filter is to specify 'any' that has 'passed'. It should default to 'all' that have 'passed', because that's the default view that people are interested in., which also matches the 'matched' statistic at the top of the report.

I take it back, I played with this locally and when you set it to 'all passed' by default, the only box that lights up is the 'all passed' box (makes sense, right??) Instead, 'any passed' makes sense from a backwards-compatable perspective, because each box represents a case where at least 1 passed, so the visualization looks the same between versions when you start with 'any'. So, we'll leave it with any, unless we get some feedback where the 'all' default makes sense such that only the lit part of the graph represents the 'matching' population,....I honestly could go either way, but i'll change it back to 'any' because it makes the visualization look the same by default.

@anton-abushkevich , I've pushed up a commit as a suggestion on some restructuring of the code. I noticed the use of subscriptions and the need to call out to greyRectsInTreemap at strategic places, but there's a more 'automatic' way to handle this using the observables. I kept much of our code, but with the following changes:

1. Removed Subscriptions: instead of subscribing to different observables and taking actions based on subscriptions, instead I introduced an afterRender hook to the population treemap binding which is called after the SVG is rendered. It is in this handler that we can do the work of graying out checkboxes. Because this is invoked in the data-binding update(), any observable that is referenced (such as the selected inclusion rules, any/all and pass/fail options) will automatically force a refresh on the treemap when their observable udpates. This also removes the need to remember to call greyRectsInTreemap because of the automatic depenency tracing will signal the refresh if any dependencies update.
2. Removed updates to observables in a loop: I noticed there was some obserable updates (like a running total of events) during the rectangle loop, and instead I just declared a local variable and made one observable update after the calculation.
3. Removed references to elementId (ie: using jquery to find an element by id): we should avoid trying to reference elements by id, By adding the hook to the databinding, we can get the element that is bound to the data-binding without getElementById, and pass it back in the hook.

Those are the main changes. I'm sorry to push directly into your branch, but I wanted to try to present a best practice when dealing with databinding and observables. If you have any objections, we can always revert this commit and come at it a different way.

Sorry about the force push (it was a quick bugfix I made in the loop of rectangles). It shouldn't impact you.