0
0
mirror of https://github.com/twbs/bootstrap.git synced 2024-12-12 00:08:59 +01:00
Bootstrap/site/content/docs/5.3/components/progress.md

203 lines
10 KiB
Markdown
Raw Normal View History

2014-07-12 00:45:11 +02:00
---
layout: docs
2014-07-12 00:45:11 +02:00
title: Progress
2017-05-28 08:01:14 +02:00
description: Documentation and examples for using Bootstrap custom progress bars featuring support for stacked bars, animated backgrounds, and text labels.
group: components
2017-05-28 08:01:14 +02:00
toc: true
2014-07-12 00:45:11 +02: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 08:07:48 +01: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 >}}
## How it works
2014-07-12 00:45:11 +02:00
2017-05-28 08:01:14 +02: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.
- We use the `.progress` as a wrapper to indicate the max value of the progress bar.
- 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 08:07:48 +01: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.
Put that all together, and you have the following examples.
{{< 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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</div>
{{< /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 08:07:48 +01: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-31 06:43:16 +01: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 08:07:48 +01: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-31 06:43:16 +01:00
</div>
{{< /example >}}
2016-12-31 06:43:16 +01: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 08:07:48 +01:00
### Height
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 08:07:48 +01: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.
{{< example >}}
<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 08:07:48 +01: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>
</div>
{{< /example >}}
2014-07-12 00:45:11 +02: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 08:07:48 +01:00
## Labels
2014-07-12 00:45:11 +02: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 08:07:48 +01:00
Add labels to your progress bars by placing text within the `.progress-bar`.
2014-07-12 00:45:11 +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 08:07:48 +01: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>
</div>
{{< /example >}}
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" >}}), but make sure to also define an explicit [text color]({{< docsref "/utilities/colors#colors" >}}) so the text remains readable. Be aware though that currently this approach does not take into account [color modes]({{< docsref "/customize/color-modes" >}}).
{{< example >}}
<div class="progress" role="progressbar" aria-label="Example with label" aria-valuenow="10" aria-valuemin="0" aria-valuemax="100">
<div class="progress-bar overflow-visible text-dark" style="width: 10%">Long label text for the progress bar, set to a dark color</div>
</div>
{{< /example >}}
2017-05-28 08:01:14 +02:00
## Backgrounds
Use background utility classes to change the appearance of individual progress bars.
{{< 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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</div>
{{< /example >}}
{{< callout info >}}
{{< partial "callouts/warning-color-assistive-technologies.md" >}}
{{< /callout >}}
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.
{{< example >}}
<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%">25%</div>
</div>
<div class="progress" role="progressbar" aria-label="Info example" aria-valuenow="50" aria-valuemin="0" aria-valuemax="100">
<div class="progress-bar bg-info text-dark" style="width: 50%">50%</div>
</div>
<div class="progress" role="progressbar" aria-label="Warning example" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100">
<div class="progress-bar bg-warning text-dark" style="width: 75%">75%</div>
</div>
<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%">100%</div>
</div>
{{< /example >}}
Alternatively, you can use the new combined [color and background]({{< docsref "/helpers/color-background" >}}) helper classes.
{{< example >}}
<div class="progress" role="progressbar" aria-label="Warning example" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100">
<div class="progress-bar text-bg-warning" style="width: 75%">75%</div>
</div>
{{< /example >}}
2017-05-28 08:01:14 +02:00
## Multiple bars
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 08:07:48 +01: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.
{{< 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 08:07:48 +01: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>
</div>
{{< /example >}}
2014-07-12 00:45:11 +02:00
2017-05-28 08:01:14 +02:00
## Striped
2014-07-12 00:45:11 +02: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-12 00:45:11 +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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</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 08:07:48 +01: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>
</div>
{{< /example >}}
2014-07-12 00:45:11 +02:00
2017-05-28 08:01:14 +02:00
## Animated stripes
2014-10-27 06:48:12 +01: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-12 00:45:11 +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 08:07:48 +01: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>
</div>
{{< /example >}}
## CSS
### Variables
{{< 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
{{< 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" >}}