Компания
87,35
рейтинг
16 ноября 2012 в 14:18

Разработка → CSS анимации на реальном проекте



Всё чаще среди веб-разработчиков поднимается тема возможностей CSS анимаций (transition/animation), практически на каждой конференции по клиентской разработке можно услышать о потрясающих преимуществах новой технологии.

Производительность и гибкость CSS анимаций позволяет творить удивительные вещи, но можно ли уже использовать эти новые возможности в силу их нестабильности и незрелости на реальных больших проектах?

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

Состояние спецификации


Модули CSS transitions и animations в W3C по-прежнему находится в состоянии “working draft”, но Firefox, Opera и Internet Explorer 10 уже откинули префиксы для этих свойств. Избавление от префиксов означает, что производители браузеров уже уверены в стабильности технологии и рекомендуют её к активному использованию.

Если большие игроки до сих пор боялись улучшать user experience пользователей за счет анимаций, ссылаясь на плохую производительность JavaScript, то сейчас самое время пересмотреть свой подход разработки интерфейсов и начать использовать возможности CSS3.

Информационный голод


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

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

Последнее время мы часто встречаемся с браузерными багами, о которых нет ни слова в сети. Вследствие чего приходится самим исследовать проблему, писать баг-репорты и искать необычные решения для её устранения.

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

CSS анимации в реальном мире


Давайте посмотрим, какие веб-проекты осмелились укротить новую технологию и не побоялись выступить пионерами в отрасли:

ВКонтакте частично использует анимацию на простых, маленьких блоках, часто выбирая JavaScript анимацию вместо CSS, даже для простых анимаций opacity и в переходах цвета текста. Поиск по стилям проекта выдаёт 17 вхождений transition (не считая свойства с префиксами).

На Facebook анимации тоже не прижились, по всем стилям найдено только пять вхождений transition, и единственная попавшаяся на глаза анимация последнего отосланного сообщения сделана на JS.

Ребята из Google+, видимо, принципиально не используют анимации (наверное, из-за проблем Chrome в работе с анимациями :), нашлось только 3 вхождения transition. Поиск “animation” выдал только одно вхождение в Goolge+.

На момент написания статьи в стилях Одноклассников — 140 вызовов transition и 4 animation, учитывая, что часть анимаций стандартизирована и переиспользуется во многих местах.

Интересное замечание — с момента написания первой версии статьи прошло пару месяцев, за это время количество анимаций на перечисленных проектах не выросло, кроме Одноклассников — количество анимаций в нашей социальной сети выросло практически в 3 раза.

Что стоит анимировать


Чем больше мы приближаем работу интерфейса к реальности, тем понятней он становится для пользователя. В жизни практически ничего не происходит мгновенно — открывая дверь, или закрывая лаптоп, мы наблюдаем кучу промежуточных состояний, а не резкое “открыто/закрыто”, как это происходит в вебе.

Мы стараемся применять анимации даже на самые рядовые действия — показ скрытых контролов на ховер, дроп-даун меню, информационные тултипы. Анимации помогают акцентировать внимание пользователя на элементы управления с помощью различных помигиваний и подёргиваний.

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

Пример контрола без анимации

Пример контрола с анимацией

Обмен опытом


Подборка багов и решений


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

Демо страница на dabblet, архив с примерами (на Я.Диске).

Opera


При комбинировании анимаций, например, opacity с box-shadow, могут наблюдаться проблемы в Опере (см. блок 1 на демо странице), когда тень полностью исчезает вместе с ховером, при обратной анимации тень возвращается с задержкой и без ожидаемой плавности.

.no_sec {
    transition: opacity 1s, box-shadow 0; 
    box-shadow: 0 0 5px 5px #000;
    }

    .no_sec:hover {opacity: 0; box-shadow: none;}

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

.no_sec.shadow {
    transition: opacity 1s, box-shadow .3s;
    box-shadow: 0 0 5px 5px blue;
    }

    .no_sec.shadow:hover {opacity: 0; box-shadow: none;}

Блоки с псевдоэлементами проблемно анимируются в Opera 12, оставляя схожие артефакты с первым примером (блок 2), причем в Opera 11.64 работает стабильно.

.pseudo {
    position: relative; 
    transition: opacity 1s;
    }

    .pseudo:hover {opacity: 0;}

    .pseudo::after {
        content: 'pseudo';
        position: absolute;
        left: 0; top: 100%;
        height: 10px; width: 100%;
        background: blue;
        font-size: 10px; line-height: 1;
        }

Приходится отказываться от псевдоэлементов и использовать обычные теги.

