Comments 66
А вы молодцы. Самому часто приходится отказываться от стандартов css3 для интеграции со старыми версиями браузеров. Спасибо за статью!
Не нужно бояться за старые браузеры, контент от этого не пострадает, а красивый и понятный интерфейс увидят уже 65%+ пользователей (по статистике Stat Counter).
UFO just landed and posted this here
О поддержки браузеров:
caniuse.com/css-animation
caniuse.com/css-transitions
caniuse.com/transforms2d
caniuse.com/css-animation
caniuse.com/css-transitions
caniuse.com/transforms2d
Зачем пользователю ждать долгую анимацию? Вообще, всё, что дольше 0.7 секуды — зло.
Можно вполне ограничиваться этими рамками, и делать быстрые анимации.
UFO just landed and posted this here
Можно реализовать наример ajax loader — анимация будет отображаться до тех пор пока не загрузится контент (а на мобильных девайсах при плохом покрытии может долго) и тут уже спорно не слишком ли быстро будет крутиться полосочка или кружечек.
Скорость-то будет одинаковая. Просто где-то имеет смысл зациклить анимацию на бесконечность.
Накидал пример jsfiddle.net/QDvU7/2/, вроде бы 0.7s норм, хотя мозг все равно думает, что могут быть случаи когда лучше подольше.
UFO just landed and posted this here
C prefix-free — jsfiddle.net/QDvU7/4/
Там опечтка, в вебките 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);
}
Это нюанс немного другого рода. Я имел в виду анимацию, как на гифке вверху поста: где выезжает пункт меню.
Зависит от контекста. Если выпадающее меню будет выпадать слишком долго, то зло, а если подсветка кнопки будет плавной, то почему нет? В общем надо учитывать зависимость функционала от анимации.
Пример с GIF'кой как раз такой, что создает страные впечатления. Т.е. пока кружок отодвигается, то под ним начинает проявляться блок. Можно же было сделать как-то поинтереснее. Пример. На все про все 5 минут. У анимаций есть еще и куча проблем, то бишь нельзя анимировать к значению auto (из-за этого в примере использовал костыль с max-width), аль к проприетарному свойству "-moz-max-content" и аналогам, да еще и с определенной скоростью, то бишь разворачивать список со скоростью 10px в пол секунды и т.п. Пока что нелья анимировать градиенты и некоторые иные свойства. Но использовать в разумных пределах вполне возможно. Да и со всякими ссылками по «событию» :hover уже вполне практикуется.
И, да, извечный баг webkit'а с неанимированием псевдо-элементов. Когда же они его исправят?..
UFO just landed and posted this here
У Ромы Комарова есть идеи на этот счет, ему удалось заанимировать псевдоэлемент.
Я уже высказывался на сей счет. И что мнение мое, что баг в webkit'ах… Стабильность, мать ее…
Такое поведение было задумано дизайнерами, с технической точки зрения было интересней делать как раз с запоздалым появлением серого блока. К сожалению ваш пример не работает в Safari 6, только в Chrome.
Переход (transition) может происходить только из 1 конкретного значения, в другое. Это скорей не проблема анимаций, а ограничения, которые, скорей всего, связаны с производительностью.
Мы призываем сообщество обратить внимание на возможности CSS анимаций, ведь это не просто красивые эффекты на ховер. Они позволяют делать кучу всего интересного, только немного по другому, в сравнении, с теми же jQuery анимациями. Новизна технологии пугает разработчиков, все пока еще делают «как привычней».
Переход (transition) может происходить только из 1 конкретного значения, в другое. Это скорей не проблема анимаций, а ограничения, которые, скорей всего, связаны с производительностью.
Мы призываем сообщество обратить внимание на возможности CSS анимаций, ведь это не просто красивые эффекты на ховер. Они позволяют делать кучу всего интересного, только немного по другому, в сравнении, с теми же jQuery анимациями. Новизна технологии пугает разработчиков, все пока еще делают «как привычней».
Если так было задумано, то да, быть может… Ну а по остальному можно тоже самое сказать про любое свойство CSS, аль селектор, аль что-то из HTML5. Да про что угодно. Если нет желания развиваться у разработчика / верстальщика / простого человек, то и на выходе не будет творчества. Я не против подобных статей, скорее всего они кого-то и подстегнут к обучнию прекрасному, но желание должно исходить не от обущающего, а от обучаемого. Анимациям и переходам уже далеко не первый день…
Расскажите, работаете ли вы с CSS transitions из JavaScript? Если да, то не сталкивались ли с тем, что события ontransitionend в Firefox срабатывают только несколько раз, а потом перестают? Другие браузеры отрабатывают каждое завершение. Все значения свойств для перехода задаются через element.style с префиксами. Переход только по opacity. Может, кто-то еще сталкивался, или есть ссылки, где почитать, как исправить или обойти.
У нас пока не возникало необходимости работать с CSS transitions из JavaScript, но можем посоветовать ознакомится с докладом по этой теме, с недавно прошедшей конференции Fronteers.
Решил ответить сразу в 2 комментария, ибо, быть может, вам это тоже будет интересно. В общем, со случаем несрабатывания событий по положению звезд на небе, аль еще кокому-то незадокументированному действу я не сталкивался (примерчик бы...), но сталкивался с другим багом, из-за которого событие «transitionend» (правильно без «on») не срабатывает на фоновых вкладках. + сталкивался с фичей, из-за которой сей код не сработает как ожидается. Но это можно решить вот так. Забавно, но на сей вариант я вышел опытным путем (как бы странно это не звучало и, да, еще можно решить сей вопрос с setTimeout'ом). Тем не менее позднее, роясь в дебрях спецификаций и иже с ними я наткнулся на http://lists.w3.org/Archives/Public/www-style/2011Mar/0729.html.
И, да, это только касаясь Firefox'а (актуально вполть до 19.0a1), хоть это еще не все его баги… Чем дольше капаешься в каких-то свойствах, тем больше багов отлавливаешь :).
И, да, это только касаясь Firefox'а (актуально вполть до 19.0a1), хоть это еще не все его баги… Чем дольше капаешься в каких-то свойствах, тем больше багов отлавливаешь :).
+, тематическая ссылка в подарок :).
Да, transitionend. У меня в коде событие правильное, поскольку несколько раз оно срабатывает, а потом перестает. Причем вкладка при этом не переключается. Пример, оторванный от контекста, типа jsfiddle, пока нет времени сделать, прошу прощения за телепатию. Но если кто сталкивался с таким поведением в принципе, независимо от конкретного случая, опыт будет полезным. Спасибо за ссылки, посмотрю в ближайшее время.
Есть еще одна фича касательно 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») :)… И элемент не удалялся :(.
Сам столкнулся с этой проблемой тогда, когда динамически создавал элемент посредством js с «opacity:0;» и сразу же анимировал его к «opacity:1;», но при определенных манипуляциях пользователя сей элемент должен был вновь перейти к состоянию «opacity:0;». Если это происходило, то элемент должен был удаляться по событию «transitionend». Так вот из-за этой фичи при быстрых манипуляциях пользователя событие «transitionend» не успевало, как часто пишут в англоязычных блогах, возгорать (значение свойства «opacity» не изменялось, то бишь оставалось равным «0») :)… И элемент не удалялся :(.
Вот, это более похоже на мой сценарий, только отличие в том, что hover-стилей через CSS не задается, и происходит не удаление элемента, а сброс внутреннего флага, запрещающего дальнейшие действия на время перехода. Нужно попробовать фишку из доклада, который порекомендовали Odnoklassniki_ru — вчера посмотрел. Там говорят, что нужно при прерывании перехода устанавливать текущее значение CSS-свойства и удалять свойство transition из style (я не удаляю, только устанавливаю transition-duration в 0s). Событие не отрабатывает, но этот момент мы знаем без события, поскольку мы его кодируем.
Доклад постараюсь посмотреть позже, быть может в понидельник, но сам вышел из сей ситуации след. способом. Значение свойства «opacity» у меня менялось тогда, когда я назначал, аль удалял стилевой класс «visible». Так вот в этот момент я и проверял, если «opacity» уже в состоянии «0», то анимация не сработает и нужно сразу же вызывать код удлаения, иначе переключать класс и ждать окончания события «transitionend», которое удалит нужный элемент.
Что-то мне подсказывает, что это не очень хорошая практика устанавливать «очень большую задержку», для того, чтобы оставить какое-то состояние навсегда. Хотя бы с точки зрения изящности кода, хотя тут скорее всего будет и лишняя нагрузка за счет таймеров.
Можно же просто отключить анимацию по событию.
А в целом молодцы)
Можно же просто отключить анимацию по событию.
А в целом молодцы)
Вами проводились какие-то тесты на сравнение загрузки процессора при выполнении CSS анимаций и их аналогов на js?
Есть ли какие-то параметры анимации, заметно влияющие на производительность? Было бы любопытно взглянуть на результаты таких исследований.
Вот, кстати, интересная статья (на английском, правда) о профайлинге CSS (про анимации, жаль, там почти ничего)
Есть ли какие-то параметры анимации, заметно влияющие на производительность? Было бы любопытно взглянуть на результаты таких исследований.
Вот, кстати, интересная статья (на английском, правда) о профайлинге CSS (про анимации, жаль, там почти ничего)
Пользы ради постараюсь ответить на ваш вопрос. Сам к представителям представленной соц. сети не являюсь. В общем сами анимации не несут какойбы-то не было существенной нагрузки, ибо была даже статья, где автор придумал интересный эффект. Он создал переход (transition) на 9999...9 секунд. Смысл был в том, что при наведении на ссылку зеленого цвета у нее менялся цвет на красный. Вернутся же обратно этот цвет должен был по окончанию действия таймера (аль во время его истекания, точно не помню). Т.к. таймер долен был работать нереально долго, то получалось так, что ссылка отсавалась красного цвета. Далее можно фантазировать куда угодно. Можно сделать табы на чистом CSS с запоминанием состояния и т.п. Автор сделал аля игршку с данным эфектом. Так вот. Сами таймеры много не кушают еще благадаря тому, что они синхронизируются друг с другом. Собственно из-за этого рекомендуется отвыкать в js от setTimeout'а, аль setInterval'а и привыкать к анимациям. Далее нагрузку создадут не анимации, а то, что они анимируют. К примеру, вы анимируете фильтр «blur». О да, это, пожалуй, если не самое тяжелое свойство в CSS, то одно из. Так вот расчеты на перерисовку сего свойства при каждой итерации анимации будут создавать нагрузку куда более существенную, чам сама анимация.
Ну а сравнимать чисто CSS-анимации с JS-анимациями даже нет возможности, ибо анимации будут работать в каком-то контексте, который так же будет создавать нагрузку, а в целом что JS-requestAnimationFrame, что CSS-animation / CSS-transition, что SVG-SMIL… Быстро и дешево!
Ну а сравнимать чисто CSS-анимации с JS-анимациями даже нет возможности, ибо анимации будут работать в каком-то контексте, который так же будет создавать нагрузку, а в целом что JS-requestAnimationFrame, что CSS-animation / CSS-transition, что SVG-SMIL… Быстро и дешево!
Сами мы пока тесты не проводили, но как минимум анимации будут производительней за счет GPU акселерации, что не только поможет разгрузить ваш CPU но и спасёт вашу батарейку на мобильных девайсах.
Тут есть очень наглядный тест производительности CSS Анимаций против jQuery.
Тут есть очень наглядный тест производительности CSS Анимаций против jQuery.
Так это и получается сравнение синего с апельсином, о которых я пытался написать чуть выше. Сам давно работал с 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, что вполне удобно и красиво.
… Отдаленно по теме. В IE вроде как продвигают штуку, под названием «setImmediate». Для сего выложили на своем Test Drive'е неплохую демку, показывающую какова разница между set'ами :). Собственно по демке видно, как печально дела обстоят с setTimeout / setInterval, о которых почти всегда говорят, когда речь заходит об анимации в JS (просто выбора раньше особого не было).
В итоге и остается, что стилевые class'ы навешивать, да снимать посредством JS через classList, что вполне удобно и красиво.
Даже если сами по себе анимации равные по производительности, то факт GPU акселерации в CSS анимации все равно остается очень весомым, особенно в эру мобильных устройств.
Есть ли разница между JS-requestAnimationFrame / CSS-animation / CSS-transition / SVG-SMIL? И, если сие все же имеет место быть, существенна ли она? Просто, судя по многочисленным описаниям, это все одно и тоже (я не находил каких-то иных мнений / фактов). Тот же MS в своем IE решил от SMIL в пользу CSS-animation / CSS-transition отказаться. Как я понимаю сам принцип у всего этого один и тот же. Просто посредством JS-requestAnimationFrame можно еще и холст оживить, плавно прокручивать страницу и прочее.., что нельзя сделать посредством CSS.
Хм, ознакомился с requestAnimationFrame, интересная технология, думаю и в правду разницы с CSS анимациями разницы в производительности не будет.
Ранее вы упомянули что сравнивать скорость анимаций CSS и на jQuery нету смысла, но я с вам не соглашусь, всё таки большинство веб разработчиков используют сейчас jQuery для анимаций, и врятли в ближ. время requestAnimationFrame переплюнет jQuery по популярности. CSS анимации имееют некие органичение, но они намного проще в применении.
Ранее вы упомянули что сравнивать скорость анимаций CSS и на jQuery нету смысла, но я с вам не соглашусь, всё таки большинство веб разработчиков используют сейчас jQuery для анимаций, и врятли в ближ. время requestAnimationFrame переплюнет jQuery по популярности. CSS анимации имееют некие органичение, но они намного проще в применении.
Есть всяко-разно проекты, вроде такого (сам не пользовался сим). Костыли, ага, но jQuery, по сути своей, тоже костыль, правда с сахаром :). Ну а в целом да, jQuery пользуются и дошло до того, что ищешь ответ на какой-нибудь вопрос по JS, а везде вылезает этот самый jQuery со своими грязными хаками. В общем здесь каждый решает сам, что и как будет правильнее, да и обратная совместимость иной раз имеет место быть, в которой нет места красивым (я видел подобное решение на MDC, но как-то не нашел ссылки на него.., да и у MS как всегда все красочно с кучей боковок) решениям…
Что-то на самих ОК абсолютно нигде не замечаю никаких эффектов анимации. Chrome 24.
Интереса ради зашел на главную (далее не пошел, ибо не пользуюсь сим творением). Нажал CTRL+U (просмотреть исходный код). Далее CTRL+F (поиск на странице), нашел первое же вхождение CSS-файла (это оказался «core.css») и в нем оказалось куча свойств «transition» и ему подобных. Да и «animation» в нем же имеет место быть ;).
Сейчас уже практически все выпадающие меню анимированы, виджет-линк на галарею скинов, сама галерея скинов и пр.
Как-то делал игру на 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. Но бросил раньше, чем удалось довести это до ума.
— Работает реально плавнее, чем 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. Но бросил раньше, чем удалось довести это до ума.
Забавно, сам работаю с CSS-анимациями и -переходами, но в контексте польовательских интерфейсов и браузера Firefox (для игр подобное, на мой взляд, не имеет смысла перед холстом). Так вот, многое, из того, что вы описали, быть может и было когда-то там в древние времена, но не сейчас. Вот к примеру, на уровне каких элементов задаются переходы? Вполне же можно задать одному элементу несколько переходов для разных свойств. Transitionend работает уже давно, кроме IE, в котором и переходы-то в новинку. Отсутствие path-анимаций, но это же не SVG, о которм вы написали. Пролемы с перерисовкой стречаются и в Firefox'е. keyframe-анимация есть уже везде (кроме старых браузеров). Про первые 3 пункта сложно что-то сказать, ибо скейлинг в Firefox'е и правду работает как-то неважно, но в Chrome вроде получше будет, про остальных не помню. Про GPU разговор чуть выше в комментариях идет (аль шел :) ).
В общем где-то давненько я встречал упоминания о том, что на мобильных Safari нет ускорения Canvas'а, а CSS вполне себе работает шустро. Но верно ли использовать сие для всего подряд…
В общем где-то давненько я встречал упоминания о том, что на мобильных Safari нет ускорения Canvas'а, а CSS вполне себе работает шустро. Но верно ли использовать сие для всего подряд…
Холст я вообще считаю некоей искусственной подпоркой для внезапно открывшегося рынка. Мне это сильно напоминает возврат в 90-е годы, когда я писал подобные игрушки на турбо-паскале под ДОС. Все приходится делать вручную — крутить цикл, опрашивать ввод, организовывать объектный граф, вычислять дельты и перемещения, компоновать и рисовать, etc… Есть конечно фреймворки, упрощающие задачу. Но все-таки основная тенденция всегда была к декларативному описанию сцены, а не императивному. Канвас хорошо подходит для битблитовых динамичных игр. Я занимаюсь программированием настольных игр типа шахмат, карт и т.д. И на канвасе реализовывать драг-дроп или простую анимацию фигуры или падения карты весьма сложно по сравнению с транзишном.
> Вполне же можно задать одному элементу несколько переходов для разных свойств.
Можно-то оно можно, но синхронно для всех свойств. Нельзя одновременно задать, чтоб объект ехал вправо 2 секунды, а при этом вращался только одну. Вообще сложные транзишны без JS не сделать.
> работает уже давно, кроме IE, в котором и переходы-то в новинку
Тем не менее, программируя игру для масс, приходится равняться именно на IE9 (т.е. по худшему). Потому как пользователю абсолютно наплевать что и как там поддерживается в его браузере. Если он заходит на сайт и игра не работает, то он делает логичный вывод, что игра-дерьмо, а вовсе не его браузер ;)
На фоне всех технологий очень понравился SVG. Несмотря на то, что он еще не очень приспособлен для динамики и сложных сцен, функционал достаточно широкий. Однако на данный момент аппаратное ускорение поддерживается, как ни странно, только IE 9. Плюс у андроида поддержка только от версии 3.0 (и то фиговенько). Так что пока CSS шустрее и «поддерживаемей». Но думаю, будущее именно за SVG.
> Вполне же можно задать одному элементу несколько переходов для разных свойств.
Можно-то оно можно, но синхронно для всех свойств. Нельзя одновременно задать, чтоб объект ехал вправо 2 секунды, а при этом вращался только одну. Вообще сложные транзишны без JS не сделать.
> работает уже давно, кроме IE, в котором и переходы-то в новинку
Тем не менее, программируя игру для масс, приходится равняться именно на IE9 (т.е. по худшему). Потому как пользователю абсолютно наплевать что и как там поддерживается в его браузере. Если он заходит на сайт и игра не работает, то он делает логичный вывод, что игра-дерьмо, а вовсе не его браузер ;)
На фоне всех технологий очень понравился SVG. Несмотря на то, что он еще не очень приспособлен для динамики и сложных сцен, функционал достаточно широкий. Однако на данный момент аппаратное ускорение поддерживается, как ни странно, только IE 9. Плюс у андроида поддержка только от версии 3.0 (и то фиговенько). Так что пока CSS шустрее и «поддерживаемей». Но думаю, будущее именно за SVG.
Описанный вами пример вполне реален (пример для Firefox, тестировал в 19.0a1). Для чего-то сложного есть более сложные (ли?) keyframes'ы. Ну а далее, да, JS как универсальный инструмент.
В IE9 вроде как и свойства transition нет.
Ну а по остальному… SVG… Все готовится к выходу 2-я версия. Красиво, классно, но я не думаю, что мы увидим в скором времени быструю его реализацию, ибо в каких-то простых вещах он (быть может даже она :) ) вполне себе производителен, но не более того. Canvas, как по мне, так это что-то временное до тех пор, пока компьютеры не «научатся» быстро работать с вектором и тогда настанет блаженство. А пока я иных вариантов и не вижу. Canvas, да и только.., разве что найти ему замену там, где он не ускоряется аппаратно, аль возможностей SVG хватает (да еще и масштабируемость нужна).
P.S. Кстати, о drag and drop'е. Он-то и в текущей реализации браузеров как-то криво себя ведет. При перетаскивании отключается скроллинг и прочие причуды. В итоге все по старинке, с использованием mouseup, mousedown и прочих костылей :).
В IE9 вроде как и свойства transition нет.
Ну а по остальному… SVG… Все готовится к выходу 2-я версия. Красиво, классно, но я не думаю, что мы увидим в скором времени быструю его реализацию, ибо в каких-то простых вещах он (быть может даже она :) ) вполне себе производителен, но не более того. Canvas, как по мне, так это что-то временное до тех пор, пока компьютеры не «научатся» быстро работать с вектором и тогда настанет блаженство. А пока я иных вариантов и не вижу. Canvas, да и только.., разве что найти ему замену там, где он не ускоряется аппаратно, аль возможностей SVG хватает (да еще и масштабируемость нужна).
P.S. Кстати, о drag and drop'е. Он-то и в текущей реализации браузеров как-то криво себя ведет. При перетаскивании отключается скроллинг и прочие причуды. В итоге все по старинке, с использованием mouseup, mousedown и прочих костылей :).
UFO just landed and posted this here
Sign up to leave a comment.
CSS анимации на реальном проекте