По сравнению со старыми версиями существенно поднялась производительность IDE. Но, к сожалению, до сих пор медленная работа с большими css и js файлами. Особенно печально дело обстоит с css, у которых 2.5к+ строк…
Хорошая статья, со многим согласен, особенно о свистелках-перделках. Но заключение как-то смазано, т.е. сначала идет перечисление фактов, а после них ожидается более глобальный вывод что ли…
Если бы все браузеры одинаково воспринимали «спецификации» и «стандарты», то и в хаках не было бы смысла.
Валидность на данном этапе развития веб-технологий — в большинстве случаев просто условность, выше я писал почему.
Хорошо, забудем о doctype html. К примеру, атрибут класса не является валидным для xhtml 1.1. Тем не менее он полностью выполняет заложенную мной функциональность, не ломая layout сайта, никак не влияет на его быстродействие и выдачу в поисковых системах. Почему я должен отказываться от этого преимущества?
Так при чем тут CMS, это не их проблемы, что валидатор обновляется раз в полгода и тупо не успевает за развитием технологий.
Как пример — провалидируйте ya.ru — страничку, состоящую из маленькой формы. 9 ошибок по версии w3validator — и ничего, работает, да и яндекс не особо волнуется.
Так я же написал про HTML5.
Ну а я о чем :) Если вас смущает невалидность аттрибута у — просто смените доктайп, и никому от этого не станет хуже, а очень даже наоборот
Во-первых, слепо валидировать html ради самой валидации не имеет особого смысла, тем более после имплементации на любую более-менее сложную cms ни о какой валидности речь идти не может.
Во-вторых, уже давно можно пользоваться <!doctype html>, который отлично понимают все браузеры, включая ie6, и который не ругается на этот класс.
В-третих, изначально в этой технике тег body и использовался, но через определенное время от него отказались в пользу , так как были обнаружены некоторые проблемы в ie разных версий (в некоторых случаях они падали в режим совместимости, на сколько я помню)
Ну там особо и напрягаться не надо — просто иметь заранее заготовленные три строчки цсс-кода и вставлять их периодически то там то сям, а потом во время презентации проекта козырнуть перед клиентом :)
собственно, спрашиваю.
я стараюсь избегать таких конструкций, потому что в процессе разработки теги могут заменяться на другие, например p на div, span на strong и тп — по разным соображениям и не всегда, но такое бывает. и тогда требуются лишние телодвижения, чтобы переделать стили.
или же дата будет появляется не только в блоке div.news, но и например в гипотетическом div.comment, тогда избыточное наследование вставит палки в колеса
Кстати, если активно пользуетесь media queries, рекомендую такую технику
Во время перестройки блоков на разных экранах применяется css transitions, и объекты плавно летят на свои места или обретают новый размер :)
Выглядит эффектнее стандартных резких перестроек дизайна и добавляет пару плюсов в карму, когда клиент замечает фичу :)
Сейчас мы живем в период перехода с одних стандартов на другие, каждый браузер поддерживает ту или иную технологию по-своему, поэтому без таких штук все сложней и сложней обходится :)
Например, вот набор библиотек, которые позволяют эмулировать разные вкусные, но не кроссбраузерные штуки github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
приходится пользоваться ими все чаще
Добавлю, что для мобильных устройств max-width или max-height — так себе решение. Потому что скорость мобильных соединений пока что так себе, плюс у некоторых считается траффик. И открывая на своем телефончике сайт, следует учитывать, что провайдеру будет пофик на то, что у тебя стоит max-width:100px, в то время, когда картинка на самом деле шириной в 1000px и загрузится в свой полный вес
Потому что существует ряд принципиальных вещей, которые отличаются на десктопе/тв и на мобильных устройствах — от дизайна и юзабилити до технических моментов.
Если, к примеру, на сайте, который состоит из трех колонок и наполнен в основном текстом и картинками, будет достаточно выстроить эти колонки в один столбик, пожав пропорционально шрифт и изображения, то на каком-нибудь портале или сайте с хитрой функциональностью c кучей js это будет уже потрудней. И начнут вылазить костыли — то флешку нужно срочно переделывать на альтернативу из js/css3, то оказывается, что на мобильных девайсах position:fixed почти нигде не работает и тривиальная задача прибить футер к низу экрана становится реальной проблемой, которую без прикрутки iscroll особо не сделаешь. Если есть карусель на сайте, то ей тоже придется уделить кучу внимания, параллельно добавив тач-ивенты
ну и так далее
Валидность на данном этапе развития веб-технологий — в большинстве случаев просто условность, выше я писал почему.
Хорошо, забудем о doctype html. К примеру, атрибут класса не является валидным для xhtml 1.1. Тем не менее он полностью выполняет заложенную мной функциональность, не ломая layout сайта, никак не влияет на его быстродействие и выдачу в поисковых системах. Почему я должен отказываться от этого преимущества?
Так при чем тут CMS, это не их проблемы, что валидатор обновляется раз в полгода и тупо не успевает за развитием технологий.
Как пример — провалидируйте ya.ru — страничку, состоящую из маленькой формы. 9 ошибок по версии w3validator — и ничего, работает, да и яндекс не особо волнуется.
Ну а я о чем :) Если вас смущает невалидность аттрибута у — просто смените доктайп, и никому от этого не станет хуже, а очень даже наоборот
Во-вторых, уже давно можно пользоваться <!doctype html>, который отлично понимают все браузеры, включая ie6, и который не ругается на этот класс.
В-третих, изначально в этой технике тег body и использовался, но через определенное время от него отказались в пользу , так как были обнаружены некоторые проблемы в ie разных версий (в некоторых случаях они падали в режим совместимости, на сколько я помню)
еще год назад вдохновился html5boilerplate, где эти техники активно юзаются, и до сих пор не могу нарадоваться :)
Такую технику: paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/
т.е. условными комментариями добавляем соответствующий класс к тегу html, благодаря чему в таблице стилей создаем развилку по версиям експлорера
я стараюсь избегать таких конструкций, потому что в процессе разработки теги могут заменяться на другие, например p на div, span на strong и тп — по разным соображениям и не всегда, но такое бывает. и тогда требуются лишние телодвижения, чтобы переделать стили.
или же дата будет появляется не только в блоке div.news, но и например в гипотетическом div.comment, тогда избыточное наследование вставит палки в колеса
Во время перестройки блоков на разных экранах применяется css transitions, и объекты плавно летят на свои места или обретают новый размер :)
Выглядит эффектнее стандартных резких перестроек дизайна и добавляет пару плюсов в карму, когда клиент замечает фичу :)
div.aside div.news p.date span.month-year {..}
Например, вот набор библиотек, которые позволяют эмулировать разные вкусные, но не кроссбраузерные штуки
github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
приходится пользоваться ими все чаще
хорошее решение, но следует учитывать, что не все мобильные браузеры поддерживают js, или поддерживают криво
Если, к примеру, на сайте, который состоит из трех колонок и наполнен в основном текстом и картинками, будет достаточно выстроить эти колонки в один столбик, пожав пропорционально шрифт и изображения, то на каком-нибудь портале или сайте с хитрой функциональностью c кучей js это будет уже потрудней. И начнут вылазить костыли — то флешку нужно срочно переделывать на альтернативу из js/css3, то оказывается, что на мобильных девайсах position:fixed почти нигде не работает и тривиальная задача прибить футер к низу экрана становится реальной проблемой, которую без прикрутки iscroll особо не сделаешь. Если есть карусель на сайте, то ей тоже придется уделить кучу внимания, параллельно добавив тач-ивенты
ну и так далее