1. Скрины статичны, а transition отвечает за «плавность перехода», задавая время совершения перехода, временную функцию и свойство CSS (либо all по умолчанию). Проще говоря, тултипы должны не просто появляться, а делать это плавно. Если вы знаете, что делает transition, то я извиняюсь, но вы показывате работу анимации с помощью статичных изображений, а это может говорить о том, что не знаете.
2. Пример с сайта W3 Schools тут не при чем, transition не работает в Chrome для псевдо-элементов (в случае hint.css это ::after и ::before), а на W3 Schools transition применяется для обычного элемента.
Зачем, сравнивая себя со статистикой, затем приводить свой частный случай как пример, ей не соответствующий? А иногда еще добавляют «и мои друзья тоже».
Зависит от контекста. Если выпадающее меню будет выпадать слишком долго, то зло, а если подсветка кнопки будет плавной, то почему нет? В общем надо учитывать зависимость функционала от анимации.
Спасибо автору за статью, очень полезно. Не так давно начал пользоваться Office for Mac и волновала проблема совместимости с Windows, начитавшись интернетов, думал работать придется в Windows, но нет, вы меня успокоили)
Теперь действительно хорошие разработчики и дизайнеры могут делать progressive enhancement, а плохие не могут, так как это сложнее и трудозатратнее.
Здесь с автором не соглашусь в плане «сложнее и трудозатратнее». Писать сначала разметку, потом добавлять оформление и поведение — на мой взгляд, это не сложнее. И более того — приятнее, мне лично доставляет удовольствие размечать документ чистым HTML, думать как поддержать семантику документа, какой тег уместнее и т. д. Если какой-то верстальщик не любит этого делать, то у меня для него плохие новости. В итоге же прогрессивное улучшение не трудозатратнее, ведь пытаясь соблюсти принципы изящной деградации, вы в принципе делаете то же самое — обеспечиваете функциональность в старых браузерах. Я бы даже сказал, что оба подхода в идеале суть одно и то же, разница в том, когда вы начинаете думать о том, как это будет выглядеть в IE6 или на старом телефоне, — сразу или после того, как напишете CSS3 и JS.
Я бы вообще не стал так себя утраждать объяснениями. Если кто-то думает стереотипами, значит этому человеку большего не надо, в таком случае, зачем все эти лекции?
А кто мешал сделать (точнее просто выбрать готовое) архитектуру, которая позволила бы писать так же легко через неделю? Или у вас проблема с в общем-то ужасным API canvas?
Есть на что переключиться.
2. Пример с сайта W3 Schools тут не при чем, transition не работает в Chrome для псевдо-элементов (в случае hint.css это ::after и ::before), а на W3 Schools transition применяется для обычного элемента.
css-tricks.com/transitions-and-animations-on-css-generated-content
Ни в Windows, ни в OS X у меня не работает transition для псевод-элементов.
Добавлю, что PHPStorm включает в себя весь функционал Webstorm, т. е. это не только PHP:
Здесь с автором не соглашусь в плане «сложнее и трудозатратнее». Писать сначала разметку, потом добавлять оформление и поведение — на мой взгляд, это не сложнее. И более того — приятнее, мне лично доставляет удовольствие размечать документ чистым HTML, думать как поддержать семантику документа, какой тег уместнее и т. д. Если какой-то верстальщик не любит этого делать, то у меня для него плохие новости. В итоге же прогрессивное улучшение не трудозатратнее, ведь пытаясь соблюсти принципы изящной деградации, вы в принципе делаете то же самое — обеспечиваете функциональность в старых браузерах. Я бы даже сказал, что оба подхода в идеале суть одно и то же, разница в том, когда вы начинаете думать о том, как это будет выглядеть в IE6 или на старом телефоне, — сразу или после того, как напишете CSS3 и JS.
Насчет поля «личностные качества», по-моему лишнее.
Теперь понятно, как появился планкинг.
:)
Хотелось бы узнать почему.