[Progress Bars] Stacked progress bars have a rounding error

[SteffanLong]

With certain parameters, the resulting bars will have a combined width that is greater than 100%, forcing the last stacked progress bar to a new line. This is on version 0.13.1.

Code to reproduce:

<progress max="433">
  <bar value="60"></bar>
  <bar value="103"></bar>
  <bar value="270"></bar>
</progress>

The resulting widths will end up being: 13.86%, 23.79%, and 62.36% for a total of 100.01%

[wesleycho]

This sounds like it will require a tricky solution to solve. One solution could be to compute the hundredth decimal place value for each bar, and determine which value to round up or down for setting the bar width.

It won't be performant for large # of bars, but I think it is safe to assume that there won't be many stacked bars, or at least it isn't a UX we want to support.

[SteffanLong]

For what it's worth, we solved this problem by computing the total percent width of the bars and if it was over 100, we found the first bar with a width over 0% and subtracted the amount over 100.

We did something similar if it was under 100 also.

Not the best solution, granted, but it works. The combined width is always 100% and at most one bar is +_ 0.01% off.

I can contribute our fix if you like.

On Jul 27, 2015, at 12:20 PM, Wesley Cho [email protected] wrote:

This sounds like it will require a tricky solution to solve. One solution could be to compute the hundredth decimal place value for each bar, and determine which value to round up or down for setting the bar width.

It won't be performant for large # of bars, but I think it is safe to assume that there won't be many stacked bars, or at least it isn't a UX we want to support.

—
Reply to this email directly or view it on GitHub.

[wesleycho]

Sure, I think that is an amenable fix, since at worst, it would only result in a few pixel difference.

[SteffanLong]

I submitted a pull request that fixes this issue.