Ivan Bogachev

Смущает класс ".list__link"

Если вас смущает повторение list в названии класса, то можно воспользоваться сохранением имени в стиле that=this из javascript:

.list {
    $b: &;

    &__item {
        &:first-child {
            #{$b}__link {
                // . . .
            }
        }
    }
}

Но это сложно назвать более читаемым вариантом.

Если цель - все же сделать код более удобоваримым, то может иметь смысл просто ограничить вложенность при написании стилей (именно визуальную вложенность кода, а не каскад), как это делают в том же rscss:

.list {
    &__item {
        // . . .
    }

    &__link {
        // . . .
    }

    &__item:first-child &__link {
        // . . .
    }
}

Вариантов может быть много. Один из них - большой-большой border-radius:

Задача разделяется на две:
1. Анимировать саму линию
2. Перемещать огонь по ней

Под первую задачу так и напрашивается SVG (статья про пунктирные вау-эффекты). Ну а решение второй вытекает из первой, достаточно загуглить "перемещение объекта по path" или еще что-то в этом духе. Получаем что-то такое (код немного странен, я другой пример перевернул вверх дном, но идея должна быть понятна):


Остается только приделать монитор нарисовать огонь, но это уже другой вопрос.

Что такое 1em? Это текущий размер шрифта. Когда вы задаете размер шрифта в единицах em, браузер считает этот размер относительно родительского размера шрифта. Но у html вы задаете font-size равный 0px. В данном случае это означает, что у всех потомков 1em будет равен нулю до тех пор, пока вы не зададите какое-то другое значение не в em/rem, тогда у потомков того элемента 1em будет равен заданному значению.

P.S.: Задавать font-size равный нулю для html - это не лучшая идея, она может приводить к самым разным багам, а также проблемам, когда у пользователей в браузере настроены ограничения на размер шрифта для html.

С первого взгляда видно:

1. Font-size в 1px для HTML, а потом все в REM? - интересное начало...
2. CSS-методология? - отсутствует.
3. Препроцессор для облегчения жизни? - отсутствует.
4. Все в одном файле? - да, так и есть.
5. Магические числа в CSS? - много.
6. Префиксы прямо в коде? - ага.
7. 21 брейкпоинт для такой простой страницы? - ежик...
8. Шрифты? - Fira отвалилась. Letter-spacing скачет.
9. Critical CSS? - отсутствует.
10. Бесполезные условные комментарии для IE6, гриды и флексы в одном флаконе? - о дааа.
11. HTML lang='ru' и контент на английском? - почему бы и нет.
12. Грузить весь FontAwesome ради пары иконок? - классика.
13. Асинхронная загрузка картинок? - отсутствует.

Продолжать можно долго. Рекомендации можно дать следующие:

1. Освойтесь с инструментами верстальщика. Откройте для себя препроцессоры и автопрефиксер. Почитайте про БЭМ. Используйте.
2. Добейтесь такого, чтобы вы понимали абсолютно все в своей верстке. Что? Зачем? Почему именно так? Избегайте копипасты. Не используйте какие-то "фишки" только потому, что кто-то их где-то поиспользовал - вполне вероятно, что там был другой контекст, а в вашей ситуации получится что-то странное. Разбирайтесь со всем.
3. Изучайте хорошие практики.
4. Ну и JS, без него никак.

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

Большая часть ресурсов - ситуативные (в основном это документации к конкретным библиотекам). Из более-менее часто используемого могу вспомнить:
MDN, DevDocs и Schema.org, чтобы вспоминать забытое.
Can I use, чтобы смотреть поддержку браузерами (+ doiuse).
WAVE и regex101, чтобы проверять себя.
В Browserhacks иногда полезно заглянуть.
FontPair и Coolors - если нужно без дизайнера подобрать шрифты и цвета.
Snazzy Maps, чтобы брать готовые цветовые схемы для карт.
Cubic-bezier, чтобы наглядно делать кривые для простых анимаций.
Google - если затупил.
Noisli - для фонового шума.
Cross Browser Testing, чтобы тестировать результат.

Как вы прокачивались?

