Ivan Bogachev

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

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

.list {
    $b: &;

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

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

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

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

    &__link {
        // . . .
    }

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

А почему бы не использовать обычную feDropShadow?

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
  <defs>
    <filter id="shadow">
      <feDropShadow dx="0" dy="4" stdDeviation="2" flood-color="grey" />
    </filter>
  </defs>
  <polygon points="30.1,84.5 10.2,50 30.1,15.5 69.9,15.5 89.8,50 69.9,84.5"
           filter="url(#shadow)" fill="hsl(156,80%,50%)"></polygon>
</svg>

Блоки с классами man, woman и kid должны быть рядом с инпутами, в той же обертке. Вот так:

div
    input
    label
    input
    label
    .man
    .woman
    .kid

а не вот так:

div
    input
    label
    input
    label
.man
.woman
.kid

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

.filters {
    filter: grayscale(0.85) sepia(0%) brightness(1);
}

.links-item:hover .filters {
    filter: grayscale(0) sepia(40%) brightness(0.55);
}

Задача разделяется на две:
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, без него никак.

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

Да, симпатичная штука. Как говорится, ябзаверстал. Да и показаться на первой странице CodePen с такой демкой тоже будет не лишним. Так что вот вам концепт для изучения по мотивам вашего видео:

В разных браузерах не тестировал, это скорее пример, чтобы показать подход к решению задачи. Рекомендую смотреть на большом экране - версия только для десктопа.

1. Расположить элементы так, как на картинке, проще всего заданием width, float и clear для них. И это логично, флоаты как раз предназначены для всевозможных обтеканий.
2. Чтобы отступы между картинкой и текстом не скакали, была ровная сеточка, а строки в разных блоках совпадали по вертикали, имеет смысл жестко привязать ее (картинки) высоту к EM/REM. Вообще удобно все к этим единицам привязывать, но это уже другая история.
3. Исходя из пункта 2, нужно добавить media-выражения для картинки на разные размеры экрана. Да, это лишняя работа. Да, это не чик-чик и в продакшен, но если важны мелочи в дизайне - делаем.
4. На маленьких экранах все это будет плохо восприниматься, так что выстраиваем элементы в столбик. Ширина в 100% всему. По уму контент важнее, чем aside, так что меняем их порядок с помощью свойств flex, flex-direction и order.

Получится что-то такое:

В теории:

В процессе работы анимации со свойством background-position постоянно происходит полный цикл всего, что только может происходить при отображении страницы:



Иными словами нагрузка есть, да.

На практике:

На среднем железе один такой цикл занимает меньше 1ms. Это не много. Это не то, что будет создавать "ощущение тормозов" у пользователя. Если поделить 1000ms на 60fps, то получится где-то ~16.5ms на кадр. Соответственно, если бы анимация занимала к примеру 30ms, то мы бы глазами видели лаг. Если анимация занимает ~10-12ms, то у устройства еще остаются ресурсы на работу остальных скриптов, общение с сервером и.т.д. и мы видим шустро работающую страницу. А в вашем случае она занимает меньше 1ms, так что нет каких-то весомых причин отказываться от нее. Не занимайтесь преждевременной оптимизацией.

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