Ivan Bogachev

Потому, что for...in перебирает не совсем то, что вы ожидаете. В вашем случае будет удобнее использовать какой-нибудь другой вариант цикла - тот же for...of к примеру.

Попробуйте дождаться события loadedmetadata у видео, возможно они просто не успевают подгрузиться к моменту исполнения скрипта.

Стали бы вы им пользоваться? Если нет, то почему? Перспективно ли это направление вообще и перспективно ли конкретно это приложение?

Минификация кода должна производиться автоматически в процессе сборки. В 2019 году никто уже не ходит куда-то и не делает это вручную. Есть gulp, webpack, parcel и.т.д. - целая куча инструментов, которые могут по ходу дела минифицировать все, что через них проходит. Нужно лишь сказать им - минифицируй! В наше время все, что можно автоматизировать, люди стараются автоматизировать, а ваш сервис - это шаг назад на этом пути.

Подобные штуки строятся на анимации transform: scale(...), ну а вариантов с разной длительностью и количеством кругов можно придумать много, тут уж на вкус и цвет...

Мозг каждый день кипит так же, как в первый день. Шаг влево шаг вправо, и вот, я уже ничего не знаю и ничего не умею... ощущение, что на работе я как будто не прогрессирую, а наоборот деградирую...

У меня такое было, когда я только перешел во фронтенд и пытался держать слишком много деталей о языках и инструментах в голове. Со временем понял, что это не имеет смысла - все меняется быстрее, чем я запоминаю. Перешел от мысли "я использую инструменты" к мысли "я делаю штуки" и сразу полегчало, стал держать в голове только общие идеи о том, как что-то делается, или что вообще бывает в какой-то области, а конкретные инструкции по применению отдельных инструментов изучаю по ходу дела. Изменил фокус своего самообразования, если это можно так назвать. В результате все препроцессоры слились в один, новые библиотеки становятся все менее сложными в освоении, поскольку идеи везде плюс-минус одинаковые и.т.д. Решения стало принимать гораздо проще. И аргументировать тоже. Иногда складывается такое впечатление, что у нас в отрасли совсем ничего не появляется нового уже лет пять, а то и больше. Да, я забываю как использовать флексы, путаю call() и apply(), гуглю свои же ответы на тостере, но это не важно. Голова занята решением проблем, в ней теперь нет никакой второстепенной информации и это очень здорово. Статьи писать тоже полезно оказалось - написал, "поставил на полочку", и забыл. А если будет нужно - можно достать и посмотреть. Таким образом вот эта вся фигня с закипанием мозгов практически ушла.

Вы много раз используете такие штуки, как use и clip-path, указывая там id елементов. Но сами id на странице не уникальны. Вот и ломается все. Используйте уникальные id для элементов.

Это один из багов отображения SVG-картинок во flex-контейнерах. Это вообще больная тема, там эти картинки то схлопываются по ширине, то получают странные отступы в отдельных браузерах. Можно решить, обернув картинку в div с явным указанием display=block для него:

<div class="test">
    <img src="https://123.svg"/>
</div>

.test {
    display: block;
}

Есть такая штука, как gulp-tap, с ее помощью можно решить вашу задачу.

А в целом - содержимое файлов можно получать вне зависимости от сборщиков и таск-раннеров с помощью fs.readFile или fs.readFileSync (пример).

Обычно в таких дизайнах просто много абсолютного позиционирования. Классическая N-колоночная сетка может использоваться в отдельных блоках, а может и не использоваться - по вкусу верстальщика. Сами дизайнеры часто используют не деление на колонки, а "художественную" сетку с диагоналями (пример можно загуглить по запросу golden canon grid). Специального названия у всего этого вроде как нет, лично мне кажется уместным называть это "журнальной" версткой (так многие модные оффлайновые журналы рисуют).

Верстать такое не сложно, важно просто аккуратно определять откуда считать позицию того или иного элемента (к чему он логически привязан в дизайне). Адаптируется медиа-запросами, как и любая другая верстка. Иногда бывают сложности, если дизайнер намалевал что-то под большой размер экрана и не удосужился написать, как все уместить на маленьком - но это решается или обсуждением с ним или влоб все в столбик перестраивается, если мобильная версия не так важна. Обычно подобная верстка уместна в рекламных сайтах, которые больше рассчитаны на привлечение внимания и оказание впечатления на посетителя. Часто все это снабжается большим количеством анимаций и плавными переходами между страницами.

В черновиках Selectors Level 4 есть мысль о псевдоклассе :has, который мог бы дать возможность проверять такие связи и писать что-то вроде

.tab-position:has(> .pinned) {
    /* . . . */
}

но на сегодняшний день ни один браузер это не поддерживает. Так что нет, такой селектор в CSS сделать пока нельзя.

если увеличить размер шрифта, то и отступы увеличатся

Так это же замечательно, так и должно быть. И вопрос не только в доступности. Задание всех размеров в rem/em позволяет при изменении размера шрифта сохранить приятный глазу дизайн, у которого не "перекашивается" соотношение веса элементов и негативного пространства. Максимальный эффект достигается при использовании CSS-шлюзов и адаптивной типографики, что дает возможность без лишних движений сделать "красиво" на любых размерах экрана. А если заранее определить с дизайнером все стандартные размеры для всего (я часто использую .3, .5, .8, 1, 1.25, 1.5, 1.75, 2, 3, 4, 5 rem), то можно будет быстро верстать "на глаз", по бумажным наброскам, и даже без дизайнера совсем, используя не гору магических чисел, а известный набор удобных размеров. Конечно, это ломает мозги неподготовленному дизайнеру, но многие модные ресурсы (тот же Smashing Magazine) используют подобный подход весьма успешно.

По поводу задач не знаю, а про интересное и для людей - советую почитать Занимательную физику Перельмана.

с помощью css