We should create a new type of trace for waterfall charts. These are very useful for understand how sums decompose/recompose into each other, see: http://support.zebrabi.com/contribution-analysis-waterfall-charts/
This would be distinct from bar charts in that the position of each bar depends on the position of the previous one, without the trace having to contain this math.
Highcharts has a neat way of dealing with the "computed remnants" by having a flag on certain values that say "take this bar down to zero": https://www.highcharts.com/demo/waterfall
see also #1015
Multiple waterfall trace types on the same subplot would work like grouped bars, with each waterfall being independent, similar to:

I could see the API being just x and y with the magic y value of NaN causing the 'computed' case. We could then provide increasing/decreasing styles, like we do in financial traces, as well as computed styles, line styles etc. And the hoverlabels would indicate the delta, which we cannot currently do with offset bar traces.
@etpinard is my data proposal above reasonably clear or... ?
Essentially this models waterfalls a lot like lines, with special handling for nan, and different rendering/hovering
Unfortunately this kind of thing wouldn't quite be possible: we wouldn't be able to stack the green and orangy ones... they would be split:

the magic
yvalue ofNaNcausing the 'computed' case.
Hmm. That sounds a little bit inconsistent with our current API. Currently, NaNs are handled like other non-numeric "bad" values (e.g. null and undefined): they get skipped and don't show up on the graph. We did get a similar proposal in https://github.com/plotly/plotly.js/issues/2941, but I'm not sure I like it. Note that NaN is not JSON.
What if instead we had an array attribute with the same length as the coordinates e.g.
sums: ['', '', 'intermediate', '', '', 'total']
where items with '' would show up as waterfalls.
We could do that instead, yep. That would allow us to define something like the two-up stacks in the image above.
I think we should support multi-cat here, as well as hovertemplates btw. Also note we will want to support text display which should be the delta value, not the absolute value (and the start, delta and end values should be available in the hovertemplate if possible). We'll also likely need to add support for 'accounting' style negative numbers (i.e. in parens) if we don't already support this elsewhere.
We'll also likely need to add support for 'accounting' style negative numbers (i.e. in parens) if we don't already support this elsewhere.
That one is interesting. d3's v4 number formatting module has a way to do this. From https://github.com/d3/d3-format#locale_format
( - nothing for zero or positive and parentheses for negative.
so perhaps we should just wait for us to bump d3 to get this feature "for free" without having to add another attribute.
Is there any way of swapping in the v4 version of the formatting module for the one we currently have?
Yeah, we could do that. The entire d3-format module is 4.6K minified, so it wouldn't be a big (big) deal.
Here's an example of waterfall charts that I've created for clients with Dash (these are created with bars).

Some notes:
Total bar on the far right is auto calculated. It's style should be customizable: the name ("Total"), the color (default e.g. rgb(30, 30, 30)