Много-много экспериментов с целью не "научиться решать типовые задачи", а скорее "поиграть с инструментами и посмотреть, что будет". Такой подход дает более полную картину происходящего. Ну и гугл/документации/статьи по мере необходимости.

На что стоит сделать упор в обучении именно верстки и малого количества js-а?

Методы зависят от наличия времени и изначального уровня обучаемых. В целом для развития понимания CSS полезно "рисовать" на нем. Грубо говоря один автопортрет или зверушка, сделанная самостоятельно от начала и до конца, даст опыта как десяток лендингов. В таких песочницах концентрация хитрых задач на верстку в разы выше, чем на обычных сайтах, и обучение идет быстрее. Ну и просто прикольные штуки получаются, можно внести элементы игры с плюшками за успехи. В последние годы эта тема стала очень популярной на CodePen в виде ежедневных разминок для ума.

Как обучали людей? У меня нет опыта в обучении людей

По поводу методологий и хороших практик - нужно объяснять, отвечая в первую очередь на вопрос "почему". Тупое давление авторитетом (я прав - вы нет, мое решение хорошее - ваше нет) ни к чему не приведет. С вопросом "как" - отправлять к документации, чтобы читали сами и заодно захватывали что-то еще по дороге. Если все разжевывать - не научатся работать самостоятельно. Полезно научить их задавать вопросы. Если видите, что совсем не получается - тогда уже можно подсказать и показать. По возможности нужно автоматизировать проверку действий стажеров, чтобы они сразу видели свои косяки, не дожидаясь, пока придет наставник. Я тут как раз на днях подборку полезностей делал, там и для этого есть инструменты.

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

Вариантов много. По-хорошему, если вы пишете много простых компонетнов руками на чистом JS, то очень имеет смысл организовать систему классов для них. Один компонент - один класс. Организовать их можно по-разному (мне вот такая структура нравится). Для вашего примера можно начать с простого:

class MySlider {
    constructor(element, options) {
        const manager = new Hammer.Manager(element);
        
        manager.add(new Hammer.Pan({ threshold: 0, pointers: 0 }));
        manager.on('pan', (e) => {
            const percentage = 100 / options.numberOfSlides * e.deltaX / window.innerWidth;
            
            element.style.transform = `translateX(${percentage}%)`;
        });
    }
}

[].forEach.call(document.querySelectorAll('.slider-wrapper'), (element) => {
    const slider = new MySlider(element, { numberOfSlides: 2 });
});

Затем, чтобы собрать все в одном месте, упростить отладку и избавиться от повторяющегося кода, имеет смысл организовать мини-фабрику по производству компонентов. Что-то вроде такого. Таким образом вы не только решите свою задачу, но и упростите жизнь себе и тем, кто будет ваш код потом поддерживать.

span {
    background: linear-gradient(to bottom,
        transparent 0%,
        transparent 50%,
        #ff0 50%,
        #ff0 100%);
}

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

• Есть несколько секций с overflow: hidden
  
• Иконки дублируются в каждой секции, но с разными цветами
  
• В процессе скролла двигаем иконки, чтобы они оказывались на одном и том же месте относительно экрана
  

Прототип для изучения:

Вариант сделать это на position: fixed - не вариант, т.к. в сочетании с overflow: hidden может происходить неведомая магия.

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

Каких-то конкретных преимуществ этого подхода по сравнению с одним кадром на все я не вижу. Использовать ли для этого WebGL? Ну можно. Точно также, как и обычный canvas. Как выводить картинки на него вы легко загуглите, остается только посчитать координаты расположения кадров в картинке (по идее дизайнер должен их там аккуратно по сеточке расставлять) и выводить их по очереди.

P.S.: По идее можно отрендерить видео и вместо ручного переключения кадров проматывать его в разные стороны с разной скоростью в зависимости от скролла. Но на практике что-то не видно, чтобы это массово делали, обычно используют именно отдельные кадры.

Как найти именно эту карту я не знаю, но вы можете взять стандартные карты от гугла и их стилизовать. Это не сложно и можно отталкиваться от готовых примеров - например вот похожий вариант.

Похоже, что единственный работающий вариант реализовать такой градиент на CSS - это играться со свойством mix-blend-mode и делать фолбек для старых браузеров. Что-то вроде этого:

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