Firefox


Если не указать значение «s» (секунд) в transition, Firefox игнонирует анимацию полностью (блок 1). В блоке 3 выставлено рабочее значение анимации тени в Firefox.

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

Webkit


В Chrome на Mac (как минимум до 23-й версии) при использовании transition вместе с transform (блок 4), а также и при других условиях ломается сглаживание текста на всей странице.

Со сглаживанием:
Текст со сглаживанием

Без сглаживания:
Текст без сглаживания

.scale {
    transition: transform 1s;
    /*-webkit-backface-
    visibility: hidden;*/           
    }

    .scale:hover {transform: scale(1.5)}

Проблему помогает решить свойство backface-visibility: hidden, применённый на body, либо на блок с мерцающим текстом, но такой фикс тоже имеет свои последствия (подробности ниже в статье), к тому же, текст потеряет сглаживание навсегда.

В Chrome не работает transition, если блок меняет свойства с display: block -> display: inline/inline-block (блок 5).

.inline b {opacity: 0; transition: opacity 1s; display: block; max-height: 0;}
.inline:hover b {opacity: 1; display: inline; }

Чтобы обойти проблему, нужно применять animation (блок 5.1).

@-webkit-keyframes reveal {
    from { opacity: 0; }
    to { opacity: 1; }
    }

.inline.anim:hover b {-webkit-animation: reveal 1s;}

В Chrome на Windows во время плавной анимации transform все инпуты получают белый фон (блок 4 с трансформом и 6 с инпутом).

Подобный эффект также наблюдается, если на любой элемент страницы применить backface-visibility. Решение проблемы пока не было найдено.

Пример белого фона под инпутом, из за backface-visibility

Общие баги


Нигде, кроме Webkit, не работает transition на background-image, нельзя поставить даже задержку, картинка меняется мгновенно (блок 7).

.bg_img {
    background: red url(image1.png);
    transition: background-color 1s linear, background-image 0s linear 1s;
    }

    .bg_img:hover {background: blue url(image2.png);}

Для решения проблемы приходилось комбинировать анимацию в нескольких слоях с помощью opacity.

Во время transition блок с анимацией opacity перекрывает другие блоки.

Чтобы избежать проблем, нужно поставить блоки, на которые не нужна анимация ниже в доме (так они автоматически получат выше z-index), либо прописать z-index вручную (блок 8.1).

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

На заметку


В CSS transition возможно контролировать анимацию в обе стороны, например, меняя скорость анимации:

.block {transition: 10s opacity;}
.block:hover {opacity: 0; transition-duration: 1s;}

При ховере переход в opacity: 0; произойдёт за 1 секунду, а обратный переход в opacity: 1; будет длиться 10 секунд. Таким образом, можно, например, при ховере “навсегда” оставить свойства ховер стейта, используя очень большую задержку.

При использовании animation, следует ожидать, что во время анимации блок не подвержен никаким внешним воздействиям (прим. смена цвета на ховер). Для этого можно сначала остановить анимацию, используя “animation-play-state:paused;“ или совсем обнулить анимацию, применяя свойство “animation: none;”.

Работая с анимациями, переодически приходится возвращаться к истокам и заново изучать самые древние возможности CSS, как у нас вышло с псевдоклассом :active.

Backface-visibility


Ранее мы упоминали backface-visibility как вариант решения некоторых багов webkit браузеров, но местами это свойство может привести к еще большим проблемам. Помимо стандартного предназначения этого свойства (прятать обратную сторону 3D анимируемого блока), его часто используют для включения аппаратного ускорения, позволяющего с помощью GPU ускорить время рендеринга страниц в браузере.

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

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

Первый раз мы столкнулись с последствиями этого свойства, когда решили применить его на элемент body для Chrome и Safari на Mac ради избежания мерцания текста при анимациях. При этом в Safari 5 стало появляться множество необъяснимых багов, страница разъезжалась в совершенно непредсказуемых местах, вследствие пришлось оставить backface-visibility только для Chrome Mac и на самые проблемные места с мерцающим текстом в Safari. С выходом Safari 6 ситуация немного устаканилась и поведение браузера по отношению к злополучному свойству приравнялось к поведению нынешнего Chrome.

На прицеле


Всегда следите за обновлениями браузеров и проверяйте свой портал на developer и preview версиях, если вы не хотите, чтобы ваш портал прогнулся под натиском багов из-за очередного обновления браузера.

