Ivan Bogachev

До того, как IE/Edge стал хромиумным, он не умел работать с clip-path. Соответственно clip-path был "модным решением не для серьезного продакшена". Сейчас стало получше, но привычки так быстро не уходят. Да и не все компании поддерживают исключительно вечнозеленые браузеры. Есть отдельные инертные ниши, в которых пользователи не обновляются так быстро, как хотелось бы веб-евангелистам. В данном контексте SVG - это надежность.

Свойство display- не анимируемое. С ним ничего не сделать. Можно плавно менять opacity от 1 до 0 и добавлять pointer-events: none, чтобы элементы уходили из под мыши и с ними нельзя было взаимодействовать. Ну и, раз у вас скрипты используются для этого - в конце анимации, когда уже элементы не видны, можно добавить display: none, если на это свойство что-то еще завязано. При появлении - все в обратную сторону - pointer-events: auto и возвращаем opacity.

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

SVG-маски - наше все. Хотя в этом случае вариант с clip-path тоже очень даже рабочий. Еще есть вариант маски на шейдерах, но это совсем особый случай, хотя может внезапно оказаться очень производительным.

Каша происходит и в Firefox тоже. Нет Safari, чтобы проверить, но в Firefox все решается заменой .h-screen на .min-h-screen для полноэкранных секций.

В translate3d третий параметр (по оси Z) не может быть задан в процентах. Это и логично - у DOM-элемента нет толщины, от которой считать проценты. Первые два (по осям X и Y) - можно задавать в процентах, с этим проблем нет.

