2014-07-11 15:45:11 -07:00
---
2015-08-14 22:45:55 -07:00
layout: docs
2014-07-11 15:45:11 -07:00
title: Progress
2017-05-27 23:01:14 -07:00
description: Documentation and examples for using Bootstrap custom progress bars featuring support for stacked bars, animated backgrounds, and text labels.
2015-08-05 17:47:45 -07:00
group: components
2017-05-27 23:01:14 -07:00
toc: true
2014-07-11 15:45:11 -07:00
---
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
{{< callout info > }}
**New markup in v5.3.0 —** We've deprecated the previous HTML structure for progress bars and replaced it with a more accessible one. The previous structure will continue to work until v6. [See what's changed in our migration guide. ]({{< docsref "/migration#improved-markup-for-progress-bars" >}} )
{{< / callout > }}
2016-12-29 14:56:28 -08:00
## How it works
2014-07-11 15:45:11 -07:00
2017-05-27 23:01:14 -07:00
Progress components are built with two HTML elements, some CSS to set the width, and a few attributes. We don't use [the HTML5 `<progress>` element ](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress ), ensuring you can stack progress bars, animate them, and place text labels over them.
2016-12-29 14:56:28 -08:00
- We use the `.progress` as a wrapper to indicate the max value of the progress bar.
2023-02-14 03:38:21 +01:00
- The `.progress` wrapper also requires a `role="progressbar"` and `aria` attributes to make it accessible, including an accessible name (using `aria-label` , `aria-labelledby` , or similar).
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
- We use the inner `.progress-bar` purely for the visual bar and label.
- The `.progress-bar` requires an inline style, utility class, or custom CSS to set its width.
- We provide a special `.progress-stacked` class to create multiple/stacked progress bars.
2016-12-29 14:56:28 -08:00
Put that all together, and you have the following examples.
2016-02-08 00:31:10 -08:00
2019-01-08 18:33:28 +02:00
{{< example > }}
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Basic example" aria-valuenow = "0" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar" style = "width: 0%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Basic example" aria-valuenow = "25" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar" style = "width: 25%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Basic example" aria-valuenow = "50" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar" style = "width: 50%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Basic example" aria-valuenow = "75" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar" style = "width: 75%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Basic example" aria-valuenow = "100" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar" style = "width: 100%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
2019-01-08 18:33:28 +02:00
{{< / example > }}
2016-02-07 13:13:06 -08:00
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
## Bar sizing
### Width
Bootstrap provides a handful of [utilities for setting width ]({{< docsref "/utilities/sizing" >}} ). Depending on your needs, these may help with quickly configuring the width of the `.progress-bar` .
2016-12-30 21:43:16 -08:00
2019-01-08 18:33:28 +02:00
{{< example > }}
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Basic example" aria-valuenow = "75" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar w-75" > < / div >
2016-12-30 21:43:16 -08:00
< / div >
2019-01-08 18:33:28 +02:00
{{< / example > }}
2016-12-30 21:43:16 -08:00
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
### Height
2016-02-07 13:13:06 -08:00
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
You only set a `height` value on the `.progress` container, so if you change that value, the inner `.progress-bar` will automatically resize accordingly.
2016-02-07 13:13:06 -08:00
2019-01-08 18:33:28 +02:00
{{< example > }}
2023-02-14 03:38:21 +01:00
< div class = "progress" role = "progressbar" aria-label = "Example 1px high" aria-valuenow = "25" aria-valuemin = "0" aria-valuemax = "100" style = "height: 1px" >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress-bar" style = "width: 25%" > < / div >
< / div >
< div class = "progress" role = "progressbar" aria-label = "Example 20px high" aria-valuenow = "25" aria-valuemin = "0" aria-valuemax = "100" style = "height: 20px" >
< div class = "progress-bar" style = "width: 25%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
2019-01-08 18:33:28 +02:00
{{< / example > }}
2014-07-11 15:45:11 -07:00
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
## Labels
2014-07-11 15:45:11 -07:00
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
Add labels to your progress bars by placing text within the `.progress-bar` .
2014-07-11 15:45:11 -07:00
2019-01-08 18:33:28 +02:00
{{< example > }}
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Example with label" aria-valuenow = "25" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar" style = "width: 25%" > 25%< / div >
2016-12-29 14:56:28 -08:00
< / div >
2019-01-08 18:33:28 +02:00
{{< / example > }}
2016-12-29 14:56:28 -08:00
2023-11-03 08:08:19 +01:00
### Long labels
2023-01-21 17:34:09 +00:00
2023-11-03 08:08:19 +01:00
Note that by default, the content inside the `.progress-bar` is controlled with `overflow: hidden` , so it doesn't bleed out of the bar. If your progress bar is shorter than its label, the content will be capped and may become unreadable. To change this behavior, you can use `.overflow-visible` from the [overflow utilities ]({{< docsref "/utilities/overflow" >}} ).
{{< callout warning > }}
**Accessibility warning:** Long labels may not be fully accessible with this method. As it relies on the text color having the right contrast ratio with both the `.progress` and `.progress-bar` background colors, your color palette could be incompatible with this approach.
If the text can overlap the progress bar, we often recommend displaying the label outside of the progress bar for better accessibility.
{{< / callout > }}
2023-01-21 17:34:09 +00:00
2017-05-27 23:01:14 -07:00
## Backgrounds
2016-12-29 14:56:28 -08:00
Use background utility classes to change the appearance of individual progress bars.
2019-01-08 18:33:28 +02:00
{{< example > }}
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Success example" aria-valuenow = "25" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar bg-success" style = "width: 25%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Info example" aria-valuenow = "50" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar bg-info" style = "width: 50%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Warning example" aria-valuenow = "75" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar bg-warning" style = "width: 75%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Danger example" aria-valuenow = "100" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar bg-danger" style = "width: 100%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
2019-01-08 18:33:28 +02:00
{{< / example > }}
2016-12-29 14:56:28 -08:00
2022-07-13 22:31:15 +01:00
{{< callout info > }}
2022-10-16 09:09:33 -07:00
{{< partial " callouts / warning-color-assistive-technologies . md " > }}
2022-07-13 22:31:15 +01:00
{{< / callout > }}
2023-11-03 08:08:19 +01:00
If you're adding labels to progress bars with a custom background color, make sure to also set an appropriate [text color ]({{< docsref "/utilities/colors#colors" >}} ), so the labels remain readable and have sufficient contrast. We recommend using the [color and background ]({{< docsref "/helpers/color-background" >}} ) helper classes.
2023-01-21 17:34:09 +00:00
{{< example > }}
< div class = "progress" role = "progressbar" aria-label = "Success example" aria-valuenow = "25" aria-valuemin = "0" aria-valuemax = "100" >
2023-11-03 08:08:19 +01:00
< div class = "progress-bar text-bg-success" style = "width: 25%" > 25%< / div >
2023-01-21 17:34:09 +00:00
< / div >
< div class = "progress" role = "progressbar" aria-label = "Info example" aria-valuenow = "50" aria-valuemin = "0" aria-valuemax = "100" >
2023-11-03 08:08:19 +01:00
< div class = "progress-bar text-bg-info" style = "width: 50%" > 50%< / div >
2023-01-21 17:34:09 +00:00
< / div >
< div class = "progress" role = "progressbar" aria-label = "Warning example" aria-valuenow = "75" aria-valuemin = "0" aria-valuemax = "100" >
2023-11-03 08:08:19 +01:00
< div class = "progress-bar text-bg-warning" style = "width: 75%" > 75%< / div >
2023-01-21 17:34:09 +00:00
< / div >
< div class = "progress" role = "progressbar" aria-label = "Danger example" aria-valuenow = "100" aria-valuemin = "0" aria-valuemax = "100" >
2023-11-03 08:08:19 +01:00
< div class = "progress-bar text-bg-danger" style = "width: 100%" > 100%< / div >
2023-01-21 17:34:09 +00:00
< / div >
{{< / example > }}
2017-05-27 23:01:14 -07:00
## Multiple bars
2016-12-29 14:56:28 -08:00
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
You can include multiple progress components inside a container with `.progress-stacked` to create a single stacked progress bar. Note that in this case, the styling to set the visual width of the progress bar *must* be applied to the `.progress` elements, rather than the `.progress-bar` s.
2016-12-29 14:56:28 -08:00
2019-01-08 18:33:28 +02:00
{{< example > }}
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress-stacked" >
< div class = "progress" role = "progressbar" aria-label = "Segment one" aria-valuenow = "15" aria-valuemin = "0" aria-valuemax = "100" style = "width: 15%" >
< div class = "progress-bar" > < / div >
< / div >
< div class = "progress" role = "progressbar" aria-label = "Segment two" aria-valuenow = "30" aria-valuemin = "0" aria-valuemax = "100" style = "width: 30%" >
< div class = "progress-bar bg-success" > < / div >
< / div >
< div class = "progress" role = "progressbar" aria-label = "Segment three" aria-valuenow = "20" aria-valuemin = "0" aria-valuemax = "100" style = "width: 20%" >
< div class = "progress-bar bg-info" > < / div >
< / div >
2016-12-29 14:56:28 -08:00
< / div >
2019-01-08 18:33:28 +02:00
{{< / example > }}
2014-07-11 15:45:11 -07:00
2017-05-27 23:01:14 -07:00
## Striped
2014-07-11 15:45:11 -07:00
2016-12-29 14:56:28 -08:00
Add `.progress-bar-striped` to any `.progress-bar` to apply a stripe via CSS gradient over the progress bar's background color.
2014-07-11 15:45:11 -07:00
2019-01-08 18:33:28 +02:00
{{< example > }}
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Default striped example" aria-valuenow = "10" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar progress-bar-striped" style = "width: 10%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Success striped example" aria-valuenow = "25" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar progress-bar-striped bg-success" style = "width: 25%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Info striped example" aria-valuenow = "50" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar progress-bar-striped bg-info" style = "width: 50%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Warning striped example" aria-valuenow = "75" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar progress-bar-striped bg-warning" style = "width: 75%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Danger striped example" aria-valuenow = "100" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar progress-bar-striped bg-danger" style = "width: 100%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
2019-01-08 18:33:28 +02:00
{{< / example > }}
2014-07-11 15:45:11 -07:00
2017-05-27 23:01:14 -07:00
## Animated stripes
2014-10-26 22:48:12 -07:00
2016-12-29 14:56:28 -08:00
The striped gradient can also be animated. Add `.progress-bar-animated` to `.progress-bar` to animate the stripes right to left via CSS3 animations.
2014-07-11 15:45:11 -07:00
2021-08-21 06:54:53 +03:00
{{< example > }}
Rework progress bar markup and styles (#36831)
* Rework progress bar markup and styles
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced.
For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s.
Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
* Add a note about progress bar change in migration guide
* Add notes with old markup examples and explanation
* Fix bundlewatch
* Update site/content/docs/5.2/components/progress.md
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
* Reintroduce deleted styles
Turns out they're needed for correct positioning of text inside progress bar
* Move changes in markup to Migrationg guide, link to that from top of progress page, rewrite some content
* Fix typo in callout
* Clarify "Sizing" section
* Remove redundant "now"
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Co-authored-by: Julien Déramond <juderamond@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
2022-11-29 07:07:48 +00:00
< div class = "progress" role = "progressbar" aria-label = "Animated striped example" aria-valuenow = "75" aria-valuemin = "0" aria-valuemax = "100" >
< div class = "progress-bar progress-bar-striped progress-bar-animated" style = "width: 75%" > < / div >
2016-12-29 14:56:28 -08:00
< / div >
2021-08-21 06:54:53 +03:00
{{< / example > }}
2021-02-10 19:29:59 -08:00
2022-03-18 09:02:03 -07:00
## CSS
2021-02-10 19:29:59 -08:00
### Variables
2022-03-18 09:02:03 -07:00
{{< added-in " 5 . 2 . 0 " > }}
As part of Bootstrap's evolving CSS variables approach, progress bars now use local CSS variables on `.progress` for enhanced real-time customization. Values for the CSS variables are set via Sass, so Sass customization is still supported, too.
{{< scss-docs name = "progress-css-vars" file = "scss/_progress.scss" > }}
### Sass variables
2021-02-10 19:29:59 -08:00
{{< scss-docs name = "progress-variables" file = "scss/_variables.scss" > }}
### Keyframes
Used for creating the CSS animations for `.progress-bar-animated` . Included in `scss/_progress-bar.scss` .
{{< scss-docs name = "progress-keyframes" file = "scss/_progress.scss" > }}