I prefer inline styles to be blocked by my CSP; but that would also affect the display of the Turbo Progress Bar, as Turbo (per the demo still uses width: ${percentage}% to set the width of the progress bar.
This issue existed before in TurboLinks, but during the great wait I was lazily hoping that this would be resolved
Initially I thought the progress representation was data based, and hence wanted to suggest adding classes per 10ths of progress, e.g. .turbo-progress-bar--progress-0, .turbo-progress-bar--progress-10 … .turbo-progress-bar--progress-100, but the bar is faked it seems (?); adding random increases to the total value; hence why not use a pure class based progress bar:
.turbo-progress-bar { width 0; opacity 0; }
.turbo-progress-bar--in-progress { width: 50*; opacity: 1} // suggest this to be a css animation
.turbo-progress-bar--finalizing { width: 100%; opacity: 0 }
happy to see if I can make a PR for this, but would like to know if such would be appreciated.
Did you do some testing on why the random increase? Did that make it more convincing?
Alternative would of course be to simply show the progress bar in full and use CSS animation to add some loading-style animation; slowly fading in and out in continuous repeat until loaded; but I kinda like the (perhaps even faked) feedback of a progress bar growing
Hey @murb, so let me try to fully understand your problem. You don’t like inline styles and you think the bar should reflect real % done rather than just random values?
NOTE: this is just my own opinon, no idea why the core team decided to do it the way they did.
As for inline styles, I think these are inside of turbo (the javascript package) and not streaming them from the server, if you have linting (which I’m assuming CSP is?) I doubt it would be checking everything for that?
Assuming I understand, I think the % problem is misleading because a page could load to 10% really fast slow down to a crawl for 300ms and then jump to 98% and slow down again for a couple of seconds then be done. The internet/server/database combination can be crazy and random in its performance and so presenting it literally can lead to some emotional rollercoasters that aren’t really needed I think for most users. Most things come relatively fast, the bar is there just to help them be more patient and feel like something is happening (because it usually is). Thus random smooth values that never quite reach 100% till the request is finally done, makes a lot of sense.
Initially I thought it would reflect some kind of state that the browser reported, but on closer inspection it turned out not to be the case, and I’m ok with that. I’m just not happy with the use of inline styles, because, well:
I think the behaviour can be replicated without inline styling (with some additional classes), except for the randomness that is present in the current code.
