Да ладно? Уже не раз обсуждалось сие на хабре. Firefox вполне поддерживает анимацию псевдо элементов (кстати, правильнее с двумя "::" писать), а у Chrome'а уже тона прошений пользователей к разработчикам, чтобы решили сей вопрос…
На самом деле решение далеко не новое и это не решение проблемы, а костыль, ибо вместо анимирования за n времени у вас получается анимирование с n скоростью, да и свойство «min-*» в большинстве подобных случаях подбирается на глаз и вполне себе не резиновое, что опровергает заголовок статьи (произвольной ширины...) :).
Проблема проверить? Собственно, что и следовало ужидать. Все работает, как и описано в статье, ибо пока Firefox не понимает свойства filter со значением не из SVG, он его и не применит. В этом и смысл всего кода.
Так баг должны будут в 18-ой версии браузера закрыть (если не ошибаюсь). Там примеров куча и в ночных версиях и им подобных все смотрится вполне красиво.
Группы вкладок / присутствие в Firefox различных фишек в CSS, которых нет в Chrome / Firebug (хоть с каждым релизом и нативные средства разработки становятся все лучше) / Дополнения, список которых формировался несколько лет…
Так можно долго перечеслять список, вот только все тоже самое с небольшой правкой можно сказать и в обратную сторону. А по большому счету в чем лучше Chrome? Просто это было нечто новое и люди пересели на него. ИМХО, не более того.
Описанный вами пример вполне реален (пример для Firefox, тестировал в 19.0a1). Для чего-то сложного есть более сложные (ли?) keyframes'ы. Ну а далее, да, JS как универсальный инструмент.
В IE9 вроде как и свойства transition нет.
Ну а по остальному… SVG… Все готовится к выходу 2-я версия. Красиво, классно, но я не думаю, что мы увидим в скором времени быструю его реализацию, ибо в каких-то простых вещах он (быть может даже она :) ) вполне себе производителен, но не более того. Canvas, как по мне, так это что-то временное до тех пор, пока компьютеры не «научатся» быстро работать с вектором и тогда настанет блаженство. А пока я иных вариантов и не вижу. Canvas, да и только.., разве что найти ему замену там, где он не ускоряется аппаратно, аль возможностей SVG хватает (да еще и масштабируемость нужна).
P.S. Кстати, о drag and drop'е. Он-то и в текущей реализации браузеров как-то криво себя ведет. При перетаскивании отключается скроллинг и прочие причуды. В итоге все по старинке, с использованием mouseup, mousedown и прочих костылей :).
Есть всяко-разно проекты, вроде такого (сам не пользовался сим). Костыли, ага, но jQuery, по сути своей, тоже костыль, правда с сахаром :). Ну а в целом да, jQuery пользуются и дошло до того, что ищешь ответ на какой-нибудь вопрос по JS, а везде вылезает этот самый jQuery со своими грязными хаками. В общем здесь каждый решает сам, что и как будет правильнее, да и обратная совместимость иной раз имеет место быть, в которой нет места красивым (я видел подобное решение на MDC, но как-то не нашел ссылки на него.., да и у MS как всегда все красочно с кучей боковок) решениям…
Доклад постараюсь посмотреть позже, быть может в понидельник, но сам вышел из сей ситуации след. способом. Значение свойства «opacity» у меня менялось тогда, когда я назначал, аль удалял стилевой класс «visible». Так вот в этот момент я и проверял, если «opacity» уже в состоянии «0», то анимация не сработает и нужно сразу же вызывать код удлаения, иначе переключать класс и ждать окончания события «transitionend», которое удалит нужный элемент.
Забавно, сам работаю с CSS-анимациями и -переходами, но в контексте польовательских интерфейсов и браузера Firefox (для игр подобное, на мой взляд, не имеет смысла перед холстом). Так вот, многое, из того, что вы описали, быть может и было когда-то там в древние времена, но не сейчас. Вот к примеру, на уровне каких элементов задаются переходы? Вполне же можно задать одному элементу несколько переходов для разных свойств. Transitionend работает уже давно, кроме IE, в котором и переходы-то в новинку. Отсутствие path-анимаций, но это же не SVG, о которм вы написали. Пролемы с перерисовкой стречаются и в Firefox'е. keyframe-анимация есть уже везде (кроме старых браузеров). Про первые 3 пункта сложно что-то сказать, ибо скейлинг в Firefox'е и правду работает как-то неважно, но в Chrome вроде получше будет, про остальных не помню. Про GPU разговор чуть выше в комментариях идет (аль шел :) ).
В общем где-то давненько я встречал упоминания о том, что на мобильных Safari нет ускорения Canvas'а, а CSS вполне себе работает шустро. Но верно ли использовать сие для всего подряд…
Есть ли разница между JS-requestAnimationFrame / CSS-animation / CSS-transition / SVG-SMIL? И, если сие все же имеет место быть, существенна ли она? Просто, судя по многочисленным описаниям, это все одно и тоже (я не находил каких-то иных мнений / фактов). Тот же MS в своем IE решил от SMIL в пользу CSS-animation / CSS-transition отказаться. Как я понимаю сам принцип у всего этого один и тот же. Просто посредством JS-requestAnimationFrame можно еще и холст оживить, плавно прокручивать страницу и прочее.., что нельзя сделать посредством CSS.
Есть еще одна фича касательно 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») :)… И элемент не удалялся :(.
Так это и получается сравнение синего с апельсином, о которых я пытался написать чуть выше. Сам давно работал с 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, что вполне удобно и красиво.
Зато в демке «Technical skill»:
CSS3 — 80%;
Photoshop — 90%;
Corel Draw — 90%.
Видать с «imagination» процентов не добрали :).
Так можно долго перечеслять список, вот только все тоже самое с небольшой правкой можно сказать и в обратную сторону. А по большому счету в чем лучше Chrome? Просто это было нечто новое и люди пересели на него. ИМХО, не более того.
В IE9 вроде как и свойства transition нет.
Ну а по остальному… SVG… Все готовится к выходу 2-я версия. Красиво, классно, но я не думаю, что мы увидим в скором времени быструю его реализацию, ибо в каких-то простых вещах он (быть может даже она :) ) вполне себе производителен, но не более того. Canvas, как по мне, так это что-то временное до тех пор, пока компьютеры не «научатся» быстро работать с вектором и тогда настанет блаженство. А пока я иных вариантов и не вижу. Canvas, да и только.., разве что найти ему замену там, где он не ускоряется аппаратно, аль возможностей SVG хватает (да еще и масштабируемость нужна).
P.S. Кстати, о drag and drop'е. Он-то и в текущей реализации браузеров как-то криво себя ведет. При перетаскивании отключается скроллинг и прочие причуды. В итоге все по старинке, с использованием mouseup, mousedown и прочих костылей :).
В общем где-то давненько я встречал упоминания о том, что на мобильных Safari нет ускорения Canvas'а, а CSS вполне себе работает шустро. Но верно ли использовать сие для всего подряд…
Сам столкнулся с этой проблемой тогда, когда динамически создавал элемент посредством js с «opacity:0;» и сразу же анимировал его к «opacity:1;», но при определенных манипуляциях пользователя сей элемент должен был вновь перейти к состоянию «opacity:0;». Если это происходило, то элемент должен был удаляться по событию «transitionend». Так вот из-за этой фичи при быстрых манипуляциях пользователя событие «transitionend» не успевало, как часто пишут в англоязычных блогах, возгорать (значение свойства «opacity» не изменялось, то бишь оставалось равным «0») :)… И элемент не удалялся :(.
… Отдаленно по теме. В IE вроде как продвигают штуку, под названием «setImmediate». Для сего выложили на своем Test Drive'е неплохую демку, показывающую какова разница между set'ами :). Собственно по демке видно, как печально дела обстоят с setTimeout / setInterval, о которых почти всегда говорят, когда речь заходит об анимации в JS (просто выбора раньше особого не было).
В итоге и остается, что стилевые class'ы навешивать, да снимать посредством JS через classList, что вполне удобно и красиво.