<pf-progress> html, <progress>, or <meter> elements

[brianferry]

In discussing the implementation of <pf-progress> as a 1:1 of PatternFly Progress the question has come up on which element we would prefer to implement in this element in PFE.

Some background:

PatternFly uses HTML in order to display their progress bars. Their description for a <PfProgress>

The structure roughly looks like:

<div class="progress">
    <div class="description">Title</div>
    <div class="status">33%</div>
    <div class="progress-bar">
        <div class="indicator" style="width:33%">
            <span class="measure></span>
        </div>
    </div>
</div>

However, because we can implement our elements in the Shadow DOM we have the ability to use HTML5 elements, two candidates being <progress> and <meter>. Though they serve similar purposes, there are subtle differences between the two and their visual representation and the information they mean to convey.

<progress>

MDN docs state "The HTML element displays an indicator showing the completion progress of a task, typically displayed as a progress bar."

<meter>

MDN docs state "The HTML element represents either a scalar value within a known range or a fractional value."

The difference can be understood as <progress> is the difference between how far you are along completing a task or downloading a file whereas <meter> would be for example your fuel level, distance needed to travel, or temperature for the oven to be set to.

The APIs of these two elements are also different, <progress> takes a max and value property but does not contain a min property. <meter> includes a min, max, high, low, and value property.

Implementation wise <meter> is easier to work with and is more flexible with CSS and more API options, however both can look pretty close to their HTML implementations through some browser-specific CSS tags. Here is a link to the current Deploy Preview where we can see some of the styling between the elements.

Personally, I feel compelled to lean towards <pf-progress> using the <progress> element as the Patternfly Progress React Component description states "A progress bar informs users about the completion status of an ongoing process or task." which seems more in line with the <progress> HTML5 element but looking for discussion on how we feel about this / possible causes for concern here.

We might also want to ask ourselves do we see a use for creating a distinct <pf-meter> component or if users would necessarily want a different component for that and / or if we want it in RHDS as well.

Also looking for guidance on accessibility implications for one or the other by @nikkimk @hellogreg. I feel like using the semantic elements will be better for accessibility but I am not 100% sure.

[bennypowers]

Keep in mind that if we remove the shadow element from the ax tree and reflect the semantic state to the host with ElementInternals, we can use either of the the solutions no problem. We can also fall back to progress in DSD scenarios

[zeroedin]

🤯 I really need to burn that idea in. Really does make the ElementInternals sort of magical in that respect.

[bennypowers]

This pattern is called <fancy-input> or semantic delegation

The host element has a shadow root with a single sematic element in it, which the host element is meant to transparently represent

@alice' semantic delegate proposal would simplify implementing this pattern

https://github.com/alice/aom/blob/gh-pages/semantic-delegate.md

Progress is a neat case of a non-interactive version of this pattern

[hellogreg]

Also looking for guidance on accessibility implications for one or the other by @nikkimk @hellogreg. I feel like using the semantic elements will be better for accessibility but I am not 100% sure.

Yeah, I lean this way, too. I frame <progress> for verbs (filling the tank) and <meter> for nouns (fuel in the tank). The HTML spec does, as well: