Вертикальный прогресс-бар, направление прогресса

[cupoma58]

Есть рабочий видео-плеер, для сайта, с вертикальными прогрессом воспроизведения и звука:

progresBar.addEventListener('click', (e) => { 
    var mouseY = e.offsetY;
    progres.style.height = (mouseY * 100) / progresBar.offsetHeight  + '%';    
    video.currentTime = (video.duration * mouseY) / progresBar.offsetHeight;  
});

Прогресс-бар заполняется сверху-вниз, через CSS(flex:start). Я хочу изменить направление заполнения - на - снизу-вверх. Через CSS(flex:end) - не получается - время воспроизведения растёт, так-же - сверху-вниз(Y). Выбор более позднего эпизода - наталкивается на уменьшение общего времени. Браузер не понимает - что, от него, хотят.
Что посоветуете?

[dmitry]

Это вопрос сильно зависит от контекста разметки и существующих стилей. Чтобы мочь ответить надо видеть саму разметку и стили. Смена направления должна быть несложной задачей.

Для нахождения решения было бы идеально дать страницу на которой можно “поиграться” с плеером. Второй по лучшести вариант - это отдельная страница на которой изолирована разметка и стили относящиеся к прогрессу.

Без вышеописанных данных что-то посоветовать и угадать сложно.

[cupoma58]

Плеер сделан под Windows, для браузера с поддержкой showOpenFilePicker но, можно - подключить, файл, вручную:
3686 byt

[dmitry]

@cupoma58

Я хочу изменить направление заполнения - на - снизу-вверх

Для этого надо для класса .progres-bar поменять align-items на align-items: flex-end;

Вот так выглядит результат:

Однако теперь у тебя есть следующая проблема. На клипе возможно будет понятно, но код плеера написан так что он ожидает что прогресс бар будет заполняться сверху вниз. Поэтому клик по прогресс бару после смены направления через стили не будет давать желаемого результата в перемотке видео.

Вот тут код который отвечает за перемотку. Надо подумать-разобраться как переделать логику перемотки в свете нового направления прогресс бара

pb.addEventListener('click', (e) => { 
    var mouseY = e.offsetY;
    pg.style.height = (mouseY * 100) / pb.offsetHeight  + '%';    
    vp.currentTime = (vp.duration * mouseY) / pb.offsetHeight;  
});

UPD и нужно будет менять логику расчета времени в тултипе при наведении на прогресс бар

[cupoma58]

@dmitry

Для этого надо для класса .progres-bar поменять align-items на align-items: flex-end;

Я пробовал - это не решение.

@dmitry

как переделать логику перемотки в свете нового направления прогресс бара

За этим, я сюда и обратился. Я не вижу решения - для JS рост, по оси Y, идёт сверху-вниз.

[dmitry]

@cupoma58

Я пробовал - это не решение.

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

@cupoma58

За этим, я сюда и обратился.

Я перечитал вопрос. В нем неочевидно что вопрос в том как организовать перемотку или верный рассчет отметки времени ролика исходя из позиции мыши над прогресс баром.

Я понял вопрос как про изменение направления роста прогресс бара, на него и ответил. В вопросе нет упоминания ни про перемотку ни про тултип появляющийся при наведении на прогресс бар.

Давай сделаем шаг назад и сформулируем что мы вообще решаем.

[cupoma58]

Благодарю за участие. Оказалось, что ответ лежал - на поверхности

display: flex;
flex: start;    
-webkit-transform: rotate(180deg);

На javascript.ru/forum/ подсказали.
Добавлю ссылку, на ваш сайт, на свою страничку.

[dmitry]

Прикольно. Действительно проще чем переделывать математику.

Спасибо за ссылку.

UPD я посмотрел детальнее почему эта строка дает желаемый результат. Оказывает css-transform трансформирует элемент вместе с системой координат. Забавный факт - трансформации “накапливаются” - если прокрутить родителя прокрученного элемента (нерелевантно для твоего случая, даю как пример), то это второе вращение так же повлияет на расчет координат.

Это новый аспект понимания которого у меня не было.

Имея на страницу два узла, прокрученный и непрокрученный, они будут иметь внешне отличную систему координат - в одном случае Y будет расти снизу вверх, в другом сверху вниз.

Для случая когда есть рабочая математика в самодельном плеере над коодинатами элемента, и надо инвертировать направление, решение может подойти. Но для случая когда над кодом будут работать и итерировать куча программистов, то думаю однородность систем координат важнее чем простота решения задачи в моменте. Однородность системы координат упростит рассуждение о коде и решении. Значит тогда лучше выбирать путь смены математики вместе со сменой направления движения.

Кому какой варианты выбирать - на его усмотрение. Главное это осознавать последствия выбора.