На самом деле это не важно. всё равно для примерной оценки мы используем текущий размер. можно при каждом отображении обновлять кэш.

Скроллбар показывает позицию вьюпорта относительно контента. Они не могут быть не связаны без деградации UX.

UX уже деградирован. потому что если вы хотите перейти на позицию например 20% но не знаете какая реальная высота коментов. Даже приблизительные размеры не знаете, для тех которые пользователь уже видел.

А то что этот индикатор скачет как бешанная лошадь, вот это как по мне проблема UX. То что отображает скроллбар и так и так будет очень приблизительная оценка. Может дойдут руки и я попробую реализовать. Интересно как будет работать.

Такого не происходит в самом начале. В середине списка скачет даже при медленной промотке. Причины мне не известны.

Скроллбар показывает позицию вьюпорта относительно контента. Они не могут быть не связаны без деградации UX.

Да уменьшение сверху это проблема. Наверное у нас нет нужного контроля за рендером чтобы обрезать сверху и при этом одновременно перейти на старое место. Т.е. чтобы не было заметно скачка. С другой стороны если просто идём сверху вниз медленно, то такого не происходит. Или я не правильно понимаю причины скачков?

Корректировки это правильно. просто надо чтобы корректировки позиции для рендера и для скроллбара не были связаны. Как я предложил выше. Что думаете?

Дальше будет критика, но меня просто заинтересовала задача, так что надеюсь конструктивная.

В вашей реализации самое странное это какие-то подергивания. Т.е. я делаю скролл вниз, браузер отрисовывает его ниже и потом он прыгает вверх и сразу вниз. Т.е. вот эти прыжки туда-сюда не понятно зачем нужны. По-идее, мы меняем высоту один раз за обработчик onscroll т.е. прыжок должен быть один. Как это происходит при бесконечной прокрутке например.

Во-вторых, не реализовано запоминание размеров. Т.е. при повторном скролле всё опять дергается.

Демка ngx-virtual-scroller работает плавнее, но возможно из-за того что там распределение рандомных размеров равномерное, а на хабре подругому.

Основная проблема это то что нельзя узнать какая высота изначально. Т.е. как только мы забираем новую пачку комментариев то у нас меняется наше предсказание о том сколько места ещё надо сверху или снизу. Соответственно соотношение место вверху к месту внизу меняется. Решить это можно так: скролл бар должен быть не линейный. Сам указатель скролла мы оставляем на месте, но теперь размеры выше от него и ниже от него умножаем на соответствующий коэффициент. Его учитываем при последующей прокрутке.

PS: К вопросу о «теоретиках» — я в своё время делал виртуализацию ленты документов (очень произвольного размера) на vanilla JS.

JustDont ну покажи решение того, что показывать не надо. Не стесняйся.

So to summarize what we know so far, the following teams at Mozilla have been either eliminated or gutted to oblivion:

* Firefox devtools
* Firefox incident/threat management team (?!)
* Servo
* MDN
* WebXR/Firefox Reality
* DevRel/Community (???)

I guess they're giving up?

— Kat Marchán (@zkat__) August 12, 2020