Ivan Bogachev

не влезая в плагин, уже на загруженной странице

const table = document.querySelector('table');
const html = table.innerHTML;
const modifiedHtml = html.replace(/>\s+<i/g, '>&nbsp;<i');

table.innerHTML = modifiedHtml;

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

Эффект определенно зависит от расположения мыши, расположения кнопки, и, возможно, от ее размеров. Так в чем проблема начать и посмотреть, что будет?

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

Можно ли как то совместить эти события, чтобы и слайды листать, и кнопки в плеере нажимать?

В том виде, в котором оно есть сейчас - нет. Проблема существует с 2013 года как минимум и будет решена примерно никогда, потому что обе стороны конфликта говорят, что проблема не на их стороне. Но можно вместо интерфейса от youtube прикрутить свой. То есть плеер оставить, но управление сделать свое, которое будет как-то сочетаться с имеющимся интерфейсом. Такой вот компромисс. Концептуально это будет выглядеть так, что мы убираем стандартный iframe, отключаем для плеера pointer-events:

<div class='swiper' id='my-slider'>
    <div class='swiper-wrapper'>
        <div class='swiper-slide'>Slide 1</div>
        <div class='swiper-slide' id='youtube-slide'>
            <div id='player'></div>
        </div>
        <div class='swiper-slide'>Slide 3</div>
        <div class='swiper-slide'>Slide 4</div>
    </div>
</div>
<style>
#player {
    pointer-events: none;
}
</style>

И переходим к API на js, чтобы сформировать свой плеер, который мы будем контролировать:

const youtubeScriptTag = document.createElement('script');
youtubeScriptTag.src = 'https://www.youtube.com/iframe_api';
document.body.appendChild(youtubeScriptTag);

window.onYouTubeIframeAPIReady = () => {
    const player = new YT.Player('player', {
        videoId: 'orbr-C3gYKk',
        playerVars: {
            controls: 0
        },
        events: {
            onReady: (event) => {
                const youtubeSlide = document.getElementById('youtube-slide');
                let isVideoPlaying = false;

                youtubeSlide.addEventListener('click', () => {
                    if (isVideoPlaying) {
                        event.target.stopVideo();
                    } else {
                        event.target.playVideo();
                    }

                    isVideoPlaying = !isVideoPlaying;
                });
            }
        }
    });
}

const swiper = new Swiper('#my-slider', {});

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

P.S.: На CodePen метод playVideo может не работать в Chrome-подобных браузерах из-за особенностей работы песочницы, но на обычной странице все должно быть ок.

Из описания вопроса не совсем понятно, какую именно логику следования стрелки за мышкой вы хотите получить (можно придумать разные варианты), но скорее всего вам нужно отталкиваться от логики вроде такой:

// Тут, конечно, лучше какие-нибудь id сделать для однозначности
const circle = document.querySelector('.circle');
const arrow = document.querySelector('.arrow');

document.addEventListener('mousemove', (e) => {    
    const circleRect = circle.getBoundingClientRect();
    const circleCenterX = circleRect.left + circle.offsetWidth / 2;
    const circleCenterY = circleRect.top + circle.offsetHeight / 2;
    const deltaX = e.clientX - circleCenterX;
    const deltaY = e.clientY - circleCenterY;
    const angleInRadians = Math.atan2(deltaY, deltaX) - Math.PI / 2;
    const angleInDegrees = 180 * angleInRadians / Math.PI;
    const angleFrom0To360 = (angleInDegrees + 360) % 360;
    const shouldEffectBeApplied = deltaY < 0;
    
    if (shouldEffectBeApplied) {
        arrow.style.transform = `rotate(${angleFrom0To360}deg)`;
    }
});

И еще в таких штуках всегда хорошо добавить какой-нибудь transition в CSS:

.arrow {
    transition: transform .1s linear;
}

В светлом будущем для решения этой задачи у нас будет :has. Но пока что о кроссбраузерности там речи не идет. В текущем состоянии CSS нет селектора, который бы позволил сделать тот же эффект. Но в контексте вашей задачи никто не мешает самим item сделать классы-модификаторы.

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

Можно что-то такое сделать:

.inv-cell {
    position: relative;
}

img {
    position: absolute;
    width: 100%;
    height: 100%;
    object-fit: cover;
}

Весь вопрос тут будет скорее не в размере картинок, а в их пропорциях. Если вы привязываете саму сетку к пропорциям экрана - она 100% будет расходиться с пропорциями картинок внутри в ту или иную сторону. Если это какие-то формальные фоточки, то object-fit решит вопрос, если же это превьюшки для фильмов с текстами или еще чем-то, что нельзя отрезать - то будет вопрос по самой концепции к дизайнеру, и его нужно будет решать с ним.

Смешались в кучу кони, люди, GSAP, React, Three.js... Стоит немного систематизировать инструменты хотя бы по задачам, которые они решают. Не привязываясь к конкретным фреймворкам из большой троицы, у нас есть несколько классов инструментов в теме креативных сайтов:

• Про готовые CSS-анимации - animate.css, Wow.js, и.т.д. Там много динозавров из времен jQuery. Такие штуки часто бывают не в тему дизайна, но стоит посмотреть и забыть. Хотя для сайтов в духе дизайнерской дичи, вроде той, что успешно делают в студии Артемия Лебедева - может быть и ок.
  
