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 CreditAttribution: Niklas Fiekas commentedW3C, WHATWG spelling
Comment #1
kika CreditAttribution: kika commentedIs this issue here dupe of #1477550: Bring progressbar to the postmodern era ?
Comment #2
Niklas Fiekas CreditAttribution: 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 CreditAttribution: Bojhan commentedComment #4
jibranComment #4.0
jibranAdd alternative
Comment #5
catchComment #19
finnsky CreditAttribution: finnsky at Skilld commentedComment #21
finnsky CreditAttribution: finnsky at Skilld commentedComment #22
finnsky CreditAttribution: finnsky at Skilld commentedComment #23
finnsky CreditAttribution: finnsky at Skilld commentedComment #24
finnsky CreditAttribution: finnsky at Skilld 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 CreditAttribution: finnsky at Skilld 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 CreditAttribution: smustgrave at Mobomo 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 CreditAttribution: finnsky at Skilld commentedI don't think so. Probably it may be fixed or even ignored.
Comment #32
Keshav Patel CreditAttribution: Keshav Patel at OpenSense Labs for DrupalFit commentedComment #33
finnsky CreditAttribution: finnsky at Skilld 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.