feat(progressbar): allow fractional values for bar width

[tjgrathwell]

I was trying to get the animation of the progress bar to match the transition speed (.2 seconds by default) and couldn't get it to work exactly right for my code because the progress bar was always fitting to integer percentages.

I don't think there is any technical reason that the progress bar should be limited to integer steps. Here, I've used $filter('number') to truncate the progress bar value to a max precision of three decimals. Now, it can cover a larger range of values than just integers, but pathologically long fractions like 0.33333333333 won't creep in to the DOM.

[bekos]

You can inject just numberFilter instead.

[bekos]

@tjgrathwell Thx for the PR. There is no technical reason to limit the progressbar to integer steps other than it's pragmatic use. What i mean is that the progressbar is just an indicator. Having a progressbar that supports 3 decimal digits, means that it's width is 100.000 pixels. I don't think that users can observe such changes or care to count pixels to know if they are at 35.567 instead of 35.568 :-) IMO, if you want to be that accurate you have to add a text hint.

Anyway, I could accept to have one decimal digit, but my main concern is the screen reader user and that have to read and be notified for such small changes. @ndarilek What is your opinion on this?

I have also left some comments on the code.

[tjgrathwell]

@bekos I've made the changes you listed. I like the default behavior of numberFilter over toFixed, because numberFilter preserves "60" as "60" rather than "60.00", but this is a minor issue. Oddly numberFilter(60, 2) always returns 60.00, and numberFilter says it uses "the current locale's number formatting pattern", which I guess would sometimes be wrong. So I'm probably talking myself out of it as I type this.

I think the width value for the progressbar should have as much resolution as necessary to show down to the correct pixel on a reasonable screen, which could be 1000 pixels or more at the fringes. Maybe three decimals is too much, but I don't think the computer is going to mind. If the main issue is screen readers, we can still round the number when populating the aria attributes.

[tjgrathwell]

@bekos I've pushed a revised version that uses toFixed(2) (but scrapes off unneeded zeroes) and omits decimals entirely from aria-valuenow and aria-valuetext.

[bekos]

@tjgrathwell You probably didn't notice the plus sign in front of the expression. You can do it like: +(100 * value / $scope.max).toFixed(2) to cut the trailing zeros.
Other than that I am fine with the changes.

[tjgrathwell]

@bekos Indeed I did not notice it. Pretty clever. Sorry to throw all those 📚 words 📚 at you when that was the right answer all along.

I've pushed an updated version.

[bekos]

Thx @tjgrathwell :-)