Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Progress bar should handle the 0% case #12848

Closed
stubbornella opened this Issue Feb 25, 2014 · 21 comments

Comments

Projects
None yet
7 participants
Contributor

stubbornella commented Feb 25, 2014

I noticed that the progress bar doesn't handle the 0% progress case gracefully. The text is white on a light gray background and touches the edge of the outer bar.

http://jsbin.com/waver/1/

Perhaps I've not set some necessary variable or I was meant to add a class?

I ended up fixing it like this: (though it feels a bit clunky)

.progress-bar.progress-bar-zero {
  color: $text-color;
  min-width: 3%;
  background: transparent;
  box-shadow: none;
}

Happy to put together a pull request if this seems useful.

@cvrebert cvrebert added this to the v3.2.0 milestone Feb 25, 2014

Owner

cvrebert commented Feb 25, 2014

Confirmed. This problem applies more generally to any low percentage value with a decent amount of label text.

Contributor

stubbornella commented Feb 25, 2014

The docs suggest adding a min-width for low percentages. That worked well for me.

It was just the 0% case that really didn't work. Here is another (better, I think) solution that uses the aria-valuenow rather than adding a class name. For 1 and 2 values it sets the min-width. For the 0 value it changes the background color and text color to have readable contrast. Also makes it so it doesn't appear blue when the value is 0 (the min width was making this happen).

.progress-bar[aria-valuenow="1"],
.progress-bar[aria-valuenow="2"] {
  min-width: 3%;
}

.progress-bar[aria-valuenow="0"] {
  color: $text-color;
  min-width: 3%;
  background: transparent;
  box-shadow: none;
}
Contributor

stubbornella commented Feb 25, 2014

Probably better to use a specific var for color rather than $text-color.

Contributor

stubbornella commented Feb 25, 2014

Here's another jsbin with the working code: http://jsbin.com/juwij/1/

It does the following:

  • Solves the 0% case by changing text contrast, setting a min-width, and removing background-color and shadow styles from the progress bar
  • Solves the 1% and 2% case by setting the min-width to 3%
  • Changes the bar to red when it is over 90% (something we needed, but probably wouldn't belong in a pull request)
Owner

mdo commented Mar 5, 2014

Pushed up a change for this. I ended up using a fixed pixel width because single digit percentages are going to always be about the same size while the percent widths can vary greatly in computed widths.

@mdo mdo closed this in 24de9b0 Mar 5, 2014

Owner

mdo commented Mar 5, 2014

Thanks, btw! <3

ithcy added a commit to stevelaz/bootstrap that referenced this issue Mar 6, 2014

Merge remote-tracking branch 'upstream/master'
* upstream/master: (45 commits)
  fix #12936
  Run `grunt update-shrinkwrap`
  grunt-contrib-jade@0.11.0
  Fixes #12901: Refactors list group active state for use on non-anchors
  nav
  Fixes #12848: Account for and document progress bars at 0-3%
  use full version number in deprecation note
  clarify deprecation /cc @cvrebert
  Fixes #12697: Document readonly inputs
  docs for #12873
  grunt after merging #12917
  Grunt after merging #12863
  grunt
  Fixes #12868: Enables icon feedback on validation states for large/small inputs.
  Fixes #12913: Remove scoped media queries from custom xs grid mixins
  Fixes #12914: Darken immediate children hr elements in jumbotrons
  Fixes #12916: Don't let .lead resize on viewport change
  add svg logos to brand guidelines
  Update csscomb properties. 'colon-spac'e and 'stick-brace' don't take boolean values.
  grunt
  ...

Conflicts:
	dist/css/bootstrap.css.map
	dist/css/bootstrap.min.css

@mdo mdo referenced this issue Mar 7, 2014

Closed

v3.2.0 ship list #12736

cdmckay commented May 21, 2014

I'm not really sure why this was added? If your progress bar doesn't have text, it causes it to jump 30px for the first 3% points, then (depending on the size of the bar) jump backwards at 4%.

Why are we assuming all progress bars contain text anyway?

Owner

mdo commented May 21, 2014

@cdmckay Yeah, hear that. Maybe we remove the 1-2% thing? This might be too specific for particular use cases and not for everyone.

cdmckay commented May 21, 2014

@mdo Yeah, it was very confusing to me at first, as I couldn't understand why my progress bar was jumping around.

A further problem is that, even if someone has text in their progress bar, not everyone is putting "3%". They might be putting "3 / 100" or "300 / 1000", and there's no way to reliably handle that.

Owner

cvrebert commented May 21, 2014

@cvrebert There is always this:
white-text-black-background

Contributor

stubbornella commented May 21, 2014

We could move it to a modifier class &/or look for a different way of making sure text isn't cut off.

On Wed, May 21, 2014 at 11:28 AM, Jonathan Hefner
notifications@github.com wrote:

@cvrebert There is always this:

white-text-black-background

Reply to this email directly or view it on GitHub:
#12848 (comment)

@cvrebert Using text-shadow as per the article you linked (plus a filter for IE9) should get the desired effect, no? What issues do you foresee?

Owner

cvrebert commented May 21, 2014

@jonathanhefner What about IE8?

The Stack Overflow answer I linked to says the filter "works in IE5.5 through IE9."

Owner

mdo commented May 21, 2014

Lol, we won't be doing text stroke or shadow for this—thanks though @jonathanhefner.

@stubbornella If you have specific ideas, feel free to pull request something. I've got a few other things to peep first before getting back to this for the v3.2 release.

z4711 commented Jun 2, 2014

capture9

i want something like that, e.g. text over the progressbar under all conditions,

with the following css i was nearly able to resolve it (at least with IE 11)

.bgtask-bar > span
{
color: #000;
position: absolute;
margin-left: 6px;
width: 100%;
text-align: left;
top: 0; /* needs adjustment as span != block element */
}

but with FF and Chrome the text is not left aligned (and also not centered, something between)

capture10

another unwanted effect is this (the 0% percent effect), the progress text is clipped!
capture11

my related markup is:
capture12

(progress() is an observable and spans from 0..100, progressText() is a computed observable and provides the appropriate text info)

for any help appreciated

At the risk of repeating myself, see Thoughtbot's Refills for a fix to the original problem:

font-weight: bold;
color: #FFF;
text-shadow: 0px 0px 1px #000;

(To properly see it in action, you'll need to change the width of their .meter element.)

bitcity commented Jul 31, 2014

It took me a while to figure out the reason for unexpected progress-bar behavior was being caused by this CSS rule change. It's not a desirable default to have min-width for values 0, 1 & 2 only. Breaks the continuity and feels unnatural.

Owner

cvrebert commented Jul 31, 2014

This was subsequently reverted; see #13953.

@cvrebert cvrebert locked and limited conversation to collaborators Jul 31, 2014

stempler pushed a commit to stempler/bootstrap that referenced this issue Nov 4, 2014

stempler pushed a commit to stempler/bootstrap that referenced this issue Nov 4, 2014

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.