Ivan Bogachev

Могу предположить что что-то на подобии gsap

Если рассматривать эту задачу в целом, без привязки к конкретному сайту, то это задача по созданию мультиков, в больших количествах, на потоке, в рамках сформированной дизайнерской системы. Делать это за счет фронтендеров - такая себе идея. Сложно всех синхронизировать, очень много накладных расходов. Это будет реально дорогая разработка. И разработчики нужны очень прошаренные по части анимаций, чтобы они были со всей командой дизайнеров на одной волне. Таких днем с огнем не найдешь. Более простой и дешевый подход состоит в том, чтобы этим всем занимались моушен-дизайнеры в рамках экосистемы Lottie. А со стороны разработки мы только интегрировали готовые сценки в сайт или приложение. В последние годы обычно все так и делают. Наш стек здесь не имеет значения, равно как и умения разработчиков.

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

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

the user agent might turn off anti-aliasing

или

might adjust line positions and line widths to align edges with device pixels

Но "might" не означает "must". На практике сглаживание или не отключается полностью, или отключается, но границы по пикселям смещаются так, что становится еще хуже, чем было, или еще какая фигня происходит. В разных браузерах все по-разному и поведение немного меняется со временем, так что старые костыли могут переставать работать. В CSS есть свойства, связанные со словом rendering, и они такие же мутные в своих формулировках.

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

Хорошего нативного и кроссбраузерного решения у нас пока нет. Но у path в SVG есть методы getTotalLength и getPointAtLength, а из них можно сообразить себе утилиту для расположения кружков вдоль кривой в удобных единицах измерения. Это не так здорово, как на CSS, но тем не менее:

function putCircleOnPath(path, circle, percent) {
    const length = path.getTotalLength();
    const point = path.getPointAtLength(length * percent / 100);

    circle.setAttribute('cx', point.x);
    circle.setAttribute('cy', point.y);
}

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

В 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), применяем там трансформацию, смещаем обратно, где он должен быть.

цифры мешают нажимать на места, а z-index изменить не получается

У SVG-элементов есть атрибут pointer-events. Работает он по той же логике, что и в CSS. Так что можно выключить интерактивность цифр, или что там еще мешает.

А "z-index" там работает по принципу "что раньше нарисовано - то ниже, что позже нарисовано - то выше". А отрисовывается все в том порядке, в котором оно в SVG-коде написано.

В начале файла стилей видно, что вы подключаете Font Awesome Free 6.2.1. Иконка fa-forward в нее входит, а вот иконка fa-arrows-repeat-1 уже входит в Pro-версию, а не Free. Для ее использования вам нужно $99 в год.

Для начала нужно определиться с двумя вещами:

1. Safari не очень дружит с морфингом SVG из CSS. Это относится не только к clip-path, но и к любому изменению контуров в самих SVG. Поэтому вариант делать это на CSS - такой себе вариант.
   
2. Для того, чтобы морфинг работал, нам нужно, чтобы контуры в SVG имели одинаковую структуру. Это первое правило морфинга. Почему это так, и в чем смысл морфинга в целом - можно почитать тут. Если вы делаете капли в blobmaker.app, то вам нужно иметь кляксы, сделанные с одним положением левого ползунка, который меняет количество точек. Правый двигать можно, рандомизировать можно, но количество точек должно быть постоянным.
   

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

При экспортировании там есть настройки (три точки вызывают всплывающий список параметров), и там есть пункт "Outline Text". Он как раз отвечает за то, будут ли буквы как буквы, или они будут конвертироваться в path. По умолчанию они конвертируются.

На MDN говорят, что это вопрос безопасности (там только про Gecko, но можно предположить, что везде так). Если SVG используется как картинка, то в ней уже нельзя подгрузить другие внешние ресурсы. Как вариант можно использовать тег embed вместо img, и все будет работать без таких ограничений.

Можно как-то так нашаманить:

Идея в том, что просто фильтр с feColorMatrix будет применяться вообще ко всему, нужно сначала выбрать область с конкретным цветом, там его заменить и наложить на оригинальное изображение.

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

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

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

@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.

Тут все дело в том, что вы используете для создания тени не саму кривую штуку, а "прозрачность" вокруг нее. Это немного нелогично с точки зрения понятия "тень". То есть у вас тень отбрасывает "пустота" вокруг кривой штуки (и эта "пустота" еще и обрезается в неудачном месте). Тут нужно использовать обратный подход, когда именно кривая штука используется для создания тени. В вашем примере для этого нужно поменять tableValues в feFuncA с "1 0" на "0 1" и в первом feComposite заменить "in" на "out".

Как альтернативный пример:


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