<progress> bar rounding cut off when max != 100

[bschaeffer]

When a <progress> element's max attributes is over 100, the rounding is cutoff.

For me, this issue popped up when I was displaying progress bars in a table.table element, but occurs outside of it as well. Here's an example:

http://www.bootply.com/X7zC8gJyLG

Though most examples of progress elements on the web use a max value of 100, I could find no documentation that 100 is the max allowed value.

[twbs-lmvtfy]

Hi @bschaeffer!

You appear to have posted a live example (http://s.bootply.com/render/X7zC8gJyLG), which is always a good first step. However, according to the HTML5 validator, your example has some validation errors, which might potentially be causing your issue:

• line 43, column 16 thru line 44, column 26: th start tag in table body.
• line 52, column 17 thru column 55: Element div not allowed as child of element progress in this context. (Suppressing further errors from this subtree.)
• line 64, column 17 thru column 55: Element div not allowed as child of element progress in this context. (Suppressing further errors from this subtree.)

You'll need to fix these errors and post a revised example before we can proceed further.
Thanks!

(Please note that this is a fully automated comment.)

[bschaeffer]

Revised example: http://www.bootply.com/E0twbUEAoy

PS:

• Error 1: Tables > Basic Example
• Error 2 & 3: Progress Bar > IE

[twbs-lmvtfy]

Hi @bschaeffer!

You appear to have posted a live example (http://s.bootply.com/render/X7zC8gJyLG), which is always a good first step. However, according to the HTML5 validator, your example has some validation errors, which might potentially be causing your issue:

• line 43, column 16 thru line 44, column 26: th start tag in table body.
• line 52, column 17 thru column 55: Element div not allowed as child of element progress in this context. (Suppressing further errors from this subtree.)
• line 64, column 17 thru column 55: Element div not allowed as child of element progress in this context. (Suppressing further errors from this subtree.)

You'll need to fix these errors and post a revised example before we can proceed further.
Thanks!

(Please note that this is a fully automated comment.)

[bschaeffer]

Ugh: http://www.bootply.com/E0twbUEAoy

[twbs-lmvtfy]

Hi @bschaeffer!

You appear to have posted a live example (http://s.bootply.com/render/E0twbUEAoy), which is always a good first step. However, according to Bootlint, your example has some Bootstrap usage errors, which might potentially be causing your issue:

• line 40, column 3: E003: Found one or more .rows that were not children of a grid column or descendants of a .container or .container-fluid
• line 67, column 3: E003: Found one or more .rows that were not children of a grid column or descendants of a .container or .container-fluid
• line 73, column 3: E003: Found one or more .rows that were not children of a grid column or descendants of a .container or .container-fluid

You'll need to fix these errors and post a revised example before we can proceed further.
Thanks!

(Please note that this is a fully automated comment.)

[bschaeffer]

This is stupid

[wolfy1339]

Fixed up example: http://www.bootply.com/HgDioZygC1

[cvrebert]

Looks like the current code assumed that value was always a percentage and didn't account for max:

bootstrap/scss/_progress.scss

Lines 46 to 52 in 6384789

	// Tweaks for full progress bar
	.progress[value="100"]::-moz-progress-bar {
	@include border-right-radius($border-radius);
	}
	.progress[value="100"]::-webkit-progress-value {
	@include border-right-radius($border-radius);
	}

Perhaps we should just always apply the border-radius regardless of the fill level?

[eliottrobson]

I think always applying it would be the best option. #18835 discusses the potential to stacking and the main discussion is, are we planning on bringing stacking progress bars back? If we are then the progress element itself becomes irrelevant because it's non supporting. Dropping support for stacking and always rounding has my vote.

[cvrebert]

are we planning on bringing stacking progress bars back?

Probably. But that doesn't imply dropping support for <progress> for non-stacked bars.

[patrickhlauke]

...just to point out that providing a sensible, live-updating and screenreader friendly way of providing stacked bars is...non-trivial ;)

[cvrebert]

"Include a screenreader-only <table> with the same data, sprinkle with ARIA attributes, and pray to the dark god Cthua11yhu?" 😜

[patrickhlauke]

heh, indeed. in seriousness, if it's only a stack of 3-4 different bars, it possibly best to make it a visually hidden live region that reads the whole thing as one short sentence ("foo: 10%; bar: 23%; baz: 92.4%") but once you have more separate elements, it starts getting really tricky...