Ivan Bogachev

нужно, чтобы строки при переносе начинались с отступом

В свойстве list-style не нужен inside. Форматирование "с отступом" - это форматирование, которое применяется по умолчанию. Просто не меняйте то, что и так работает.

пропорции 16:9

Ну так:

.whois-video {
    aspect-ratio: 16 / 9;
}

И да, это уже можно делать. Пора уже забыть эти хаки с padding.

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



Код с повторениями почти одного и того же, вероятно его можно сократить в какой-нибудь хитрый миксин, но конечная идея примерно такая.

P.S.: И тут, по хорошему, стоит уточнить у дизайнера, как он видит длину затемнения в процентах от длины ячейки, особенно когда они сильно отличаются по пропорциям. Здесь градиенты от края до края, но, возможно, что в вашем случае нужно делать градиент не от 0% до 100%, а от 0% до какого-то другого значения, возможно зависящего от размера шрифта, а дальше уже заканчивать одним цветом.

var video = document.querySelector('video');

У вас в body нет ни одного тега video, соответственно с помощью querySelector не находится ничего, переменная video равна null, и дальше все ломается. Добавьте тег video и все заработает.

В SVG условный transform-origin всегда находится в координатах (0,0) координатной плоскости. Его нельзя изменить. Если мы пытаемся задать его в CSS, то логика работы трансформаций в CSS входит в явный конфликт с логикой работы трансформаций в SVG, и там каждый браузер интерпретирует происходящее на свой вкус (тут есть старая, но все еще годная статья по теме). В последние годы, со всеми этими сменами движков у браузеров, вкусы начинают двигаться в одну сторону, но бардак все еще присутствует. Но всегда можно сделать старую добрую матрешку:

<!-- 90 = x + width, 168 = y + height - правый нижний угол книги -->
<g transform="translate(90, 168.5)">
    <g id="book">
        <rect class="fil0 str0" x="60" y="18.5" width="30" height="150" transform="translate(-90, -168.5)" />
    </g>
</g>

Убираем transform-origin из CSS, чтобы не было конфликтов, смещаем нужный центр трансформации в координаты (0, 0), применяем там трансформацию, смещаем обратно, где он должен быть.

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

В большинстве случаев это решается размерами и расположением элементов в духе calc(100% + 0.5px). В зависимости от логики в дизайне значения меняются, но логика остается - добавляем к значениям в коде доли пикселя до тех пор, пока не начнет округляться нормально. Иногда, если там картинка, помогает font-size: 0 для контейнера картинки. Все это лютые костыли, и так оно не должно работать, но более толкового решения пока не наблюдается. Это баг браузера, который мы не контролируем.

Вообще рисование линий обычно делается через изменение свойств stroke-dasharray и stroke-dashoffset у кривых в SVG. Это самый простой способ в рамках фронтенда, хотя и изначально эти вещи были для другого придуманы. Но в случае с ЭКГ нужна постоянная скорость рисования по горизонтали. Поэтому можно взять прямоугольную маску в рамках той же SVG, и двигать ее в сторону:

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

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 их можно привязать к пикселям. По производительности что то, что это, будет плюс-минус одинаково, не прям супер (много элементов анимируются одновременно), но и явно тормозить нигде не должно.