Добавляем анимацию блоков #4
Conversation
|
♻️ Я собрал ваш пулреквест. Посмотреть можно здесь. |
There was a problem hiding this comment.
✏️ Первичная проверка.
Обозначения:
🔴 - Нужно обязательно исправить.
☝️ - Нужно принять к сведению, обращать внимание в перспективе.
💡 - Дополнительные мысли для саморазвития (за рамками учебных задач).
🔷 - Важное сообщение.
Чеклист:
- Поочередное появление пунктов правил. Тексты появляются из прозрачности со смещением.
- Анимация кружков - с увеличением/уменьшением, как и у кнопки социальных сетей в шапке.
- Кнопка "Погнали" появляется в форме круга, расширяется, затем в ней появляется текст.
Комментарии:
💡 - Получение длительностей и угадывание временных функций из видео при работе над интерфейсами – в некоторой степени сомнительная затея. В рамках учебного курса, как упражнение - ок. Развиваем глазомер, так сказать, учимся видеть детали. Но в реальной работе этим заниматься не стоит - слишком уж много времени уходит на что-то, чем можно вообще не заниматься. Обычно мы можем организовать процессы так, чтобы исключить саму идею подбора чего-то из видео. Это упростит работу всем вокруг. Дизайн интерфейсов – это же больше промышленный дизайн, чем искусство. Все должно быть по возможности унифицировано для уменьшения издержек на производстве. Если анимации имеют разную длительность – это должно быть логически обосновано. Если разные временные функции – тоже. Так или иначе мы приходим к ограниченной дизайн-системе (даже если ее изначально нет в проекте, то мы ее можем создать), и все длительности, задержки и временные функции берутся из нее. В таком контексте видео-концепты становятся просто способом показать суть движений, когда их сложно описать словами. Видео не нужно рассматривать как эталон, к которому нужно что-то подгонять по времени.
💡 - Если все же возникает желание/необходимость посмотреть видео по кадрам (например если дизайнеры нашли какое-то видео в интернете и там какое-то хитрое движение, и его нужно разглядеть получше), то это может быть удобно делать в программах, предназначенных для редактирования видео. Если вы еще пользуетесь плеером с одной кнопкой на страницах учебника - попробуйте альтернативные варианты, чтобы посмотреть, как оно может выглядеть. Там есть разные программы, сам я обычно использую Blender для таких исключительных ситуаций, потому что он и так используется для работы с 3D, и получается все в одном месте.
Итог:
✅ - Задание принято.
| opacity: 1; | ||
| transform: translateX(0); |
There was a problem hiding this comment.
☝️ - Для таких универсальных анимаций есть общепринятые названия вроде fadeIn, fadeOut, fadeInLeft, fadeInRight и.т.д. Есть популярная библиотека animate.css в которой они все собраны. Если вы будете придерживаться этих названий - ваш код будет проще понимать вашим коллегам, не нужно будет думать, что делает та или иная анимация. По крайней мере познакомиться с этой системой названий точно стоит.
| @function counter-animation-delay($i) { | ||
| @return ($i - 1) * $counter-animation-duration; | ||
| } |
There was a problem hiding this comment.
☝️ - Я вижу определенную логику здесь, но на самом деле напрашивается мысль, что можно было бы все эти расчеты построить на CSS custom properties. Это не даст какой-то сильной нагрузки на железо, а вот нагрузку на мозг снимет. Результаты этих расчетов используются в одном единственном месте, вынесенный в сторону миксин усложняет восприятие. И плюс не нужно будет повторять одни и те же строки для before и p ниже. Кода будет заметно меньше и воспринимать его будет проще. Подумайте над этим. CSS не стоит на месте, и в подобных задачах часто можно сильно сократить количество кода без каких-то сильных побочных эффектов.
| $counter-animation-duration: 0.3s; | ||
| $counter-number-animation-duration: 0.4s; |
There was a problem hiding this comment.
☝️ - И если продолжать мысли про упрощение восприятия, то можно сказать, что эти вынесенные в сторону константы тоже не имеют особого смысла. Эти значения так же используются только в одном месте, и их смысл однозначно трактуется из того факта, что в том CSS свойстве ничего другого, кроме длительности, быть не может. Если это были бы вынесенные в единую на весь проект систему значения со смыслами вроде "короткая", "средняя", "длинная" и они бы переиспользовались во всех компонентах, то это была бы система, которая приводит весь проект к единому знаменателю. И мы бы находили в этом определенную прелесть при построении процессов разработки. Но текущие константы такого эффекта не дают. Они просто есть чтобы были. Не совсем понятно, какую задачу они решают.
|
|
||
| @keyframes show-btn { | ||
| from { | ||
| width: 6rem; |
There was a problem hiding this comment.
☝️ - С точки зрения производительности лучше отдавать предпочтение свойству transform. Более подробно тема производительности в CSS разбирается во втором модуле учебника, но если в двух словах, то лучше все, что есть, анимировать меняя свойства transform и opacity, т.к. они менее склонны вызывать перерисовку всей страницы. Не всегда решение очевидно с первого взгляда, но это вопросы больше из области верстки, а не анимаций. Вы вроде как уже начинали верстать на трансформациях, стоит эту тему и дальше развивать.
💡 - Может быть полезно завести себе в привычку сразу верстать разные состояния компонентов интерфейса так, чтобы они отличались только по этим свойствам, или по крайней мере стремиться к этому. Если верстку делает кто-то другой, то можно требование использовать эти свойства заранее включить в ТЗ. Это простой способ предотвратить рост технического долга по части производительности в нашем текущем контексте. Главный подводный камень тут в том, что проблемы с производительностью, заложенные в таких анимациях, имеют накопительный эффект. Чем больше одновременных анимаций и чем больше страница - тем сильнее они будут проявляться. И не всегда можно заранее предсказать, где те или иные компоненты будут использоваться. В результате может получиться пожар из разряда тех, что проще предотвратить, чем потушить. Думаю вы видели такие интернет-магазины, которые чуть ли не вешаются при открывании какой-нибудь менюшки - это именно оно. Схожий эффект может дать постоянное залезание в DOM из скриптов и совершение операций, которые вызывают перерисовку страницы в той или иной степени. Там тоже легко закрыть на это глаза на простой странице, но по мере роста проекта проблемы с производительностью будут усугубляться аналогичным образом. В некоторых особо сложных случаях делу может помочь свойство contain, но оно не решает проблему с перерисовкой страницы полностью, оно лишь помогает ее локализовать. Иногда этого достаточно, чтобы страница перестала тормозить, иногда - нет.
🎓 Добавляем анимацию блоков
💥 https://htmlacademy-animation.github.io/2523083-magic-vacation-1/4/