Но я как-то уже делал такое не прибегая к псевдо. Забыл(((

Как вариант можно линейными градиентами все нарисовать, с помощью border-image:

.menu-item {
    border-image: linear-gradient(to bottom, transparent 0%, #fff 50%, transparent 100%) 1;
    border-width: 0 0 0 1px;
    border-style: solid;
}

.menu-item:last-child {
    border-width: 0 1px 0 1px;
}

В общем случае можно градиентами на фоне вообще все, что угодно нарисовать.

В соседнем ответе все верно написали. CSS-трансформации - это именно то, что нужно в такой ситуации. Технически вся красота возникает из-за параллакса - там несколько слоев движутся с разной скоростью. Так что здесь не обязательно именно слайдер использовать - это может быть любой инструмент для построения кастомного скролла (с инерцией). При желании можно свой написать, это не так сложно, нужен лишь школьный справочник по физике, но можно и готовый инструмент взять. Тот же Locomotive Scroll вполне сгодится.

В этом примере как раз что-то похожее (только нужно открыть на CodePen - горизонтальный скролл не очень дружит с iframe-вставками):

• Белый по светлому не читается. Белый по пестрому - тем более. Голубой по голубому - ох...
  
• Странное смешение шрифтов с засечками и без. Никакой системы в этом не наблюдается. Какую задачу эта разница решает - непонятно.
  
• Очень много разных размеров шрифтов и межбуквенных интервалов. Проблема та же - нет системы.
  
• Отступы везде разные. Внизу их вобще нет. Проблема та же.
  
• Местами намешана информация. Глаза разбегаются. Здесь явно прослеживается идея поэкранного скролла, или чего-то вроде него, но стоит подумать над тем, чтобы каждый экран был о чем-то одном. Первый про то, что это такое (зачем там какие-то характеристики про опыт и духов?), дальше описание сервера (зачем там реклама справа?), магазин вообще спрятался в куче рандомных фактов по краям, я его в первый раз даже не заметил.
  
• Не совсем понятно, как это должно адаптироваться под разные размеры экранов.
  

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

1. Обращайте внимание на систему в дизайне. Загуглите, что такое дизайн-система и почему простота и последовательность - это хорошо.
   
2. Думайте больше о доступности и адаптивности. Вы дизайн делаете для пользователей в первую очередь. Красочная картинка вторична.
   
3. Не нужно нагромождать все, как в газете. Это очень редко работает. Управляйте вниманием пользователей, не давайте ему растекаться во все стороны.
   

P.S.: Также в таких проектах всегда нужно быть готовым к диалогу с разработчиком и не допускать требований pixel-perfect по согласованным без него макетам. Это не так сложно сверстать, но вот эти штуки по краям с линиями и кубиками будут генерироваться на лету (для адаптивности). Они не будут 100% соответствовать нарисованному. Также тут так и напрашивается все эти картинки анимировать, как на текущем сайте mtg. Не знаю, как этот стиль называется, но WebGL - наше все. Да и эти кубики я бы сделал неспешно плывущими более-менее вниз с покачиваниями и поворотами... Но это уже следующий шаг. Первое - система в дизайне и доступность.

...там работал обычный CSS, но был 3D объектом на который смотрит камера... Да, я видел всякие Three.js...

Как раз в Three.js есть такая штука как CSS 3D Renderer. Можно расположить условные div елементы в пространстве и работать с ними "в 3D".

task never defined: default

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

nmp

Ясное дело, что система не может найти nmp, когда он называется npm. Это сокращение от Node Package Manager.

Общая концепция будет примерно такая:

@keyframes custom-fade-in {
    0% {
        stroke-dasharray: 0 300;
        fill: transparent;
        animation-timing-function: ease-in;
    }
    50% {
        stroke-dasharray: 150 150;
        fill: transparent;
        animation-timing-function: ease-out;
    }
    100% {
        stroke-dasharray: 300 0;
        fill: #000;
    }
}

path {
    stroke: #000;
    fill: none;
    stroke-dasharray: 0 300;
    animation: custom-fade-in 2s ease-in-out infinite;
    animation-fill-mode: forwards;
}

Но если взять контуры как есть, то они будут заливаться не там, где нужно по дизайну. Нужно открыть эту SVG в векторном графическом редакторе и слегка порезать эти контуры. Нужно чтобы каждая буква была обрисована линией по кругу один раз, а не два, как сейчас. Тогда заливка будет по всей букве. А то сейчас заливается пространство между двумя почти продублированными контурами букв, т.к. технически именно оно является внутренной частью path. А еще будет удобно каждую букву делать отдельным контуром - проще будет подобрать значения для stroke-dasharray.

Вопрос даже не столько про GitHub, сколько про систему контроля версий. Что в нее должно попадать, а что - нет. По идее там должны быть все текстовые файлы, которые мы правим руками, и все, что нужно для сборки проекта. Чтобы можно было себе репозиторий склонировать, нажать кнопочку, и все недостающее собралось.

Если по типам файлов:

• Исходники с вашим кодом - однозначно да. Это самое главное.
  
• Все конфиги для сборки - да. Иначе без них проект не собрать. Исключение - какие-то ситуативно-локальные конфиги с ключами, паролями, и всем тем, что не должно попасть к другим людям. Но тогда это нужно описать в доках, что и где должно быть.
  
• Картинки - зависит от. SVG - скорее да, т.к. это текст. Растровые, особенно большие, может быть стоит хранить отдельно. Но это зависит от проекта и соглашений, главное избегать крайностей, чтобы репозиторий с лендингом не весил по пол гигабайта из-за исходников картинок или макетов. И это к любым бинарникам имеет отношение.
  
• node_modules - нет. Зависимости и зависимости зависимостей - это обычно тысячи файлов, которые вы никогда (ну почти никогда) не будете править своими руками. Они могут скачиваться при сборке проекта, в репозитории им делать нечего.
  
• Собранный и минифицированный проект - может быть. Зависит от применения. Обычно это не нужно хранить в системе контроля версий в том смысле, что минифицированные файлы мы все равно получаем при сборке и руками их не правим. Но иногда могут возникать ситуации вроде "хочу использовать репозиторий на GitHub как зеркало для моего NPM пакета" или "хочу захостить что-то на GitHub Pages", или "хочу, чтобы любая домохозяйка могла скопировать мой скрипт в свой бложик на wordpress и не парилась со сборкой", или еще что-то в этом духе. Иными словами, минифицированные файлы могут туда попасть, если вы понимаете, зачем это вам, какую задачу это решит. В общем случае пользы от этого никакой.