• Про интерполяцию всего и вся. Тут обычно выбирают между GSAP и Anime.js. Первый вариант - более замороченный, есть полезные плагины, второй - попроще, но тоже хорош, в некоторых кругах даже более популярен. Для совсем простых задач - можно свой инструмент написать.
  
• Про скролл, в основном в контексте CSS-анимаций. Тут Locomotive Scroll рулит.
  
• Про переходы между экранами. Грубо говоря прокаченный роутер. Самый популярный - Barba.js. Раньше еще был Highway.js, но в последне время что-то про него мало говорят.
  
• Про экспорт готовых анимаций из софта для анимаций. Тут нужно отталкиваться от софта. Обычно вопрос возникает в контексте AE и простых мультиков - тут Lottie, говорят, неплох. Но нужно дизайнера заранее консультировать по теме, чтобы лишнего не намалевал.
  
• Про визуализацию данных. Тут полезно знать про d3.js, в основном ради готовых примеров.
  
• Про трехмерный WebGL, чтобы не писать все руками. Самый популярный вариант - Three.js, в основном за счет экосистемы и горы готовых решений, но есть и альтернативы на любой кус и цвет. Для 2D -эффектов вообще ничего не нужно в большинстве случаев.
  
• Плюс не стоит забывать про всякие вспомогательные штуки вроде WebFontLoader, Hammer.js, LeaderLine, и.т.д. К анимациям они не относятся, но в работе могут быть полезны, чтобы не писать все самому.
  

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

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

Нужно чтобы форма была по центру

Тогда может быть align-self: center; должно быть у самой формы?

Теги - это все же про HTML, а не про CSS.

А со всем, что есть в CSS, можно познакомиться на сайте W3C. Они заботливо делают странички с состоянием CSS на текущий год, где есть перечисление всего со ссылками на стандарты, где можно более подробно обо всем почитать. Но это такой источник информации для теоретиков, если хотите погрузиться действительно глубоко. На сайте MDN есть почти то же самое, но в формате, более ориентированном на практику, чем на теорию.

svg

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

на css такое сделать

Поскольку пути простые, все под 90 градусов - можно и на CSS сделать все это:


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

По сути SVG - это почти HTML (ок, нехорошо так говорить, но тем не менее). Дерево из тегов, атрибуты, все дела. Выбираем нужные элементы, меняем атрибуты - вот и вся анимация. Как и с любыми другими элементами на странице. Это не какой-то отдельный и ни на что не похожий тип анимаций.

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

1. CSS. Картинку, вставленную в страницу, можно анимировать с помощью CSS в каких-то пределах. Не все так получится сделать, но какие-то простые движения, изменения цветов - вполне можно. Если вы знаете CSS - можно сказать, что уже знаете все, что тут можно сделать.
   
2. JS. Все как всегда. Получаем элементы через querySelector, getElementBy... и.т.д., и через setAttribute задаем элементам SVG нужные атрибуты. Обычно удобно добавить какой-то инструмент для интерполяций значений во времени. Из популярного - GSAP и Anime.js. При желании можно что-то свое написать, если задачи совсем простые, в базовом варианте все подобные инструменты строятся примерно по такому принципу. Некоторые инструменты добавляют какие-то еще свои дополнительные возможности, или есть готовые прикольные примеры, сделанные с их использованием, как например у d3.js, но нужны ли они лично вам - нельзя сказать, не зная задач. А инструменты должны выбираться исходя из этих самых задач, а не из моды. Здесь важно лишь понимать, что никакие библиотеки не расширяют сам формат SVG, не привносят никаких принципиально новых возможностей в него, они все больше про организацию скриптов.
   
3. Еще есть SMIL. Это древнее зло из миров, далеких фронтенду. Есть хороший туториал на CSS-tricks. Это все "модно-нативно", но иногда сложно синхронизировать с остальными событиями на странице, и сложно отлаживать, т.к. нет адекватной привязки к инструментам разработчика в браузерах.
   

Полезно еще познакомиться с вот этой статьей, там отмечены некоторые косяки, связанные с кроссбраузерностью. Да, SVG - это штука, которая вроде бы была с нами всегда, но в контексте анимирования wtf-моментов там все еще достаточно.

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

Ну и полезно познакомиться с каким-нибудь векторным графическим редактором, чтобы уметь структурировать SVG перед анимированием, удалять мусор, адаптировать контуры для морфинга (не всегда дизайнер будет предоставлять полный набор нужных контуров).

Если хранить все в одном css/js то пока js загрузиться будет мелькать html сайта а после уже загрузочный экран будет

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

красивый загрузочный экран, стоит задача создать такой-же... стили и скрипты...

Скрипты здесь не нужны, можно все на CSS сделать (ну только потом, в основном скрипте, когда он загрузится, нужно будет убрать этот экран). А еще, как вариант, можно воспользоваться древней магией под кодовым названием SMIL для встроенной в страницу SVG-картинки с логотипом и надписью. Будет по сути то же самое, только сбоку.

Набор инструментов - это всегда дискуссии из разряда "на вкус и цвет фломастеры разные". Я бы в первую очередь смотрел на:

• Для скролла - Locomotive Scroll.
  
• Для всего подряд - Anime.js.
  
• Для плавных переходов между страницами - Barba.js.
  
• Для 3D - Three.js.
  

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