Помимо реализации поддержки новых технологий и откидывания префиксов, вместе с новой версией могут прийти не совсем стабильные алгоритмы оптимизации рендеринга страницы. Учитывая, что часть рендеринга браузеры начинают перекидывать на GPU, стоит так же ожидать, что баги могут воспроизводится только на машинах с определённым железом. Были случаи, что на некоторых компьютерах в одном и том же браузере не работал 3D transform из-за видео карты.

Вместе с выходом 21-й версии Chrome на стабильной ветке нам пришлось встретится с кучей необъяснимых багов, касающихся не только CSS3 анимаций, одним из критичных оказался баг с черными пятнами (только в Chrome на Windows), которые хаотично появлялись по всей странице из-за анимации opacity. Самое интересное, что версии stable и dev (в Chrome) могут легко отличаться, даже если в 22-й dev версии баг починен, не факт, что с переводом ветки в stable фикс останется.

Интересный случай наблюдался и с выходом Safari 6, с обновлением браузер подтянул много изменений из ветки разработки webkit движка и перенял множество багов нынешнего Chrome.

Оптимизация


Одно из основных правил нашей команды разработки интерфейсов — как можно больше pure CSS решений. Использование CSS взамен JavaScript даёт отличный прирост производительности клиентской части как и по скорости работы интерфейса, так и по времени разработки.

Every byte counts


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

transition-property: top;
transition-duration: 1s;
transition-timing-function: ease;
transition-delay: 0.5s;
=
transition: top 1s .5s;

К слову, самая минимальная запись анимации — “transition: 1s”, остальные свойства по умолчанию: «all ease 0;»

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

transition: all … ;

взамен четкого

transition: opacity … ;

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

Также не забывайте следить за префиксами, например, свойств -ms-animation и -ms-transition вообще не существует, т.к. 10-ая версия Internet Explorer вышла с уже опущенными префиксами. CSS препроцессоры позволяют сильно упросить работу с префиксами с помощью миксинов.

Стандартизируем


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

Вот пример одного из переиспользуемых модулей:

.fade {
    transition: .3s opacity, visibility 0s .3s;

    visibility:hidden;
    opacity: 0;
    }

    .fade_in:hover .fade {
        transition-delay: 0s;

        visibility: visible;
        opacity: 1;
        }

Этот стандартный модуль позволяет нам сэкономить кучу повторных вхождений кода для самого часто встречающегося эффекта анимации. Используя дополнительно свойство “visibility”, мы реализуем обратную совместимость для браузеров, не поддерживающих CSS анимации.

Вывод


Глядя на множество трудностей, с которыми приходится сталкиваться при работе с CSS анимациями, может показаться, что усилия не оправданы, но это совершенно не так:

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

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

В-третьих, работать с CSS анимациями интересно! Что может быть более вдохновляющим, чем быть пионерами технологии и прокладывать первые пути? Если в задаче по созданию нового интерфейса есть хоть один анимируемый элемент, то работать с ней становится намного захватывающе. Особенно приятно слышать похвальные отзывы, делясь наработками с коллегами-верстальщиками.
Автор: @Odnoklassniki_ru
Одноклассники
рейтинг 87,35

