[progressbar] Use HTML5 <progress>

[darkdragon-001]

Please use HTML5 progress bar which is supported on any modern browser (mostly since 2012, see browser support).

Fixes #293

[facelessuser]

Can progress bars easily and consistently styled cross browser? I believe the issue before was styling support was very inconsistent. I guess we could always just provide basic HTML5 progress without some features if they don't work cross browser.

[darkdragon-001]

I just using basic HTML5 progress using the default styling. This should work for most users and makes sure that more modern styling coming with more modern browsers will be used as well. If someone needs more specific/consistent styling, customization is always possible.

[facelessuser]

I'll have to reevaluate what translates over to HTML5 progress bars and what does not. I'll have to look into this and make a decision.

[facelessuser]

@gir-bot remove S: triage
@gir-bot add T: feature, P: maybe

[facelessuser]

The requirement for the current extension is that you must be able to create a label and progressbar. This requirement will remain. Current styling ability of progress bars are still, even years after 2012, all over the place. For those who want to use the default style that is fine, but for those hate the inconsistent styling across browsers, this is a problem.

To allow something mostly like what we had before, I think moving forward, we may create an output format like this:

<label><span class="progress-label">Label</span><progress max="100" value="50.0"/></label>

Not sure where all the classes will go yet (do we attach increment classes to label or to progress?). Regardless of class details, this will give anyone using it control to mimic what they had before or just have a plain old HTML5 progress bar. If you omit the label, the label content will be empty.

[darkdragon-001]

The requirement for the current extension is that you must be able to create a label and progressbar. This requirement will remain. Current styling ability of progress bars are still, even years after 2012, all over the place. For those who want to use the default style that is fine, but for those hate the inconsistent styling across browsers, this is a problem.

For me default styling is good. Consistent styling is a CSS problem, not a markdown one.

<label><span class="progress-label">Label</span><progress max="100" value="50.0"/></label>

Looks good

Not sure where all the classes will go yet (do we attach increment classes to label or to progress?).

I don't even understand from your docs what increment classes are...

Regardless of class details, this will give anyone using it control to mimic what they had before or just have a plain old HTML5 progress bar. If you omit the label, the label content will be empty.

I often don't need labels, but having empty ones is fine for me as well.

[facelessuser]

This is accommodating a number of people. While you may not use some of the features, others might. You may like the default styling, but others may not. The documents illustrate the increment classes as well. What looks good is very subjective.

Regardless, if I completely switch to HTML5 progress bars, some expectations will be lost. To accomplish what used to be possible may be more difficult.

Anyways, I will need to work out something to bridge the gap. Right now the legacy option is more flexible from a styling perspective.

[facelessuser]

I will reiterate though that I still think we can implement HTML5 style, but the limitations will affect whether it becomes default, completely replace legacy or lives beside it, and how I write up the migration guide. So, that is why I care and will need to work through this.

[darkdragon-001]

I agree that an update should suit the need of all previous, current and future users. I can only talk for myself and as a result elaborate on my own needs.

Instead of the increment classes, one could use a linear gradient. Resetting all styling is also possible in many browsers. I found a good article on <progress /> styling.

[facelessuser]

I've read that article as well. The big take away is that basic styling is possible, even though it isn't consistent in approach across browsers, some things like animation just aren't possible currently, and since CSS behaves a little different cross browsers it is a bit trickier to style labels the same way as previously done in our documentation. None of these are deal breakers per se, but they are different. I just need to decide how I wish to handle it. It may simple mean HTLM5 progress bars will simply be different.

I do have this generally working locally, but settling on the exact output and how I want to treat things moving forward is the current blocker. As this is lower priority on my list, there is currently no rush to get this out quick, but I imagine I will get something official out at some point.

[ofek]

Did this ever get implemented?

[facelessuser]

@ofek This is an example of a situation that isn't technically broken, people can still use it even if it isn't using HTML5 progress bars. Also, this is not an extension that many people use, and so the priority to finish this up has been a bit low. The computer I had the preliminary work on died on me so I don't have that work right now, but I imagine it wouldn't be too difficult to code it up again.

So in short, this hasn't been implemented yet, just some investigative work.

[Kristinita]

This issue is still relevant in December 2023.

Thanks.

[facelessuser]

Yep, I am still aware. The issue has been marked a maybe as I have made no commitments to provide the ask. As I stated in my last post, this is not an "issue" and nothing is broken. There are some people that would prefer an HTML5 progress bar, for whatever reason, but progress bars have been and continue to be perfectly functional. The same styling and functionality that I use and expect, the last time I evaluated, cannot be achieved cross browser with HTML5 progress bar. I would have to lose something: titles and/or animations.

If anyone can demonstrate an HTML format, using HTML5 progress bars, that can be styled the same as shown in the documentation for progress bars and works cross browsers, that will go a long way in convincing me to move this from a maybe to a higher priority item.

[Kristinita]

Type: Reply 💬

Personally, I want Progressbar to not generate inline CSS because I can’t use the PostCSS plugin “postcss-combine-media-query” if HTML contains inline CSS.

Of course, this isn’t a Progressbar problem, but HTML parsers may not handle inline CSS correctly. As indicated by the links I have given in #293, inline CSS isn’t a best practice, and parser developers may not pay enough attention to it. No inline CSS — no problems 😁.

Thanks.

[facelessuser]

Any HTML parser that cannot handle inline CSS has an issue. There is nothing invalid about inline CSS. "Best practices" and "bad" are two different things. Some people may not like it, but there is nothing wrong with it. If a PostCSS parser can't be configured to not throw errors on inline CSS, I would argue it is an issue on their end. I do see you've open an issue over on their repo, and I think that is probably the best option for now.