SelenIT

Насколько я в курсе, да.

Для табличных элементов при необходимости создаются анонимные обертки, нужные по структуре. Например, рядом с table-row могут быть только другие table-row, поэтому если там затесалась "голая" table-cell, рендерер всё равно оборачивает ее в анонимный table-row.

Абсолютно верно. И в данном простом случае это может быть решением.

Инлайн-блоки (как и инлайн-таблицы и просто инлайны) живут в инлайновом контексте, в котором пробелы в коде значимы и интерпретируются как пробелы между словами. Это не баг, это фича. Если не хочется зависеть от форматирования кода и некрасивых хаков, лучше воспользоваться другими техниками (float, flexbox и т.п.)

Чаще всего абсолютное позиционирование и выручает. Кстати, без псевдиков действительно можно обойтись (только размеры padding-ов придется отсчитывать от внешнего контейнера, а не самого блока). А в чем проблема с галереей (особ. при условии, что превьюшки уже имеют нужные пропорции)?

Пожалуй, что так. У тени и возможностей больше.

отсюда

В Firefox с outline были и похуже проблемы. Долгое время она не учитывала трансформации (обводила прямоугольником трансформнутый элемент по визуальным габаритам), сейчас трансформируется, но с каждой трансформацией раздувается (только в 30-й версии, судя по всему, починили окончательно). Зато в нек-рых др. браузерах с помощью outline давно можно превращать целую страницу в негатив Вообще, по сабжу, главное различие — border является частью боксовой («блочной») модели элемента, outline не является. Соответственно, нет гарантий, что outline будет неотрывно следовать за элементом в любых его приключениях, и критичных элементов оформления лучше на нее не завязывать. Всё-таки ее основная задача — динамическое выделение элемента при его активации для какого-то действия (например, печально знаменитая пунктирная рамка ссылок и кнопок при фокусе ), для этой цели, сугубо имхо, лучше ее и оставить.

В принципе, в IE5.5-8 есть Matrix filter, который позволяет худо-бедно реализовать все 2D-трансформации. Но кого сегодня интересуют проблемы динозавров? Текст читается — и ладно!

Еще можно использовать единицу vw, если матрица браузеров (IE9+) позволяет.

Вообще говоря, overflow:hidden не должен обрезать абсолютно позиционированных потомков, если только элемент с ним сам не является позиционированным (абсолютно или относительно). Так что может быть достаточно превратить контейнер с overflow:hidden; position:relative в два вложенных контейнера, где overflow задано внутреннему, а position — внешнему. Но это уже не так очевидно, так что с таким подходом нужна осторожность

Что это значит?Это просьба дать ссылку (link) на проблемную страницу. Потому что необходимость подключать для ответа модуль телепатии снижает точность и эффективность отладки на порядки.

12. Бредятина в User-agent введена исключительно для того, чтобы старые скрипты, проверяющие версию браузера по первой цифре, не спотыкались об единицу. Вообще в User-agent'ы исторически чего только не пихают...

Как вариант, рисунок «вихрей» сделать картинкой, а затемнение к краям — через внутренний box-shadow. Хотя, наверное, это лишнее

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

При использовании gzip-сжатия (а оно сейчас много где поддерживается автоматом) разница от длины классов становится исчезающе малой:

С другой стороны, ошибочные (как и вообще любые неподдерживаемые данным браузером) значения по стандарту же игнорируются, так что с точки зрения результата утверждение «такое указание свойства ничего не даст» тоже верно

Куда transform-origin поставите, там центр и будет..

-*-backface-visibility: hidden — это такой современный *zoom: 1. Выделяет элемент в отдельный RenderLayer (это такой современный hasLayout) и, с достаточно большой вероятностью, переносит нагрузку по отрисовке на видеокарточку. Попутно фикся многие непонятные и нелогичные косяки (и добавляя новые временами, хоть и редко).

Почему? Из значимых «отказников» только Андроид и (пока) IE8, но у первого, AFAIK, виртуальный вьюпорт по дефолту всегда «как бы» 800px и можно смело привязываться к этому значению, а второй стремительно уходит в небытие и хватит с него изящной деградации. Была проблема в Хроме с динамической перерисовкой, но она тоже, как показывает опыт, вполне решаема.

Так Хром же тоже. Как и сабж. По моим наблюдениям, сабж отстает от Хрома на пару версий движка, так что ему бывают еще нужны префиксы для того, что в Хроме уже работает и так, и т.п. Но, да, штука удобная и в Рунете довольно популярная (популярнее всех IE). Так что разок проверить не помешает

Вопрос о «переходе» уже года два как не стоит — другого *HTML просто не осталось. Вопрос стоит примерно так: «какие из возможностей HTML5 есть смысл использовать в данном конкретном проекте, для данной аудитории».

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

Fx15 можно найти лишь в музее, т.к. он обновляется автоматически каждые полтора месяца и актуальная версия — 29. Старый синтаксис градиентов сейчас есть смысл поддерживать только для андроид-планшетов (-webkit-), и то по желанию, остальные браузеры (включая IE10+) поймут стандартную запись без префикса. Для всего остального старья — изящная деградация до однотонной заливки, пользователи ископаемого хлама только скажут спасибо, что сайт у них будет работать более-менее быстро, а не виснуть в отчаянных попытках «сделать красиво» сверх возможного. А зачем радиус градиента аж 130%? Не лучше ли взять поближе и поставит реальный цвет, а не «свести в полную прозрачность где-то там»? Потому что представление о «где-то там» у браузеров действительно может различаться.

Есть вот такая старая статья с «рейтингом скорости» селекторов. И есть тест сравнения скорости выборки по классу и по атрибуту в jQuery (понятно, что это другая задача, но, если я не заблуждаюсь, лежащий там в основе document.querySelectorAll использует тот же алгоритм выборки элементов по селектору, что и рендерер). Конечно, оптимизировать селекторы принято в последнюю очередь, они редко становятся узким местом… но всё же изначально вешать самую основу оформления на заведомо медленный селектор лично я бы не стал