Комментарии (66)

  • +9
    А вы молодцы. Самому часто приходится отказываться от стандартов css3 для интеграции со старыми версиями браузеров. Спасибо за статью!
    • +2
      Не нужно бояться за старые браузеры, контент от этого не пострадает, а красивый и понятный интерфейс увидят уже 65%+ пользователей (по статистике Stat Counter).
      • 0
        А своей у вас нету что-ли? По нашей, например, поддерживается более чем у 70%.
        • +1
          У нас есть своя статистика, но, в этом вопросе она важна только в контексте нашего портала.

          Мы привели пример мировой статистики, показывая глобальной аудитории, что «уже пора».
          • +1
            Ну почему, она достаточно интересна и в контексте российского рынка, особенно его консервативной части.
            • +6
              По последним данным, у нас более 82% пользователей имеют поддержку CSS transitions и немного меньше CSS animations, за счет поздней реализации технологии в Опере.
  • 0
    Ну вообще-то на то и префиксы, что есть баги. Используйте на свой страх и риск, как говорится.

    P.S. Только прочитав статью, увидел что в начале не логотип HTML5.
    • +1
      Это неофициальный вариант CSS3 логотипа :)
      • 0
        Я не про CSS3, а про логотип перед ним.
        • +2
          Хорошая ассоциация ОК и HTML5 :)
          • 0
            Цвет похож, а в детали не вглядываешься.
    • 0
      Правда, но префиксы остались только у Chrome, можно делать анимации для всех, кроме него :) если страшитесь нестабильности.
  • +1
  • 0
    Зачем пользователю ждать долгую анимацию? Вообще, всё, что дольше 0.7 секуды — зло.
    • 0
      Можно вполне ограничиваться этими рамками, и делать быстрые анимации.
    • 0
      Согласен, долгие анимации раздражают и рождают в голове слово “тягомотина”, а быстрые — наоборот, показывают, как хорош компьютер.
      • 0
        Быстрые анимации создают иллюзию ускоренного интерфейса.
        • +1
          В CSS существуют как анимации, так и переходы. Всему свое применение, да и время сего зависит от контекста, то бишь может быть уместен переход за .2 секунды, аль анимация на 1 секунду.
          • 0
            Да, всё так. Но в контексте анимации интерфейса скорость, думаю, всегда должна быть высокой. За исключением разовых исключений, разумеется.
    • +1
      Можно реализовать наример ajax loader — анимация будет отображаться до тех пор пока не загрузится контент (а на мобильных девайсах при плохом покрытии может долго) и тут уже спорно не слишком ли быстро будет крутиться полосочка или кружечек.
      • +1
        Скорость-то будет одинаковая. Просто где-то имеет смысл зациклить анимацию на бесконечность.
        • 0
          Накидал пример jsfiddle.net/QDvU7/2/, вроде бы 0.7s норм, хотя мозг все равно думает, что могут быть случаи когда лучше подольше.
          • 0
            Что забавно: не крутится в стабильном Chrome. Что не так? Все префиксы, вроде, стоят.
            • 0
              C prefix-free — jsfiddle.net/QDvU7/4/
              • 0
                Да, так работает даже на iOS5+Chrome/Safari
          • 0
            Там опечтка, в вебките jsfiddle.net/QDvU7/5/

            @-webkit-keyframes loader {
                from {
                    -webkit-transform: rotate(0deg);
                    transform: rotate(0deg);
                }
                to {
                    -webkit-transform: rotate(0deg);
                    transform: rotate(360deg);
                }
            }
            

            Надо:
                to {
                    -webkit-transform: rotate(360deg);
                    transform: rotate(360deg);
                }
            
      • 0
        Это нюанс немного другого рода. Я имел в виду анимацию, как на гифке вверху поста: где выезжает пункт меню.
    • +1
      Зависит от контекста. Если выпадающее меню будет выпадать слишком долго, то зло, а если подсветка кнопки будет плавной, то почему нет? В общем надо учитывать зависимость функционала от анимации.
  • 0
    Пример с GIF'кой как раз такой, что создает страные впечатления. Т.е. пока кружок отодвигается, то под ним начинает проявляться блок. Можно же было сделать как-то поинтереснее. Пример. На все про все 5 минут. У анимаций есть еще и куча проблем, то бишь нельзя анимировать к значению auto (из-за этого в примере использовал костыль с max-width), аль к проприетарному свойству "-moz-max-content" и аналогам, да еще и с определенной скоростью, то бишь разворачивать список со скоростью 10px в пол секунды и т.п. Пока что нелья анимировать градиенты и некоторые иные свойства. Но использовать в разумных пределах вполне возможно. Да и со всякими ссылками по «событию» :hover уже вполне практикуется.
    • +2
      И, да, извечный баг webkit'а с неанимированием псевдо-элементов. Когда же они его исправят?..
      • +1
        Проходим по ссылке, жмём звёздочку, не стесняемся.
        • +1
          Судя по колличеству комментариев это не шибко решает… Увы и ах :).
          • 0
            Просто решил лизний раз напомнить. Где, как не в сообществе “компьютерщиков”, напоминать об этом? :)
      • +1
        У Ромы Комарова есть идеи на этот счет, ему удалось заанимировать псевдоэлемент.
        • +1
          Я уже высказывался на сей счет. И что мнение мое, что баг в webkit'ах… Стабильность, мать ее…
    • +1
      Такое поведение было задумано дизайнерами, с технической точки зрения было интересней делать как раз с запоздалым появлением серого блока. К сожалению ваш пример не работает в Safari 6, только в Chrome.

      Переход (transition) может происходить только из 1 конкретного значения, в другое. Это скорей не проблема анимаций, а ограничения, которые, скорей всего, связаны с производительностью.

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

      • 0
        Если так было задумано, то да, быть может… Ну а по остальному можно тоже самое сказать про любое свойство CSS, аль селектор, аль что-то из HTML5. Да про что угодно. Если нет желания развиваться у разработчика / верстальщика / простого человек, то и на выходе не будет творчества. Я не против подобных статей, скорее всего они кого-то и подстегнут к обучнию прекрасному, но желание должно исходить не от обущающего, а от обучаемого. Анимациям и переходам уже далеко не первый день…
  • 0
    Расскажите, работаете ли вы с CSS transitions из JavaScript? Если да, то не сталкивались ли с тем, что события ontransitionend в Firefox срабатывают только несколько раз, а потом перестают? Другие браузеры отрабатывают каждое завершение. Все значения свойств для перехода задаются через element.style с префиксами. Переход только по opacity. Может, кто-то еще сталкивался, или есть ссылки, где почитать, как исправить или обойти.
    • 0
      У нас пока не возникало необходимости работать с CSS transitions из JavaScript, но можем посоветовать ознакомится с докладом по этой теме, с недавно прошедшей конференции Fronteers.
      • +1
        Решил ответить сразу в 2 комментария, ибо, быть может, вам это тоже будет интересно. В общем, со случаем несрабатывания событий по положению звезд на небе, аль еще кокому-то незадокументированному действу я не сталкивался (примерчик бы...), но сталкивался с другим багом, из-за которого событие «transitionend» (правильно без «on») не срабатывает на фоновых вкладках. + сталкивался с фичей, из-за которой сей код не сработает как ожидается. Но это можно решить вот так. Забавно, но на сей вариант я вышел опытным путем (как бы странно это не звучало и, да, еще можно решить сей вопрос с setTimeout'ом). Тем не менее позднее, роясь в дебрях спецификаций и иже с ними я наткнулся на http://lists.w3.org/Archives/Public/www-style/2011Mar/0729.html.

        И, да, это только касаясь Firefox'а (актуально вполть до 19.0a1), хоть это еще не все его баги… Чем дольше капаешься в каких-то свойствах, тем больше багов отлавливаешь :).
        • 0
          +, тематическая ссылка в подарок :).
        • 0
          Да, transitionend. У меня в коде событие правильное, поскольку несколько раз оно срабатывает, а потом перестает. Причем вкладка при этом не переключается. Пример, оторванный от контекста, типа jsfiddle, пока нет времени сделать, прошу прощения за телепатию. Но если кто сталкивался с таким поведением в принципе, независимо от конкретного случая, опыт будет полезным. Спасибо за ссылки, посмотрю в ближайшее время.
          • 0
            Есть еще одна фича касательно Firefox'а. Про другие браузеры сказать не могу. К примеру, у вас имеется элемент с «opacity:.5;» (свойство значение не имеет). Вы выставили «transition:opacity .2s linear;» + событие «transitionend». Так вот, далее в CSS прописали, что при ":hover" над элементом у вас «opacity:.5;» должно перейти в «opacity:1;». Навели курсор на элемент и сработало событие «transitionend». Все нормально, все рады. Но! Если быстро отвести курсор от элемента и вновь навести, то значение свойства «opacity» может не успеть измениться и тогда событие «transitionend» не сработает. Вроде бы должно, но не срабатывает. Сложно сказать баг это, аль фича. Ответа на сей вопрос пока не нашел.
            Сам столкнулся с этой проблемой тогда, когда динамически создавал элемент посредством js с «opacity:0;» и сразу же анимировал его к «opacity:1;», но при определенных манипуляциях пользователя сей элемент должен был вновь перейти к состоянию «opacity:0;». Если это происходило, то элемент должен был удаляться по событию «transitionend». Так вот из-за этой фичи при быстрых манипуляциях пользователя событие «transitionend» не успевало, как часто пишут в англоязычных блогах, возгорать (значение свойства «opacity» не изменялось, то бишь оставалось равным «0») :)… И элемент не удалялся :(.
            • 0
              Вот, это более похоже на мой сценарий, только отличие в том, что hover-стилей через CSS не задается, и происходит не удаление элемента, а сброс внутреннего флага, запрещающего дальнейшие действия на время перехода. Нужно попробовать фишку из доклада, который порекомендовали Odnoklassniki_ru — вчера посмотрел. Там говорят, что нужно при прерывании перехода устанавливать текущее значение CSS-свойства и удалять свойство transition из style (я не удаляю, только устанавливаю transition-duration в 0s). Событие не отрабатывает, но этот момент мы знаем без события, поскольку мы его кодируем.
              • 0
                Доклад постараюсь посмотреть позже, быть может в понидельник, но сам вышел из сей ситуации след. способом. Значение свойства «opacity» у меня менялось тогда, когда я назначал, аль удалял стилевой класс «visible». Так вот в этот момент я и проверял, если «opacity» уже в состоянии «0», то анимация не сработает и нужно сразу же вызывать код удлаения, иначе переключать класс и ждать окончания события «transitionend», которое удалит нужный элемент.
  • +1
    Что-то мне подсказывает, что это не очень хорошая практика устанавливать «очень большую задержку», для того, чтобы оставить какое-то состояние навсегда. Хотя бы с точки зрения изящности кода, хотя тут скорее всего будет и лишняя нагрузка за счет таймеров.
    Можно же просто отключить анимацию по событию.

    А в целом молодцы)
    • 0
      Такой подход применяли в экспериментальных играх на CSS3, на обычной практике это регулируется добавлениями классов в динамике, так что у нас нигде нету таких вечных анимаций :)
  • 0
    Вами проводились какие-то тесты на сравнение загрузки процессора при выполнении CSS анимаций и их аналогов на js?
    Есть ли какие-то параметры анимации, заметно влияющие на производительность? Было бы любопытно взглянуть на результаты таких исследований.

    Вот, кстати, интересная статья (на английском, правда) о профайлинге CSS (про анимации, жаль, там почти ничего)
    • 0
      Пользы ради постараюсь ответить на ваш вопрос. Сам к представителям представленной соц. сети не являюсь. В общем сами анимации не несут какойбы-то не было существенной нагрузки, ибо была даже статья, где автор придумал интересный эффект. Он создал переход (transition) на 9999...9 секунд. Смысл был в том, что при наведении на ссылку зеленого цвета у нее менялся цвет на красный. Вернутся же обратно этот цвет должен был по окончанию действия таймера (аль во время его истекания, точно не помню). Т.к. таймер долен был работать нереально долго, то получалось так, что ссылка отсавалась красного цвета. Далее можно фантазировать куда угодно. Можно сделать табы на чистом CSS с запоминанием состояния и т.п. Автор сделал аля игршку с данным эфектом. Так вот. Сами таймеры много не кушают еще благадаря тому, что они синхронизируются друг с другом. Собственно из-за этого рекомендуется отвыкать в js от setTimeout'а, аль setInterval'а и привыкать к анимациям. Далее нагрузку создадут не анимации, а то, что они анимируют. К примеру, вы анимируете фильтр «blur». О да, это, пожалуй, если не самое тяжелое свойство в CSS, то одно из. Так вот расчеты на перерисовку сего свойства при каждой итерации анимации будут создавать нагрузку куда более существенную, чам сама анимация.
      Ну а сравнимать чисто CSS-анимации с JS-анимациями даже нет возможности, ибо анимации будут работать в каком-то контексте, который так же будет создавать нагрузку, а в целом что JS-requestAnimationFrame, что CSS-animation / CSS-transition, что SVG-SMIL… Быстро и дешево!
    • +1
      Сами мы пока тесты не проводили, но как минимум анимации будут производительней за счет GPU акселерации, что не только поможет разгрузить ваш CPU но и спасёт вашу батарейку на мобильных девайсах.

      Тут есть очень наглядный тест производительности CSS Анимаций против jQuery.
      • 0
        Так это и получается сравнение синего с апельсином, о которых я пытался написать чуть выше. Сам давно работал с jQuery, ибо не нравится мне сие, но раньше анимации там были на setTimeout, аль setInterval, точно уже не припомню. Так вот используя сие + еще куча всего от jQuery c инициализацией переменных и прочего выходит неплохая нагрузка, которая не имеет отношения к анимации. Интереса ради решил найти устройство текущей функции анимации в jQuery. Исходники было лень рассматривать, решил поискать в гугле готовую функцию. Но нашел вот эту статью. И первым же комментарием к ней: «When speaking of animations, what about supporting http://www.w3.org/TR/animation-timing/#requestAnimationFrame?». Один этот комментарий перечеркивает весь смысл текущего сравнения. SetTimeout / setInterval в JS даже работают совершенно по другому принципу и вполне логично, что это несравнимые вещи.
        … Отдаленно по теме. В IE вроде как продвигают штуку, под названием «setImmediate». Для сего выложили на своем Test Drive'е неплохую демку, показывающую какова разница между set'ами :). Собственно по демке видно, как печально дела обстоят с setTimeout / setInterval, о которых почти всегда говорят, когда речь заходит об анимации в JS (просто выбора раньше особого не было).
        В итоге и остается, что стилевые class'ы навешивать, да снимать посредством JS через classList, что вполне удобно и красиво.
        • 0
          Даже если сами по себе анимации равные по производительности, то факт GPU акселерации в CSS анимации все равно остается очень весомым, особенно в эру мобильных устройств.
          • 0
            Есть ли разница между JS-requestAnimationFrame / CSS-animation / CSS-transition / SVG-SMIL? И, если сие все же имеет место быть, существенна ли она? Просто, судя по многочисленным описаниям, это все одно и тоже (я не находил каких-то иных мнений / фактов). Тот же MS в своем IE решил от SMIL в пользу CSS-animation / CSS-transition отказаться. Как я понимаю сам принцип у всего этого один и тот же. Просто посредством JS-requestAnimationFrame можно еще и холст оживить, плавно прокручивать страницу и прочее.., что нельзя сделать посредством CSS.
            • 0
              Хм, ознакомился с requestAnimationFrame, интересная технология, думаю и в правду разницы с CSS анимациями разницы в производительности не будет.

              Ранее вы упомянули что сравнивать скорость анимаций CSS и на jQuery нету смысла, но я с вам не соглашусь, всё таки большинство веб разработчиков используют сейчас jQuery для анимаций, и врятли в ближ. время requestAnimationFrame переплюнет jQuery по популярности. CSS анимации имееют некие органичение, но они намного проще в применении.
              • 0
                Есть всяко-разно проекты, вроде такого (сам не пользовался сим). Костыли, ага, но jQuery, по сути своей, тоже костыль, правда с сахаром :). Ну а в целом да, jQuery пользуются и дошло до того, что ищешь ответ на какой-нибудь вопрос по JS, а везде вылезает этот самый jQuery со своими грязными хаками. В общем здесь каждый решает сам, что и как будет правильнее, да и обратная совместимость иной раз имеет место быть, в которой нет места красивым (я видел подобное решение на MDC, но как-то не нашел ссылки на него.., да и у MS как всегда все красочно с кучей боковок) решениям…
  • –1
    Что-то на самих ОК абсолютно нигде не замечаю никаких эффектов анимации. Chrome 24.
    • 0
      Интереса ради зашел на главную (далее не пошел, ибо не пользуюсь сим творением). Нажал CTRL+U (просмотреть исходный код). Далее CTRL+F (поиск на странице), нашел первое же вхождение CSS-файла (это оказался «core.css») и в нем оказалось куча свойств «transition» и ему подобных. Да и «animation» в нем же имеет место быть ;).
      • 0
        Нечего сдуру минусовать.
        Я не о коде, я о сервиси глазами пользователя. С ходу совсем нигде не видно анимации. Стоило бы написать, в каких именно местах она сейчас используется.
    • 0
      Сейчас уже практически все выпадающие меню анимированы, виджет-линк на галарею скинов, сама галерея скинов и пр.
      • 0
        На выпадающих меню заметил, если бы не заострил внимание на этом то как пользователь бы никогда не замечал это, то есть вообще абсолютно никак заметно на уровне пользовательских ощущениях или удовлетворённости.
        А вот что такое галлеря скинов не знаю и найти её не смог, гугл тоже молчит.
  • +2
    Как-то делал игру на CSS. Из опыта использования CSS-анимаций:

    — Работает реально плавнее, чем JS-анимация, ибо используется GPU.
    — Скейлинг работает быстро, но некачественно. Поскольку объект не перерисовывается, а скейлится только его отрендереный bitmap. Особенно заметно на шрифтах.
    — Какой-то браузер, кажется Safari Mobile, не использовал GPU, если анимировались свойства left и top. С трансформами все работало.
    — Transitions задаются на уровне элемента, а не на уровне свойств. Поэтому для одного элемента нельзя создавать различные независимые таймлайны для разных свойств. Как вариант врапать элемент несколькими div-ами, у каждого из которых менять только одно свойство.
    — Нет стандартного способа для callback-ов по завершению анимации. Transitionend в половине браузеров не работает. Приходится callback тупо вешать на таймер.
    — До сих пор нет массовой поддержки keyframe-анимации. Составные анимации приходится контролировать на JS.
    — Отсутствует path-анимация, которая есть в SVG. Также нет возможности задать свою функцию интерполяции. Поэтому невозможно задавать достаточно сложные траектории движения объекта.
    — На работе Chrome иногда выдает какие-то странные артефакты при перерисовке, либо вообще не работает. Скорей всего проблема в видеокарте/драйвере. С другой стороны, в Safari/Firefox работает хорошо.

    Вывод: для сложных игровых сцен CSS-анимация еще не готова. Везде приходится юзать JS. Для простых же эффектов на странице — это самое то.

    P.S. Был эксперимент как подружить CSS и JS анимацию. Фишка в том, что JS контролировал анимацию и просчитывал только ключевые фреймы с достаточно большим интервалом. А промежуточная интерполяция осуществлялась CSS. Но бросил раньше, чем удалось довести это до ума.
    • 0
      Забавно, сам работаю с CSS-анимациями и -переходами, но в контексте польовательских интерфейсов и браузера Firefox (для игр подобное, на мой взляд, не имеет смысла перед холстом). Так вот, многое, из того, что вы описали, быть может и было когда-то там в древние времена, но не сейчас. Вот к примеру, на уровне каких элементов задаются переходы? Вполне же можно задать одному элементу несколько переходов для разных свойств. Transitionend работает уже давно, кроме IE, в котором и переходы-то в новинку. Отсутствие path-анимаций, но это же не SVG, о которм вы написали. Пролемы с перерисовкой стречаются и в Firefox'е. keyframe-анимация есть уже везде (кроме старых браузеров). Про первые 3 пункта сложно что-то сказать, ибо скейлинг в Firefox'е и правду работает как-то неважно, но в Chrome вроде получше будет, про остальных не помню. Про GPU разговор чуть выше в комментариях идет (аль шел :) ).
      В общем где-то давненько я встречал упоминания о том, что на мобильных Safari нет ускорения Canvas'а, а CSS вполне себе работает шустро. Но верно ли использовать сие для всего подряд…
      • 0
        Холст я вообще считаю некоей искусственной подпоркой для внезапно открывшегося рынка. Мне это сильно напоминает возврат в 90-е годы, когда я писал подобные игрушки на турбо-паскале под ДОС. Все приходится делать вручную — крутить цикл, опрашивать ввод, организовывать объектный граф, вычислять дельты и перемещения, компоновать и рисовать, etc… Есть конечно фреймворки, упрощающие задачу. Но все-таки основная тенденция всегда была к декларативному описанию сцены, а не императивному. Канвас хорошо подходит для битблитовых динамичных игр. Я занимаюсь программированием настольных игр типа шахмат, карт и т.д. И на канвасе реализовывать драг-дроп или простую анимацию фигуры или падения карты весьма сложно по сравнению с транзишном.

        > Вполне же можно задать одному элементу несколько переходов для разных свойств.
        Можно-то оно можно, но синхронно для всех свойств. Нельзя одновременно задать, чтоб объект ехал вправо 2 секунды, а при этом вращался только одну. Вообще сложные транзишны без JS не сделать.

        > работает уже давно, кроме IE, в котором и переходы-то в новинку
        Тем не менее, программируя игру для масс, приходится равняться именно на IE9 (т.е. по худшему). Потому как пользователю абсолютно наплевать что и как там поддерживается в его браузере. Если он заходит на сайт и игра не работает, то он делает логичный вывод, что игра-дерьмо, а вовсе не его браузер ;)

        На фоне всех технологий очень понравился SVG. Несмотря на то, что он еще не очень приспособлен для динамики и сложных сцен, функционал достаточно широкий. Однако на данный момент аппаратное ускорение поддерживается, как ни странно, только IE 9. Плюс у андроида поддержка только от версии 3.0 (и то фиговенько). Так что пока CSS шустрее и «поддерживаемей». Но думаю, будущее именно за SVG.
        • 0
          Описанный вами пример вполне реален (пример для Firefox, тестировал в 19.0a1). Для чего-то сложного есть более сложные (ли?) keyframes'ы. Ну а далее, да, JS как универсальный инструмент.
          В IE9 вроде как и свойства transition нет.
          Ну а по остальному… SVG… Все готовится к выходу 2-я версия. Красиво, классно, но я не думаю, что мы увидим в скором времени быструю его реализацию, ибо в каких-то простых вещах он (быть может даже она :) ) вполне себе производителен, но не более того. Canvas, как по мне, так это что-то временное до тех пор, пока компьютеры не «научатся» быстро работать с вектором и тогда настанет блаженство. А пока я иных вариантов и не вижу. Canvas, да и только.., разве что найти ему замену там, где он не ускоряется аппаратно, аль возможностей SVG хватает (да еще и масштабируемость нужна).
          P.S. Кстати, о drag and drop'е. Он-то и в текущей реализации браузеров как-то криво себя ведет. При перетаскивании отключается скроллинг и прочие причуды. В итоге все по старинке, с использованием mouseup, mousedown и прочих костылей :).
  • –2
    Вот если бы убрать раздражающий оранжевый и название… ах да, точно.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка