Also, I'm confused about some points. For example, is progress meter really necessary? I mean, isn't the scrollbar a good indicator for the progress?
Progress meter is also at 0% when you're not scrolling, so unless you scroll, you don't know how much text there is to read.
(btw, just checked for Firefox and Safari, and the scrollbar is visible at all times, unless the website explicitly hides it)
There is a setting for this called "Always show scrollbars" and I know it defaults to off for me. The underlying about:config rule is specific to GTK though, so this may be platform-specific.
But also I don't really get how people are fine with hiding the scrollbar, but prefering to see the progress meter always visible for text, when the scrollbar conveys mostly the same information (except some edge cases when the footer is long I guess).
Not that it's important at all, I'm just at loss and it's not the first time I'm getting a signal that sometimes I simply don't understand people. But of course that's fine.
On macOS, at least, this is a setting so you can make them visible or invisible according to your taste. Probably not available on phones, though.
I'm personally a huge fan of the progress meter (having once thought it was redundant as well) - one other easy addition I didn't see mentioned is an "estimated reading time." Having a ballpark range for how long I should expect to spend with a piece of content greatly increases my chance of engaging with it, and the progress meter creates a tangible representation of that time (and how much of it I have left to finish consuming the content).
As for "progress meter" being an optimization of websites with large footers or long lists of comments, I'd argue that a better optimization technique would be to remove the footer, or remove/hide by default list of comments (i.e. make it available with a mouse click somewhere).
Do you mean for non-native speakers reading English material or for material in other languages when read by native speakers with an average reading competence in their native language?
Anyhow, as a non-native English speaker, it implemented it on my site by showing both the word count, as well as an estimated time, which is simply calculated by dividing the word count by a constant number of assumed words per minute.
That number was guesstimated by doing some reading speed tests on myself and researching average reading speeds and rounding up to 10 wpm. I have to admit that my assumption of 240 words per minute does not hold up to any scientific scrutiny, but otoh it is an estimation.
It works ok for prose. As soon as other notation is mixed in (code, math, graphs, diagrams etc.pp) that begins to naturally to vary wildly in accuracy.
Do you mean people whose native language is not English? I assume it works the same way as for everyone else, i.e. it's always an approximation anyway. I'm not from an English-speaking country, but I'm pretty sure I read faster than the average English native.
The other interpretation is that you mean people who can't read English at all, but in this case I understand even less. They won't be able to read the article, if they don't speak the language. After automated translation, the reading time should be roughly correct again.
so i’ll agree that progress indicators are helpful for this use case.
I think the better solution in this case is to use the (relatively) new html tags: <details><summary>Comments</summary></details>
Demo:
https://try.scroll.pub/#scroll%0A%20%0A%20expander%20Comment...