WHATWG: http://www.whatwg.org/specs/web-apps/current-work/#the-progress-element
Currently it supported by all browsers and can be even styled. https://caniuse.com/progress
Current install Drupal pages for example:
Chrome

Safari

Small transition problem in FF(but seems not critical):

Main plus here is a11y
From:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/pr...
It is recommended to use a native
or elements rather than the progressbar role. User agents provide a stylize widget for the
element based on the current value as it relates to the 0, the minimum value, and the max value. When using non-semantic elements, all features of the native semantic element need to be recreated with ARIA attributes, JavaScript and CSS.
Better to use native elements always imo.
What left to do?
- Correct styles for Umami (it is possible to remove them completely from Umami. Because they look strange even before the patch)
- Figure out what to do with stable9 styles
- Figure out what to do with the starter kit.
| Comment | File | Size | Author |
|---|
Issue fork drupal-1484174
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #0.0
Niklas Fiekas commentedW3C, WHATWG spelling
Comment #1
kika commentedIs this issue here dupe of #1477550: Bring progressbar to the postmodern era ?
Comment #2
Niklas Fiekas commentedOh, it is. Thank you.
Just created the issue because that one wasn't in the overview. Added it there.
Comment #3
Bojhan commentedComment #4
jibranComment #4.0
jibranAdd alternative
Comment #5
catchComment #19
finnsky commentedComment #21
finnsky commentedComment #22
finnsky commentedComment #23
finnsky commentedComment #24
finnsky commentedComment #25
mgiffordWanted to flag this the accessibility concerns about properly labelling it:
I would say that using
<label>is better.More good examples here - https://scottaohara.github.io/a11y_styled_form_controls/src/progress-bar/
Comment #26
finnsky commentedRE #25
Thank you for review. Yes definitely we need label. Here i only prepared example that no visual regressions will be.
Comment #27
smustgrave commentedBut think original question, least how I understood, is that this is definitely a good replacement to have.
Comment #29
andypostThere's still little lag in current Firefox but is it really a blocker?
Comment #30
finnsky commentedI don't think so. Probably it may be fixed or even ignored.
Comment #32
keshav patel commentedComment #33
finnsky commented- I adjusted the styles for Olivero and Claro.
- Added a label for accessibility
What's left to do:
- Correct styles for Umami (it is possible to remove them completely from Umami. Because they look strange even before the patch)
- Figure out what to do with stable9 styles
- Figure out what to do with the starter kit.
Moving back to work
Would be cool if anyone could test it.
Comment #34
mgiffordWorth comparing with https://dequeuniversity.com/library/aria/progress-bar-bounded
Many uses of progress bars are essentially static, but Drupal we often use them as dynamic elements which should be updated with aria-live.
Deque uses:
They leverage the ARIA progressbar role. I"m not certain that this is needed, but wanted to note it here.
MDN just states:
What is in the latest patch I think is:
I'm not sure how much the JavaScript would affect things here either. I haven't compared the two.
Comment #35
andypostneeds rebase, looks still valid
Comment #37
tom kondaI rebased MR !5115.