Ivan Bogachev

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

.category-desc {
    position: relative;
}

.page-header.item-title {
    position: absolute;
    bottom: 60px;
    left: 10px;
}

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

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

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

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

Они используют vuepress.

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

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

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

не важно каким образом ты что-то изучаешь, главное, что в итоге ты получишь знания

Кроме достижения цели есть еще такой фактор, как время. А время, как известно - деньги. Объемы и скорость потребления текстовой информации всегда выше, чем видео. Текст - это:

• Возможность бегло просматривать, на автомате фильтруя воду
  
• Возможность пользоваться поиском и гиперссылками
  
• Возможность копипастить
  
• Зачастую более полная информация
  
• Чем больше читаете, тем быстрее читаете, тем больше читаете, тем быстрее читаете....
  
• + В наших краях читать на английском большинству проще, чем слушать
  

Как вы читаете подобную литературу и как мне не умирать после каждой страницы?

Книги и статьи по разработке, маны и документации - это тексты, которые читать последовательно от корки до корки долго, скучно и неэффективно. Гораздо лучше быстро скользить взглядом, останавливаясь на важных моментах. А если объем большой - то сразу пролистывать все, а потом "спускаться на уровень ниже" за подробностями по тому или иному вопросу. Так книжка на 700-800 страниц может пролистываться за день, а затем при необходимости можно точечно просматривать темы, которые нужны на данный момент. Вести записи в тетрадях для запоминания также почти всегда неэффективно, лучше сразу практиковаться. Что нужно - само запомнится, а что не нужно - просто знайте где почитать, на случай если оно вдруг понадобится.

Попробовал набросать свой вариант без jQuery:

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

В обсуждении #19394 говорят, что эта проблема была исправлена в версии 5.7.0. Вероятно вам стоит немного обновить NPM.

Вот тут не должно быть пробелов между именами классов:

var services__slider = $(".services__wrap.owl-carousel");

какие паттерны применяются чаще всего на практике и где

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

1. Модули (делим код на независимые части)
   
2. Фабрики (для компонентов интерфейса)
   
3. Синглтоны (для хранилищ, точек сбора полифиллов / утилит и.т.д.)
   
4. Адаптеры (для зависимостей и полифилов, которые могут измениться / выпилиться)
   
5. Наблюдатели (для сбора происходящих событий в одном месте)
   
6. Хранители (для сохранения действий пользователя и "Ctrl-Z")
   
7. Стратегии (если действуем в зависимости от прилетевших данных)
   

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

Важно понимать, что паттерны проектирования - это просто хорошие идеи по поводу того, как организовать большой объем кода в той или иной ситуации. Это не "изучи тайное знание, запомни, и делай так всегда", не "используй паттерны, потому что великие их используют", это скорее "если не уверен как организовать код, возьми готовую идею, она вроде работает". Если вы будете просто решать задачи, то через N лет практики вы сами их все "изобретете", только не будете знать, что у них есть названия. Эффективно будет организовать себе заметку о том, какие из этих идей для чего примерно применяют, а потом, в процессе работы, в нее подглядывать, если встал вопрос "как организовать этот код".

Забудьте... дизайнер просто демон... посылайте нафиг дизайнера...

О да, люблю эти комментарии. Набросал тут небольшой прототип:


В браузерах особо не проверял, только Chrome и FF, но вроде в современных должно работать.

result.hasOwnProperty(i) не может быть false. Во всяком случае я не придумал подходящего "кейса".

Может быть и false, если какое-то свойство определено в прототипе:

class Test {
    constructor() {
        this.foo = 'foo';
    }
};

Test.prototype.bar = 'bar';

const test = new Test();

console.log('foo' in test); // true
console.log('bar' in test); // true
console.log(test.hasOwnProperty('foo')); // true
console.log(test.hasOwnProperty('bar')); // false

Обычно достаточно хранить конфиги из /etc, для этого можно этот самый git и взять (очень удобно добавить также etckeeper). Я бы еще отдельно в файлик коммитил вывод команды apt-mark showmanual, чтобы знать, какие пакеты ставились руками и в случае чего не вспоминать, что как называлось. Если вы не делаете что-то жутко специфическое, правя руками файлы по всей системе, то этого должно хватать. Снапшоты - это на крайний случай, если вы действительно хотите всю систему сохранять.

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