Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 244
Статья супер. Сам правда никогда не любил верстать. Но может если следовать советам из данной статьи, на выходе будет получаться хороший продукт, и я полюблю это дело.
Думаю, следовать этим советам следует прежде всего, если ты изначально умеешь верстать неплохо. А если верстальщих плохой, то советы эти вряд ли спасут. А пост неплохой, согласен, некий такой чеклист перед завершением всех работ.
Я старался написать чек-лист так, чтоб его критерии были формальными, а вёрстку можно было воспринимать как чёрный ящик.
Например «Корректная работа при вбивании реального текста» — её можно организовать и написал килобайты css-правил и несколько выверенных строк. Для клиента результат будет один. Верстальщику же, сталкиваясь с такими требованиями, проще научится делать качественный код.
С плохими верстальщиками дела не имел, но проекты написанные с соблюдением этих требований, ещё неопытными джуниорами, получились вполне качественными, мы время от времени вносим правки в старые проекты — желания «всё выкинуть и переписать» не возникает.
Например «Корректная работа при вбивании реального текста» — её можно организовать и написал килобайты css-правил и несколько выверенных строк. Для клиента результат будет один. Верстальщику же, сталкиваясь с такими требованиями, проще научится делать качественный код.
С плохими верстальщиками дела не имел, но проекты написанные с соблюдением этих требований, ещё неопытными джуниорами, получились вполне качественными, мы время от времени вносим правки в старые проекты — желания «всё выкинуть и переписать» не возникает.
поправьте
через-чур -> чересчур
PRS -> GPRS
роуминт -> роуминг
аплетом -> апплетом
В целом неплохо, только под конец теряется общая структурированность.
Такой список уже пора и автоматизировать :)
через-чур -> чересчур
PRS -> GPRS
роуминт -> роуминг
аплетом -> апплетом
В целом неплохо, только под конец теряется общая структурированность.
Такой список уже пора и автоматизировать :)
Ещё должна быть PHP-валидация формы.
Какая блин php валидация на ВЕРСТКЕ?
Я так понял речь идет не только о верстке, а в целом, что следует проверять при создании сайта перед сдачей его заказчику. Потому что например
>Все страницы должны быть слинкованы и проверены на наличие битых ссылок.
этого верстальщик не обязан делать, имхо.
Статья хорошая, Delka все по-делу расписал! Редко встретишь код, соответствующий требованиям (рекомендациям) что здесь описаны.
>Все страницы должны быть слинкованы и проверены на наличие битых ссылок.
этого верстальщик не обязан делать, имхо.
Статья хорошая, Delka все по-делу расписал! Редко встретишь код, соответствующий требованиям (рекомендациям) что здесь описаны.
Я придерживаюсь мнения что самые простые вещи на php, например запрограммить отправку письма, верстальщик должен уметь. Бывают маленькие сайты, на которых всё статично, и php используется только для порезки на шаблоны и отправки письма с формы контактов.
Аналогично, 404 ошибка при вёрстке?
пхп-валидация наверное имеется ввиду проверка введенных значений :)
Автору статьи — Спасибо!
Автору статьи — Спасибо!
Не забывайте только все эти требования оформить в виде ТЗ при заказе верстки, а то большинство ваших желаний отнюдь не обязательны по умолчанию.
на самом деле, все правильно сказал)
Великолепная статья!
Маленькое дополнение: IE8 в режиме совместимости с IE7 != IE7. На хабре даже была статья с описанием, что за чудо этот режим совместимости, и как с ним бороться.
Маленькое дополнение: IE8 в режиме совместимости с IE7 != IE7. На хабре даже была статья с описанием, что за чудо этот режим совместимости, и как с ним бороться.
Да, есть небольшие отличия, но в целом, они почти идентичны. Во всяком случае если в режиме совместимости с IE7 возникает баг — он будет возникать и в реальном IE7.
А, глядишь, пройдёт ещё годик и похороним IE7 так же как многие уже забыли про IE6.
А, глядишь, пройдёт ещё годик и похороним IE7 так же как многие уже забыли про IE6.
Я на своём сайте прописал
надеюсь этот недорежим "несовместимости со стандартами" отключается. Пользователей старых IE предупреждаю, что их браузер устарел и не придерживается страндартов. Сделал это с помощью:
Тем, кому действительно нужен мой сайт поставит нормальный браузер или наконец-то обновит свою Windows XP через Windows Update или WSUS.Ох, чёрт. Не думал, что внутри code тэги съедаются… в первом случае речь идёт о метатеге
http-equiv="X-UA-Compatible" content="IE=8", во втором про [if lt IE 8].для X-UA-Compatible лучше указывать IE=edge, а то скоро 9-ка выйдет и будет ваши сайты отображать так же как 8-ка, а могла бы — гораздо лучше!
и желательно не метатегом это писать (валидатор ругается), а в .htaccess:
ну или прямо в коде сайта отправлять этот header
и желательно не метатегом это писать (валидатор ругается), а в .htaccess:
<IfModule headers_module>
Header set X-UA-Compatible: IE=edge
</IfModule>ну или прямо в коде сайта отправлять этот header
Отличная статья — объёмистый материал в понятном и сжатом виде. Автору спасибо.
Автору:
— Следует указать, что необходимо проверять, как отображается страница при загрузке на малых скоростях (хотя бы 64 КБ). Очень часто в такие моменты пользователь видит разъехавшуюся верстку.
Throttle — плагин FF. Позволяет ограничить скорость браузера, тем самым спытать web-проект на разных скоростях интернет соединения.
Автору:
— Следует указать, что необходимо проверять, как отображается страница при загрузке на малых скоростях (хотя бы 64 КБ). Очень часто в такие моменты пользователь видит разъехавшуюся верстку.
Throttle — плагин FF. Позволяет ограничить скорость браузера, тем самым спытать web-проект на разных скоростях интернет соединения.
большое спасибо, дополнил статью.
addons.mozilla.org/ru/firefox/search/?q=Throttle&cat=all&x=0&y=0 Нет такого плагина
Выполнение всех этих пунктов увеличат себестоимость вёрстки как минимум в 2-4 раза. Не каждый заказчик согласится заплатить за вёрстку столько же сколько и за дизайн :) Но чеклист явно пригодится…
Но вот работу программиста не всегда можно проверить, а вооружившись описанным в статье инструментарием среднестатистический заказчик начнет требовать соблюдения от вёрстальщика всех стандартов и правил при этом платя такую-же сумму как и раньше.
тогда вон из профессии!
img-fotki.yandex.ru/get/5803/i-zharskiy.d/0_44d57_ea04b4f2_L.jpg
img-fotki.yandex.ru/get/5803/i-zharskiy.d/0_44d57_ea04b4f2_L.jpg
Вы наверное работаете в конторе которая берёт за проект от 300 тыс. рублей. Хочу вас обрадовать, не каждая фирма может позволить себе такие излишества.
Я думаю вёрстальщик бы с радостью потратил своё время на то, чтобы сделать качественный продукт и положил бы его в портфолио, если бы ему за это заплатили деньги и дали достаточно времени, а не как обычно у нас в стране бывает — «к вчера».
Я думаю вёрстальщик бы с радостью потратил своё время на то, чтобы сделать качественный продукт и положил бы его в портфолио, если бы ему за это заплатили деньги и дали достаточно времени, а не как обычно у нас в стране бывает — «к вчера».
Забавно, у нас этим тестировщики занимались, а тут сам ПМ верстку чекает. Скажите, вы, наверное, еще и бэкенд весь проглядываете?
так точно. у нас маленькая фирма, а римт работ довольно спокойный.
Думаю, у каждого приличного ПМ, на основании предыдущего опыта, уже есть сформированный чек-лист или сервис в запасе, типа launchlist.net/
Отличная статья.
IE 6 можно проверять через IETeester
IE 6 можно проверять через IETeester
Вы ради интереса проверьте на родном IE6 и в IETeester — это небо и земля. Так что IETeester не выход.
Удачное решение от Adobe, где можно посмотреть отображение сайта во всех браузерах
Удачное решение от Adobe, где можно посмотреть отображение сайта во всех браузерах
target="_blank"С удивлением обнаружил, что такого атрибута нет в xhtml1-strict
Вообще, читал, что использование этого атрибута не является «правильным», так как нарушает привычный паттерн — юзер просто хочет перейти по ссылке, а тут у него вдруг новое окно/вкладка открывается. Если я хочу новую вкладку, то я жму колесиком (если знаю о таком поведение), а _blank ломает шаблон.
Если уж придерживаться такого требования для внешних ссылок, то желательно тогда добавить еще одно: для таких ссылок как-то показывать, что ссылка внешняя (иконкой например).
Если уж придерживаться такого требования для внешних ссылок, то желательно тогда добавить еще одно: для таких ссылок как-то показывать, что ссылка внешняя (иконкой например).
вы правы, но уж больно не нравится клиентам, когда уходят с их сайта по какой-нибудь ссылке a-la «BBB Accredited Business».
да, желательно выделять такие ссылочки иконкой «внешняя ссылка», дополнил.
да, желательно выделять такие ссылочки иконкой «внешняя ссылка», дополнил.
Некоторые браузеры подсвечивают, что будет открыто в новом окне (вкладке). Например, Konqueror подрисовывает иконку при наведении на такую ссылку.
Его вернули в HTML5.
Ненависть ко всем, кто использует target="_blank"!
Все браузеры открывают страницу в новой вкладке при щелчке на колёсико (в крайнем случае можно выбрать новую вкладку в контекстно меню).
Все браузеры открывают страницу в новой вкладке при щелчке на колёсико (в крайнем случае можно выбрать новую вкладку в контекстно меню).
Колесика может не быть, а открытие контекстного меню долгим. Мне нравится как гугл в поиске сделала — открывать ссылки в поиске или нет задаётся в настройках. Жаль что ко всем ссылкам на гугле это не относится.
DOCTYPE: HTML5
Зачем нужно: это современный стандарт, XHTML – тоже хорошо, но HTML5 – актуальней, да и это модный тренд сейчас.
Проверка: открываем исходный код страницы, первая строка должны быть <!DOCTYPE HTML>
Это минимально необходимый доктайп, чтобы IE не свалился в Quirks, а не HTML5
Плохо когда нет постепенного уточнения стилей, а стиль выписывается для каждого элемента отдельно
Здесь частично не соглашусь. Плохо — только при плохом подходе. Например, если у каждого такого уточнения стоит разный background:url("..."), то некоторые браузеры будут загружать этот новый бэкграунд каждый раз при этом уточнении, независимо от того, какой в итоге должен быть (проверял, правда не помню, какие браузеры)
На очень крупных и частоменяющихся проектах хорошо действует идеология clubs.ya.ru/bem/. Вложенность там есть, но очень неглубокая. Там же рекомендуют отказываться от reset.css.
Проверяется поиском по тексту css названий “Helvetica”,“Liberation”, “DejaVu”,”Meera”,”Monaco”, “ Century Schoolbook L”,” Nimbus Mono L”, “URW”. Хотя бы два из них должны быть.
Наборы аналогов популярных шрифтов:
Не согласен. Вообще ставить что-то кроме семейства шрифта, имхо, необходимо только тогда, когда это _действительно_ нужно. Обычно с головой хватает
font-family: sans-serif;
target="_blank" == невалидность хтмла
Грамотно, нравится, но так из проекта в проект?
Рассматривались ли возможности автоматизировать проверку, не говоря уже о процессе верстания?
Рассматривались ли возможности автоматизировать проверку, не говоря уже о процессе верстания?
Вместо пиксел-перфекта пользуйте ModularGrid (http://habrahabr.ru/blogs/webdev/109988/). В разных браузерах макет может выглядеть по-разному.
Всё так. Ох уж этот пиксел-перфект — жечь его надо каленым железом. Очень часто PM требуют его, тратя драгоценное время разработчиков на статисфакцию никому ненужных пожеланий, когда они могли бы заняться чем-нибудь более полезным для проекта. Я о тех клинических случаях, когда приходят нервные письма с кучей скриншотов и гневными возгласами «Катастрофа! В FF шрифт больше на полпиксела! И вот input, у формы, не такой как в макете.» Особенно если речь про большие проекты, к презентационным сайтам это не относится (идиотизм пиксел-перфект в этих случаях вполне оправдан).
спасибо, дополнил
Да, и ещё, на главной странице ставить название компании в h1 можно только с разрешения оптимизатора.
Вообще, в h1 лучше запихнуть текст ключевого запроса для сайта, или название ключевой услуги. Название компании прекрасно себя чувствует в strong, например.
Вообще, в h1 лучше запихнуть текст ключевого запроса для сайта, или название ключевой услуги. Название компании прекрасно себя чувствует в strong, например.
СЕОшников забыли спросить, что ставить в h1 а что в strong :-)
спасибо.
буквально вчера озадачился таким чеклистом
спасили кучу времени
буквально вчера озадачился таким чеклистом
спасили кучу времени
1.1, 1.2 — не профессиональная аргументация
1.3, предпоследних версий тоже много установлено :)
1.3 Проверка в IE7 и проверка в режиме IE7 — есть различия, плюс режим IE7 менялся некоторыми обновлениями Windows Update, так что… лучше просто в IE7
2.2 Упоротая секретарша копипастит тексты из Word’а в визиг — это надо предусматривать, и чинить, и инструкцию секретарше писать, и теги лишние фильтровать где можно :)
Начиная с 4го пункта, я так понимаю написано уже не для заказчиков?) Как проверять, опускаете, но пошли советы разработчикам :)
1.3, предпоследних версий тоже много установлено :)
1.3 Проверка в IE7 и проверка в режиме IE7 — есть различия, плюс режим IE7 менялся некоторыми обновлениями Windows Update, так что… лучше просто в IE7
2.2 Упоротая секретарша копипастит тексты из Word’а в визиг — это надо предусматривать, и чинить, и инструкцию секретарше писать, и теги лишние фильтровать где можно :)
Начиная с 4го пункта, я так понимаю написано уже не для заказчиков?) Как проверять, опускаете, но пошли советы разработчикам :)
1.1, 1.2 — не профессиональная аргументациякак на ваш взгляд нужно аргументировать 1.1 и 1.2?
1.3, предпоследних версий тоже много установлено :)к счастью они быстро (пару месяцев) уходят со сцены благодаря автоапдэйту.
1.3 Проверка в IE7 и проверка в режиме IE7 — есть различия, плюс режим IE7 менялся некоторыми обновлениями Windows Update, так что… лучше просто в IE7согласен, но учитывая что IE7 уже недолго осталось жить, можно ограничится режимом совместимости. Во всяком случае если в режиме совместимости с IE7 возникает баг — он будет возникать и в реальном IE7.
Начиная с 4го пункта, я так понимаю написано уже не для заказчиков?) Как проверять, опускаете, но пошли советы разработчикам :)вроде бы везде написал как проверять, подскажите плиз где нехватает.
Не думаю, что IE7 осталось жить недолго. Кто ещё не обновился обновится, скорее всего, только при смене ОС. Кто ещё не обновил Висту и, тем более, XP обновят ОС, скорее всего, только при смене железа…
на мой взгляд:
1.1 — универсальность, совместимость
1.2 — пока не нужно аргументировать :)
5й пункт — есть что плохо/хорошо, есть примеры, как проверять нету)
кстати) как решаете вопрос с печатью спрайтов? (версия для печати, css background)
1.1 — универсальность, совместимость
1.2 — пока не нужно аргументировать :)
5й пункт — есть что плохо/хорошо, есть примеры, как проверять нету)
кстати) как решаете вопрос с печатью спрайтов? (версия для печати, css background)
2.2 Упоротая секретарша копипастит тексты из Word’а в визиг — это надо предусматривать, и чинить, и инструкцию секретарше писать, и теги лишние фильтровать где можно :)
Прекрасно лечится jevix'ом и избавляет от лишней головной боли верстальщикам
Спасибо. В Избранное.
Ну и вопрос, в каких ценовых пределах находится создание сайта, удовлетворяющего этим требованиям?
Не-ве-рю! В смысле, не верю, что верстаете именно по всем стандартам. Чего только стоит сделать правильный сайт под WCAG/WAI/Section 508. Именно правильный для людей с ограниченными возможностями, а не для валидатора. Таких сайтов единицы на весь интернет.
$200-250 титулка, $50-60 внутряк.
SEOник отдельным пунктом у вас?
потому что про микроформаты, карты и т.п. — я лично это считаю обязательным и очень важным, всегда делаю сам и от других требую, а кто-то считает баловством (категорически не согласен, есть печальные примеры)
у вас очень грамотно, если вы действительно всё это внедрили в процесс разработки, — то честь вам и хвала
отдельная благодарность за статьи, за то, что делитесь знаниями (я не знал 1 или 2 пункта всего, но они довольно интересные), за то, что дорабатываете посты и активно обсуждаете в каментах (конструктивно)
ваши посты читаю, заношу в избранное, распечатываю, внимательно анализирую
и потом ещё возвращаюсь за новыми комментариями
потому что про микроформаты, карты и т.п. — я лично это считаю обязательным и очень важным, всегда делаю сам и от других требую, а кто-то считает баловством (категорически не согласен, есть печальные примеры)
у вас очень грамотно, если вы действительно всё это внедрили в процесс разработки, — то честь вам и хвала
отдельная благодарность за статьи, за то, что делитесь знаниями (я не знал 1 или 2 пункта всего, но они довольно интересные), за то, что дорабатываете посты и активно обсуждаете в каментах (конструктивно)
ваши посты читаю, заношу в избранное, распечатываю, внимательно анализирую
и потом ещё возвращаюсь за новыми комментариями
спасибо,
Извиняюсь, не совсем понял вопрос «SEOник отдельным пунктом у вас?»
Про организацию отдела вёрстки планирую сделать доклад этой весной/летом.
Извиняюсь, не совсем понял вопрос «SEOник отдельным пунктом у вас?»
Про организацию отдела вёрстки планирую сделать доклад этой весной/летом.
У вас всё хорошо написано именно с точки зрения SEO.
Некая изначальная семантичность/оптимальность входит в базовый набор услуг и оговаривается в брифе/ТЗ?
К верстальщикам есть требования SEO-грамотности, знания важных основ?
Вы это как-то специально упоминаете в рекламе? (IMHO имеете право, если приведённый checklist — каждодневная, обычная практика)
Некая изначальная семантичность/оптимальность входит в базовый набор услуг и оговаривается в брифе/ТЗ?
К верстальщикам есть требования SEO-грамотности, знания важных основ?
Вы это как-то специально упоминаете в рекламе? (IMHO имеете право, если приведённый checklist — каждодневная, обычная практика)
думаю что пункт о показе банеров даже с включенным адблокером лучше не упоминать
Отличная, полезная статья. Несколько замечаний:
Есть несколько специфичных моментов. Вы пишете на PHP — у вас валидаци в PHP и расширение файлов — php, у кого-то будет другое. Вы пишете на Windows 0 вы ищете аналоги шрифтов на Mac/Linux, у кого-то ьбудет наоборот и т.д.
> модный тренд
Руки так и тянутся к топору. Пишите по-русски.
Есть несколько специфичных моментов. Вы пишете на PHP — у вас валидаци в PHP и расширение файлов — php, у кого-то будет другое. Вы пишете на Windows 0 вы ищете аналоги шрифтов на Mac/Linux, у кого-то ьбудет наоборот и т.д.
> модный тренд
Руки так и тянутся к топору. Пишите по-русски.
Статья — полная чушь. Какая-то реклама HTML5. Большинство пунктов вообще можно оспорить.
Оспаривайте, интересно почитать
1.2. DOCTYPE: HTML5.
Выбирать HTML5 из-за его актуальности и модности? Бред. Автору советуется почитать хотя бы Якоба Нильсена и узнать на что же нужно опираться, выбирая какую-нибудь технологию.
1.3. Кроссбраузерность.
Проверка веб-сайта лишь в последней версии браузера может быть черевата в некоторых случаях. Про IE6 — автору рекомендуется посмотреть видео «Кривое зеркало» Сергея Чикуёнка (http://2010.404fest.ru/video/item-23/). Ну и про мобильные браузеры — или автор не делал веб-сайты под них или делал, но очень простые и не понимает, почему в нынешнем уровне развития технологий гораздо лучше сделать специальную версию веб-сайта для мобильных устройств, поместив её на, допустим, поддомене.
2.1. Не должно быть js-ошибок!
Спаисбо, кэп!
2.1. Микроформаты должны быть.
Микроформаты должны быть, если их использование уместно. Бездумное набивание веб-сайта функционалом, микроформатами и прочего — яркий пример непрофессионализма. Здесь автору рекомендуется почитать Алана Купера.
4.2. и 4.5.
См. первый ответ.
6. Правильная структура заголовков. Важна для SEO.
Она не для SEO важна (и вообще хватит говорить об этом позоре), а для вас, когда вы будете писать стили для разных устройств.
Пункты 8, 9, 10.
Только если вы «Яндекс».
Всё это обнаружилось беглым пробегом, уверен, что если поискать и попридираться, можно найти ещё. Но, прошу прощения, у меня тут не школьные каникулы :-)
Выбирать HTML5 из-за его актуальности и модности? Бред. Автору советуется почитать хотя бы Якоба Нильсена и узнать на что же нужно опираться, выбирая какую-нибудь технологию.
1.3. Кроссбраузерность.
Проверка веб-сайта лишь в последней версии браузера может быть черевата в некоторых случаях. Про IE6 — автору рекомендуется посмотреть видео «Кривое зеркало» Сергея Чикуёнка (http://2010.404fest.ru/video/item-23/). Ну и про мобильные браузеры — или автор не делал веб-сайты под них или делал, но очень простые и не понимает, почему в нынешнем уровне развития технологий гораздо лучше сделать специальную версию веб-сайта для мобильных устройств, поместив её на, допустим, поддомене.
2.1. Не должно быть js-ошибок!
Спаисбо, кэп!
2.1. Микроформаты должны быть.
Микроформаты должны быть, если их использование уместно. Бездумное набивание веб-сайта функционалом, микроформатами и прочего — яркий пример непрофессионализма. Здесь автору рекомендуется почитать Алана Купера.
4.2. и 4.5.
См. первый ответ.
6. Правильная структура заголовков. Важна для SEO.
Она не для SEO важна (и вообще хватит говорить об этом позоре), а для вас, когда вы будете писать стили для разных устройств.
Пункты 8, 9, 10.
Только если вы «Яндекс».
Всё это обнаружилось беглым пробегом, уверен, что если поискать и попридираться, можно найти ещё. Но, прошу прощения, у меня тут не школьные каникулы :-)
> Пункты 8, 9, 10.
>Только если вы «Яндекс».
Вот так и остаются некоторые пользоватеи с Интернетом, в котором работает один Яндекс.
>Только если вы «Яндекс».
Вот так и остаются некоторые пользоватеи с Интернетом, в котором работает один Яндекс.
1.2. DOCTYPE: HTML5.
Выбирать HTML5 из-за его актуальности и модности? Бред.
Нет, выбирать HTML5-доктайп из-за того, что это единственный разумный выбор сегодня.
Аргументация здесь: Доктайп. Точка
1.2 А почему ж не выбирать акутальную технологию? Какие есть объективные доводы против HTML5? Плюсов много.
1.3 Каюсь, до сих пор не посмотрел то видео, обязательно посмотрю, но! Я считаю не стоит цепляться за старое, закопайте наконец стюардессу, доля IE6 уже меньше 4%. И явно часть этой доли — верстальщики, проверяющие в нём вёрстку :)
За прошедший год, только 1 (один!) клиент попросил нас добавить поддержку IE6. Благодаря отказу от его поддержки мы можем писать более чистый, красивый, удобный в поддержке код. Значительно меньше времени уходит на разработку и поддержку. Сайты лучше и быстрее отображаются в современных браузерах.
2.1 Чем помешают микроформаты? Они не бездумные, нам в любом случае писать html-разметку, почему же не использовать определённые стандарты кодирования? Это только ускоряет процесс, верстальщик точно знает — это пишем так, а это так.
4.2 и 4.5 — чем плохи html5 формы? Какие проблемы с новыми типами input? Они обратносовместимы, старые браузеры просто покажут input[text]. Смена клавиатуры под формат ввода на iPhone — это очень удобно.
6. Конечно в первую очередь это семантика документа, дополнил. Но согласитесь — стили для разных устройств можно написать и для сайта где кроме
8,9,10 — полезно всем. Дополнил что если уж впадлу делать — так хоть уведомление через noscript выведите.
1.3 Каюсь, до сих пор не посмотрел то видео, обязательно посмотрю, но! Я считаю не стоит цепляться за старое, закопайте наконец стюардессу, доля IE6 уже меньше 4%. И явно часть этой доли — верстальщики, проверяющие в нём вёрстку :)
За прошедший год, только 1 (один!) клиент попросил нас добавить поддержку IE6. Благодаря отказу от его поддержки мы можем писать более чистый, красивый, удобный в поддержке код. Значительно меньше времени уходит на разработку и поддержку. Сайты лучше и быстрее отображаются в современных браузерах.
2.1 Чем помешают микроформаты? Они не бездумные, нам в любом случае писать html-разметку, почему же не использовать определённые стандарты кодирования? Это только ускоряет процесс, верстальщик точно знает — это пишем так, а это так.
4.2 и 4.5 — чем плохи html5 формы? Какие проблемы с новыми типами input? Они обратносовместимы, старые браузеры просто покажут input[text]. Смена клавиатуры под формат ввода на iPhone — это очень удобно.
6. Конечно в первую очередь это семантика документа, дополнил. Но согласитесь — стили для разных устройств можно написать и для сайта где кроме
span class ничего не используется.8,9,10 — полезно всем. Дополнил что если уж впадлу делать — так хоть уведомление через noscript выведите.
>Я считаю не стоит цепляться за старое, доля IE6 уже меньше 4%.
Доля IE7 IE8 = 25%. Они поддерживают HTML5?
Доля IE7 IE8 = 25%. Они поддерживают HTML5?
graceful degradation для IE8 и тем более IE7 допустим.
некоторые наиболее востребованные css3-свойства весьма клёва эмулируются через pie.htc (там через VML, всё кошерно).
некоторые наиболее востребованные css3-свойства весьма клёва эмулируются через pie.htc (там через VML, всё кошерно).
1.2 По сути сейчас HTML5 поддерживает более-менее нормально только WebKit. Остальные должны игнорировать незнакомые элементы (вместе с содержимым). Всех пользователей пересаживаем на Хром(иум) и Сафари?
всё зависит от конкретных фич, которые вы используете в конкретном проекте, что именно из html5 и css3 вам нужно. обычно не так много то и надо :)
смотрите плиз коммент чуть выше про graceful degradation.
смотрите плиз коммент чуть выше про graceful degradation.
Я про всякие section, article, header, footer и т. п. Свойства-то понятно, что если даже игнорируются, то не смертельно.
Это ведь те же div, просто несущие доп. семантику.
Для IE есть маленький js-скрипт, позволяющий стайлить html5 элементы в css.
Для IE есть маленький js-скрипт, позволяющий стайлить html5 элементы в css.
Ну вот и хочется эту семантику нести не в классах или ид, а в элементах, раз уж html5.
По-моему, дело одним IE не ограничивается, но это ладно, какие-нить хаки наверное есть, хотя что этот скрипт делает не понял, уж очень всё минимизировано, а вот насчёт гугла-яндекса вообще не уверен, парсят ли они html5 или нет.
По-моему, дело одним IE не ограничивается, но это ладно, какие-нить хаки наверное есть, хотя что этот скрипт делает не понял, уж очень всё минимизировано, а вот насчёт гугла-яндекса вообще не уверен, парсят ли они html5 или нет.
Вы назвали статью чушью основываясь на своем субъективном мнении, а оспаривая, сами соглашаетесь с некоторыми выводами автора. Вы не там чушь увидели ;)
Возвращайтесь, когда школьные каникулы начнутся :-)
Возвращайтесь, когда школьные каникулы начнутся :-)
>HTML5 – актуальней, да и это модный тренд сейчас
HTML5 уже принят в качестве стандарта? Тыркните где об этом можно почитать.
HTML5 уже принят в качестве стандарта? Тыркните где об этом можно почитать.
Очень много спорных заявлений. По поводу тренда и моды на доктайп, рекомендую посмотреть небольшой доклад Вадима Макеева Доктайп. Точка.
> IE7+ (для IE6 выводится уведомление о неподдержке и предложении скачать другой браузер, но с возможностью всё-таки просмотреть сайт)
> Safari 3 (в нём «размытые Mac'овские» шрифты, они чуть большего размера, из-за этого бывает вылазят баги) + последний Safari
Странные требования. Что-то мне подсказывает, что Safari 3 в разы меньше, чем IE 6
> Safari 3 (в нём «размытые Mac'овские» шрифты, они чуть большего размера, из-за этого бывает вылазят баги) + последний Safari
Странные требования. Что-то мне подсказывает, что Safari 3 в разы меньше, чем IE 6
Ну, чтобы «поддерживать» Safari 3 никаких особых дополнительных усилий не надо, а вот IE6 — жесть.
Вообще-то, дизайнер/верстальщик должен следовать не мантре «мне так удобнее» или «это жесть», а хотя бы таблице graded browser support
Правда, в первой четверти этого года IE6 переходит в C-grade, так что уже неважно
Правда, в первой четверти этого года IE6 переходит в C-grade, так что уже неважно
Ну вот о том и речь, никто и не говорит, что с IE6 вообще не надо заморачиваться, просто должно выводиться предупреждение о том, что браузер устарел и советовать его обновить.
В идеале верстальщик должен уметь поддерживать всё хоть как-то еще встречающееся — и IE6, и Safari 3. Но нормально объяснять клиенту (или ПМ-у, а тот — клиенту… нутыпонел) стоимость поддержки каждого динозавра.
Уметь — да, конечно, должен!
Я отчасти понимаю ваше желание поддерживать 6-ку. Когда уже знаешь её баги и умеешь с ними бороться — чувствуешь себя круче других. «Я настоящий профи, я с лёгкостью поддерживаю IE6 в своих проектах, на радость клиентам, а те кто это не делают — неумёхи и не думаю про несчастных юзеров».
Ещё недавно так всё и было. В 2009 году я для повышения скилов потребовал на одном проекте сделать поддержку IE5 :)
Но сейчас есть вещи гораздо сложнее и круче чем zoom: 1; для hasLayout. А 6-тым IE скоро будут пользоваться только те кто в нём проверяют вёрстку, как в своё время было с NN4 :)
Лучше повышать свои скилы изучая CSS3 и HTML5. Там много крутых вещей и возможностей порадовать пользователя.
Я отчасти понимаю ваше желание поддерживать 6-ку. Когда уже знаешь её баги и умеешь с ними бороться — чувствуешь себя круче других. «Я настоящий профи, я с лёгкостью поддерживаю IE6 в своих проектах, на радость клиентам, а те кто это не делают — неумёхи и не думаю про несчастных юзеров».
Ещё недавно так всё и было. В 2009 году я для повышения скилов потребовал на одном проекте сделать поддержку IE5 :)
Но сейчас есть вещи гораздо сложнее и круче чем zoom: 1; для hasLayout. А 6-тым IE скоро будут пользоваться только те кто в нём проверяют вёрстку, как в своё время было с NN4 :)
Лучше повышать свои скилы изучая CSS3 и HTML5. Там много крутых вещей и возможностей порадовать пользователя.
Поддерживать IE6 — это было моё желание как руководителя (хотя я им никогда не был), а вот как верстальщику поддерживать IE6 мне не очень интересно. С другой стороны делал недавно одну страничку для себя на float-блоках… хаков для ie6+ie7 понадобилось гораздо больше, чем для одного ie6. Да, в strict mode.
А что там в css3 такого?
— навороченные селекторы уже использую в js.
— веб2.0 рюшечки? Регулярно нападает желание сделать что-дь такое гламурное одним css3 без картинок. Например, нижнюю панель как в WinXP silver.
ну и т.д.
Впрочем, я был веб-программистом широкого профиля и вёрсткой занимался только частично, а сейчас перешёл практически чисто на js. Вкусно и питательно!
А что там в css3 такого?
— навороченные селекторы уже использую в js.
— веб2.0 рюшечки? Регулярно нападает желание сделать что-дь такое гламурное одним css3 без картинок. Например, нижнюю панель как в WinXP silver.
ну и т.д.
Впрочем, я был веб-программистом широкого профиля и вёрсткой занимался только частично, а сейчас перешёл практически чисто на js. Вкусно и питательно!
Вчера вот верстал под хром, слои фона очень понравились.
Страничку на float-блоках делать не надо. Я правильно понимаю что вы задавали почти всем блокам float: left? они тогда схлопываются до своего содержимого и друг за дружкой идут, похоже на ячейки таблицы. Это очень плохо, очень.
Да, рюшечки и селекторы :)
CSS3 gradients, rgba, box/text-shadow, border-radius — на самом деле очень большой шаг вперёд — прописать несколько правил, а не нарезать картинки и мучатся с их позиционированием.
Да, рюшечки и селекторы :)
CSS3 gradients, rgba, box/text-shadow, border-radius — на самом деле очень большой шаг вперёд — прописать несколько правил, а не нарезать картинки и мучатся с их позиционированием.
Нет, не всем. Все float-блоки у меня собраны внутри div с фиксированной шириной. Раньше там вообще таблицы были =)
Рюшечки css3 с приличной деградацией в IE6-8: imperion.kirilloid.ru/beta/
3 картинки + один спрайт на все иконки + спрайт с подписями к «лампочкам».
ЗЫ: индикаторы «врут» — ошибки нет )
Рюшечки css3 с приличной деградацией в IE6-8: imperion.kirilloid.ru/beta/
3 картинки + один спрайт на все иконки + спрайт с подписями к «лампочкам».
ЗЫ: индикаторы «врут» — ошибки нет )
Это всего-лишь способ проверить сглаживание шрифтов «как на Маке», дополнил статью пояснением.
ниже в комментах мне подсказали что маковское сглаживание можно включить и на 5-том Safari под win.
Pixel Perfect — офигенно удобная и полезная вещь!
Не «типографировать», а «оттипографить». Этот неологизм построен из самого названия лебедевского инструмента.
Последний абзац порадовал :)
Последний абзац порадовал :)
Opera Mini (проверяется в Opera 9.64→Вид-Маленький экран)
Плохой совет. А вот хороший: Opera Developer Tools — Opera Mini Simulator и Opera Mobile Emulator, иначе мини-режим в 9.64 это просто ужатая вёрстка. Это как проверять поведение в iOS на Safari, глупо же.
Opera Mini Simulator требует какой-то плагин, но при клике на «Хотите узнать подробнее об установке плагина» выводит страничку с кучей ссылок про разные плагины, так и не подсказав какой нужен.
Мини-режим в 9.64 — это не ужатая вёрстка, подгружается handheld.css а не screen, внешний вид отображению в Opera Mobile на мобильнике.
Мини-режим в 9.64 — это не ужатая вёрстка, подгружается handheld.css а не screen, внешний вид отображению в Opera Mobile на мобильнике.
хихи, расскажи Макееву про Оперу
уже рассказывал :)
а что ж поделать, я сам Оперу очень люблю, но ни что не идеально
а что ж поделать, я сам Оперу очень люблю, но ни что не идеально
Симулятор Opera Mini — это Java-приложение, требует соотв. плагин. Java в обычных системах это вроде бы не бог весть какая редкость. Так что это не похоже на проблему. По меньшей мере, стоит тестировать в эмуляторе Opera Mobile, хотя соотношение пользователей Mini/Mobile — 85/15%.
В любом случае, даже если подргузится handheld.css вы не вспомните про ограниченный JS, особенности рендеринга и потенциальные проблемы. Так что разумнее будет открыть страничку с симулятором, а не держать на машине 9.64.
В любом случае, даже если подргузится handheld.css вы не вспомните про ограниченный JS, особенности рендеринга и потенциальные проблемы. Так что разумнее будет открыть страничку с симулятором, а не держать на машине 9.64.
с версткой статьи все ок, но вот сетка поехала ;)
В целом хороший список, отражает, скажем так, «Best Practices» для работы с версткой, хотя тут и не все пункты и подпункты касаются именно верстки.
Однако на практике некоторые пункты несут определенный «overhead» в объеме работ, и нужно уже смотреть по конкретным требованиям, а не пытаться сделать каждую и каждую страницу максимально доступной (accessible). Ну типа круто бы, конечно, чтоб даже при выключенном мониторе отображалась надпись «Включите монитор для полноценной работы сайта», но сделать — сложно, и не всегда нужно.
Я бы добавил еще по пунктам:
0. Не забываем, что есть еще весьма полезная штука — SuperPreview, особенно для тестирования в IE.
3. В большинстве (абсолютном большинстве) я бы использовал или WYSIWYM-редактор, или простой текст с Markdown вместо этих TinyMCE, FCK и прочих. В любом случае — стили должен задавать дизайнер сайта, а не пользователь.
15. > «Расширение страниц на сайте всегда должно быть ».html", а все созданные странички изначально должны иметь расширение .php, быть порезаны на шаблоны и работать через mod_rewrite."
А зачем там вообще какое-то расширение. Ну и, конечно, ".php" совсем не «должны» :)
Ну а заодно,
16. Лого на главной должно быть активным и вести на главную же страницу. Вопреки расхожему мнению, лого-ссылка — это не обязательно лишь ссылка, а некоторый контекстный элемент с очень удобным поведением — на всех страницах это ссылка на главную, а на главной — это основной инструмент «рефреша» страницы. Особенно актуально для часто-обновляемых ресурсов.
Ну и, в заключение добавлю, что львиную долю проверки перечисленного в топике можно автоматизировать.
Однако на практике некоторые пункты несут определенный «overhead» в объеме работ, и нужно уже смотреть по конкретным требованиям, а не пытаться сделать каждую и каждую страницу максимально доступной (accessible). Ну типа круто бы, конечно, чтоб даже при выключенном мониторе отображалась надпись «Включите монитор для полноценной работы сайта», но сделать — сложно, и не всегда нужно.
Я бы добавил еще по пунктам:
0. Не забываем, что есть еще весьма полезная штука — SuperPreview, особенно для тестирования в IE.
3. В большинстве (абсолютном большинстве) я бы использовал или WYSIWYM-редактор, или простой текст с Markdown вместо этих TinyMCE, FCK и прочих. В любом случае — стили должен задавать дизайнер сайта, а не пользователь.
15. > «Расширение страниц на сайте всегда должно быть ».html", а все созданные странички изначально должны иметь расширение .php, быть порезаны на шаблоны и работать через mod_rewrite."
А зачем там вообще какое-то расширение. Ну и, конечно, ".php" совсем не «должны» :)
Ну а заодно,
16. Лого на главной должно быть активным и вести на главную же страницу. Вопреки расхожему мнению, лого-ссылка — это не обязательно лишь ссылка, а некоторый контекстный элемент с очень удобным поведением — на всех страницах это ссылка на главную, а на главной — это основной инструмент «рефреша» страницы. Особенно актуально для часто-обновляемых ресурсов.
Ну и, в заключение добавлю, что львиную долю проверки перечисленного в топике можно автоматизировать.
Хотя я и 10 лет «верстаю» — и половины наверное не делаю. Это ужасно.
«Skype-плагин не должен ломать вёрстку» — FFFFFFUUUUUUUUUUUU я бы на манагера накинулся наверное скажи он мне такое)))))) «Эти суки лезут в код ломают его а я должен теперь из-за них работать дополнительно!!!!»)
«Skype-плагин не должен ломать вёрстку» — FFFFFFUUUUUUUUUUUU я бы на манагера накинулся наверное скажи он мне такое)))))) «Эти суки лезут в код ломают его а я должен теперь из-за них работать дополнительно!!!!»)
Если используем html5 доктайп, то можно ли использовать тэги, которые есть в html5, но нет в html 4? :)
Статья хорошая, но немного спорная. И чуть смешано с программной частью разработки сайта.
Насчёт №8 работоспособность при выключенном JavaScript вводить class, например, no-js — выше код.
Для h1,h2,h3… Я еще добавляю классы, соответственно .h1,.h2,.h3, чтобы использовать стили заголовков, там где по CEO ненужно.
№13 Оптимизация скорости загрузки. +Все скрипты перенести с head в конец страницы, для быстрой загрузки страницы.
Если же вставляем хаки для IE в main.css, то их нужно фильтровать: (* html, *+html и т.д.).хаки такого типа отстой, мне больше:
<!--[if lt IE 7 ]> <html class="no-js ie6"> <![endif]--> <!--[if IE 7 ]> <html class="no-js ie7"> <![endif]--> <!--[if IE 8 ]> <html class="no-js ie8"> <![endif]--> <!--[if (gte IE 9)|!(IE)]><!--> <html class="no-js"> <!--<![endif]-->Можно и body вместо html, но не забывая про lang=«ru» либо в body, либо в html. А лучше откройте для себя html5boilerplate.com.
Насчёт №8 работоспособность при выключенном JavaScript вводить class, например, no-js — выше код.
Лого на внутряках должно вести на титулку. На титулке logo = h1, на внутряках h1 = заголовок контента, а logo = divИногда на главной есть CEO текст — там-то и используется h1.
Для h1,h2,h3… Я еще добавляю классы, соответственно .h1,.h2,.h3, чтобы использовать стили заголовков, там где по CEO ненужно.
№13 Оптимизация скорости загрузки. +Все скрипты перенести с head в конец страницы, для быстрой загрузки страницы.
Со многим согласен. Некоторые вещи из выше написанного не знал. Конечно присутствует мое дилетантское ощущение — что слишком уж многое надо проверять.
Огромное спасибо за расшаренный боевой опыт!
P.S.
Удивлен что ПМ должен выполнять работу тестера. Но как ни странно — на практике инициатива чек листов обычно исходит именно от ПМ.
Огромное спасибо за расшаренный боевой опыт!
P.S.
Удивлен что ПМ должен выполнять работу тестера. Но как ни странно — на практике инициатива чек листов обычно исходит именно от ПМ.
hCard — не слишком ли упрощает жизнь спамерам?
Для какихто внутренних вещей, CRM и пр., может и хорошо, но надо ли иметь hCard в каком-нибудь внешнем сайте?
Для какихто внутренних вещей, CRM и пр., может и хорошо, но надо ли иметь hCard в каком-нибудь внешнем сайте?
Всё клёво, разве что смущает указание на конкретные инструменты для проверки. Почти везде указаны Fx, PHP, SVN и всё-такое, тогда как лучше было бы или привести по несколько вариантов или ограничиться более общими фразами:
- «Все бекапы можно вытянуть из SVN» → «Все бекапы можно вытянуть из системы контроля версий»
- «Ещё должна быть PHP-валидация формы» → «Ещё должна быть деградация на серверную валидацию форм» (хотя я тоже против этого пункта в этом списке :)
Прекрасная статья!
Еще заказчиков найти бы, готовых все это оплатить, самому было бы очень интересно.
По некоторым пунктам с вами будут несогласны гуру.
Еще заказчиков найти бы, готовых все это оплатить, самому было бы очень интересно.
По некоторым пунктам с вами будут несогласны гуру.
Просто апплодирую стоя! Очень полезная статья. Именно ради таких топиков, которые позволяют повышать свой уровень, я и хожу на Хабр. Спасибо!
Очень плохо — презентационные классы (right, red).
Объясните свою позицию. У меня всегда есть заготовки float: left/right; для случаев, когда больше ничего для элемента не нужно. Например для иллюстраций в тексте. Мне кажется, что это достаточно семантично.
Браво! Спасибо за чек-лист, все сам давно собирался сделать такой :)
Вот только я не согласен с тем, что в стилях нужно писать теги. В стилях вообще не должно быть тегов, только классы (и иногда id)! (подразумеваются стилизированных элементов, а не глобальные a, p, table и т.д.).
Т.е. вместо
пишем
Аргументация: При программинге не редко приходится менять теги (сеошники тоже, порой, хотят что-то иное), если теги в CSS. Еще где-то было про внутренние требования яндекса к верстке, там тоже об этом говорили, но не могу найти, мб на яндекс.субботниках говорили.
Ну и вообще, если в проекте придерживаются подхода верстки независимыми блоками, то там немного другой чек-лист будет.
Вот только я не согласен с тем, что в стилях нужно писать теги. В стилях вообще не должно быть тегов, только классы (и иногда id)! (подразумеваются стилизированных элементов, а не глобальные a, p, table и т.д.).
Т.е. вместо
body.contacts div#content div#content-text div.entry div.somenamedblockпишем
#content #content-text .entry .somenamedblockАргументация: При программинге не редко приходится менять теги (сеошники тоже, порой, хотят что-то иное), если теги в CSS. Еще где-то было про внутренние требования яндекса к верстке, там тоже об этом говорили, но не могу найти, мб на яндекс.субботниках говорили.
Ну и вообще, если в проекте придерживаются подхода верстки независимыми блоками, то там немного другой чек-лист будет.
Ах, ну и да, то что уже сказали выше — IE6 надо поддерживать.
спасибо за замечание, требования к написанию кода (стандарты кодирования) мы ещё не формировали официально, учтём.
У яндекса для атомарных блоков вроде как позволительно использовать теги и соответственно писать стили. В общем случае, конечно, лучше стараться через классы.
В смысле, использовать теги без классов/id и писать стили для них. Вот про простые блоки: clubs.ya.ru/bem/replies.xml?item_no=42
Когда код состоит из одних дивов, да спавнов, то перечислять тэги смысла нет, конечно. Но вот менять селектор вида
#someblock ul li a img#someblock .unordered_list .list_item .anchor .image<ul class="unordered_list"><li class="list_item"><a class="anchor" ...><img class="image" ...>...Yep. Я говорю о ситуации, когда у вас тег может поменяться. ul/li не могут поменять — это законченный объект на странице. А вот h3 на h4 или даже на strong, p на div иди span — относительно часто могут меняться.
То есть грубо говоря там где верстальщик уже прописал классы — не нужно в стилях ограничивать их каким-либо элементов.
То есть грубо говоря там где верстальщик уже прописал классы — не нужно в стилях ограничивать их каким-либо элементов.
*не нужно в стилях ограничивать их каким-либо тегом.
А, ну если прописаны, то грех не воспользоваться. Просто как-то видел страничку в портфолио у верстальщика, там фактически свёрстано на дивах с ид/клаасами, то есть в боди одни только дивы, почти ни одного другого тэга. Подпись была «верстаю дивами», но я так и не понял, шутка это была, или он серьезно так верстает.
Статья супер!
Закос в P.S. под Касту — тоже классно.
Закос в P.S. под Касту — тоже классно.
>Все ссылки должны как-то реагировать на :hover
ИМХО, все ссылки ДОЛЖНЫ быть подчёркнуты (если это, конечно, не новостной сайт)
ИМХО, все ссылки ДОЛЖНЫ быть подчёркнуты (если это, конечно, не новостной сайт)
Представьте верстку под Андроид с разными dpi, под iPhone учетом ориентации окна(горзонтально или вертикально) а потом советуйте этот дурацкий PixelPerfect. За последние, примерно, 7 месяцев работы уже забыл что это такое расположение блоков 1:1. Прибъете размеры шрифтов в пикселях, и соотвественно отступы и посмотрите на разных андроид устройствах и iPhone/iPod/iPad — в целом статья классная, все гуд, но вот на счет пиксель перфект, и вообще прибивания чего-то гвоздями в верстке… я бы несоветовал.
конечно, при смене ориентации соответствия 1:1 макету уже не получится.
но это ведь не значит что вообще не стоит сравнивать вёрстку с макетом? разве есть проблема расположить блоки как на макете? чтоб у них были такие же размеры, отступы.
ясное дело что при изменениях контента, размеры блоков могут меняться (по высоте например), но это нормально, адекватный ПМ не должен затягивать сдачу проекта, тратя время (а значит и деньги фирмы) на вылизывание каждого пикселя.
но это ведь не значит что вообще не стоит сравнивать вёрстку с макетом? разве есть проблема расположить блоки как на макете? чтоб у них были такие же размеры, отступы.
ясное дело что при изменениях контента, размеры блоков могут меняться (по высоте например), но это нормально, адекватный ПМ не должен затягивать сдачу проекта, тратя время (а значит и деньги фирмы) на вылизывание каждого пикселя.
Считаю что да. Я часто для своих проектов, делая верстку сталкивался с такой проблемой что на 1280-800 все классно а на 1024-768 не так уже смотретиться. И я искренне рекомендую всем клиентам(своим) что бы они прислушались и использовали относительные размеры и т.д. потому как важна то информация, если по части дизайна, и качество кода, если по части верстки. Но это имхо, и то часто приходиться прибивать гвоздями :) правда потом не редко клиенты просят переделать…
Ну а поповоду вылизывания каждого пикселя, я как то думал что именно для этого всем так нужен пиксельперфект :)
Ну а поповоду вылизывания каждого пикселя, я как то думал что именно для этого всем так нужен пиксельперфект :)
Что, так часто требуют верстать под мобильники?
более того — зачастую заказывают только мобильную версию. Ситуация когда обычный сайт у клиента давно есть, а теперь он хочет чтоб вёрстка и на айфончике красиво открывалось.
В таких случаях конечно делается отдельная вёрстка, т.к. пытаться только стилями, не меняя порезки сделать мобильную версию из старого чужого говнокода нерационально.
В таких случаях конечно делается отдельная вёрстка, т.к. пытаться только стилями, не меняя порезки сделать мобильную версию из старого чужого говнокода нерационально.
Да… довольно. На аутсорсе цена верстки под дестопы от 9$ до 15$ в час под мобильники от 30$ в час но со знанием дела… Да и потом, посмотрите на мир реально, планшеты, Андроидфоны, Айфоны… вы думаете это не придет и к нам?
Статья -однозначано избранное. Must have для любого верстальщика.
# Ещё хуже – чересчур детализированные глобальные стили. Например a {font: italic 10px Tahoma;} /* Ненависть! Ненависть! НЕНАВИСТЬ!!11 */ Потом приходится переопределять стиль ссылок для каждого блока.
А если глобально не указать, разве не будете для каждого блока писать стили ссылок? Или пусть будут синенькие?
А если глобально не указать, разве не будете для каждого блока писать стили ссылок? Или пусть будут синенькие?
для ссылок глобально укажите цвет и всё.
параметры шрифта они наследуют от родителя и ссылка не будет выглядеть в тексте инородно.
А где необходимо (в меню; внутри какого-то блока например сайдбара) — уточните стиль, задайте особые параметры если необходимо.
параметры шрифта они наследуют от родителя и ссылка не будет выглядеть в тексте инородно.
А где необходимо (в меню; внутри какого-то блока например сайдбара) — уточните стиль, задайте особые параметры если необходимо.
Собственно мне проще делать 2-мя путями, либо для всего
body задать body {font: 90%/170% Aller, Arial, Verdana;} либо сделать спец класс .planetext {font: 90%/170% Aller, Arial, Verdana;} Потому что стандартный Arial не всегда и не для всех рулит, особенно сегодня, в мире просто дурдом с @font-face :)
Спасибо!!! Полезнейшая вещь!
еще деталь — правила адресации ресурсов — картинок, цсс, js
приятно видеть в статье сеошные тремины!)
еще деталь — правила адресации ресурсов — картинок, цсс, js
приятно видеть в статье сеошные тремины!)
Не скажу что это супер-эталон, но много полезного есть. Хотя и есть то с чем можно поспорить.
буду рад замечаниям, они делают статью лучше и повышают собственные скилы.
Сомневаюсь, конечно, как-то измените свой чек-лист из-за одного хабра юзера. Максимум можем развести холивар. Всё же.
Немного не согласен. Есть такие макеты, которые подразумевают по собой некую хаотичность. Как вот проверять на соответствие резиновый сайт? Ту уже на усмотрение верстальщика, и несомненно в действие вступает пункт 14.
№1. Кроссбраузерность
Если используются последние версии нормальных браузеров, то почему уведомление о неподдержке будет появляться только у IE6. Почему бы сразу не в IE7? Ведь глюки у IE6 и IE7 очень схожи.
Потом у вас не сказано про цвет. Имхо, лучше номер цвета писать $ffffff, вместо $fff.
Ещё иногда бывают проблемы с загрузкой фона у элементов. Пожалуй, это единственный случай где желательно описывать отдельным стилем такие параметры как background-color, background-image, background-position и background-repeat вместо одного background.
Про :focus вот верно сказали, кстати.
№0 Соответствие макету
Расположение блоков должно быть 1:1 по сравнению с макетомНемного не согласен. Есть такие макеты, которые подразумевают по собой некую хаотичность. Как вот проверять на соответствие резиновый сайт? Ту уже на усмотрение верстальщика, и несомненно в действие вступает пункт 14.
№1. Кроссбраузерность
Если используются последние версии нормальных браузеров, то почему уведомление о неподдержке будет появляться только у IE6. Почему бы сразу не в IE7? Ведь глюки у IE6 и IE7 очень схожи.
Потом у вас не сказано про цвет. Имхо, лучше номер цвета писать $ffffff, вместо $fff.
Ещё иногда бывают проблемы с загрузкой фона у элементов. Пожалуй, это единственный случай где желательно описывать отдельным стилем такие параметры как background-color, background-image, background-position и background-repeat вместо одного background.
Про :focus вот верно сказали, кстати.
для резиновых сайтов тоже ведь рисуют макеты. проверять на соответствие нужно под разрешение макета.
Доля IE7 пока ещё не так мала, чтоб совсем с ней не считаться. А поддержка стандартов в 7-ке гораздо получше.
Чем запись вида #ffffff лучше сокращенной #fff?
В чём смысл прописывать стили background отдельно? background-color сработает вне зависимости от того прописан он отдельным свойством или внутри background.
Доля IE7 пока ещё не так мала, чтоб совсем с ней не считаться. А поддержка стандартов в 7-ке гораздо получше.
Чем запись вида #ffffff лучше сокращенной #fff?
В чём смысл прописывать стили background отдельно? background-color сработает вне зависимости от того прописан он отдельным свойством или внутри background.
Видимо не правильно выразился. Имелось ввиду не именно #fff (белый) или #000(чёрный), а любой другой цвет.
Почему отдельно? Не помню точно на каком именно браузере, но был пару раз глюк то ли с позиционированием фона, то ли с повторением. Но он решился разделением этих параметров. С тех пор как бы всегда прописываю отдельно.
Почему отдельно? Не помню точно на каком именно браузере, но был пару раз глюк то ли с позиционированием фона, то ли с повторением. Но он решился разделением этих параметров. С тех пор как бы всегда прописываю отдельно.
>Все ссылки должны как-то реагировать на :hover
многие забывают также прописать :active и :focus — для клавиатуры и тач-скринов (которые не генерируют событие hover, в результате вид ссылки не меняется)
еще на ссылках меню (если оно «красивое») можно задавать :focus { outline: 0; }, чтобы пунктирная обводка фокуса его не уродовала
на обычных ссылках это не желательно — юзабилити и аксессибилити портятся :)
многие забывают также прописать :active и :focus — для клавиатуры и тач-скринов (которые не генерируют событие hover, в результате вид ссылки не меняется)
еще на ссылках меню (если оно «красивое») можно задавать :focus { outline: 0; }, чтобы пунктирная обводка фокуса его не уродовала
на обычных ссылках это не желательно — юзабилити и аксессибилити портятся :)
IE 6 — это до сих пор ~10%, а JavaScript отключен у 1%, так что решайте, что поддерживать, а что — нет
кстати, css-ресет — это плохо, в битриксе, например, админка херится (только давайте без холиваров про битрикс)
А что тут холиварить… не хочешь ресет делать не делай.
Забыл основную мысль сказать: нельзя говорить что ресет это плохо только из-за одного Битрикса. ИМХО!
вообще-то у админки обычно свой отдельный css, не связанный с продакшеном.
нет возможности — ну и не делайте там ccs reset.
нет возможности — ну и не делайте там ccs reset.
CSS-ресет — это всегда хорошо для верстальщика. Гораздо ближе к стандартам все браузеров. Интересно сколько времени займёт у верстальщика кроссбраузерная вёрстка без него?
+1
Я раньше непонимал смысла css-reset — зачем «все базовые стили мы сотрёт до основанья, а затем...», зачем? Считал что надо просто сразу прописать все стили для всех элементов.
Писал, дополнял, смотрю, много получается, начал оптимизировать, выносить повторяющиеся стили в отдельные правила… И шо вы таки думаете? Смотрю — css-reset получается :)
Я раньше непонимал смысла css-reset — зачем «все базовые стили мы сотрёт до основанья, а затем...», зачем? Считал что надо просто сразу прописать все стили для всех элементов.
Писал, дополнял, смотрю, много получается, начал оптимизировать, выносить повторяющиеся стили в отдельные правила… И шо вы таки думаете? Смотрю — css-reset получается :)
согласен, с оговоркой, цсс ресет — плохо, если не восстановили ожидаемое поведение элементов со сброшенными стилями (например отсутствие отступов ломет li ol/ul)
Статья хорошая только в одном не соглашусь.
body.contacts div#content div#content-text h1
body.contacts div#content div#content-text div.entry
body.contacts div#content div#content-text div.entry div.somenamedblock
За такое просто нужно бить по рукам, потому что вложенность селекторов не должна быть больше 2-3х уровней и лучше всего вообще не использовать теги и привязываться только к классам. Иначе это сильно уменьшает производительность обработки css. Исследование на эту тему делал Виталий Харисов.
body.contacts div#content div#content-text h1
body.contacts div#content div#content-text div.entry
body.contacts div#content div#content-text div.entry div.somenamedblock
За такое просто нужно бить по рукам, потому что вложенность селекторов не должна быть больше 2-3х уровней и лучше всего вообще не использовать теги и привязываться только к классам. Иначе это сильно уменьшает производительность обработки css. Исследование на эту тему делал Виталий Харисов.
Спасибо, убрал теги из примера.
Но для обычных сайтов эти доли секунды абсолютно не критичны, а читабельность кода повышается. Вы же не будете БЭМ на небольших и средних сайтах использовать? :)
У highload свои законы, там и семантика будет лишним тормозом.
Но для обычных сайтов эти доли секунды абсолютно не критичны, а читабельность кода повышается. Вы же не будете БЭМ на небольших и средних сайтах использовать? :)
У highload свои законы, там и семантика будет лишним тормозом.
Если использовать эту систему с умом и доработать под свои нужды то она сильно упростит жизни при верстке даже не очень больших сайтов из 3-4 макетов. Ну а на 20-30 это просто спасение.
Если где то по макетам используется элемент идентичный по смыслу и немного изменяющийся или вообще не меняющийся внешне, я могу его вставить в любое место страницы на любом макете и буду уверен что он не подхватит еще какие то стили прописанные глобально. И в таких случаях верстка превращается в собирание конструктора:)
>>Но для обычных сайтов эти доли секунды абсолютно не критичны
Почему не стремиться сделать свою работу на все 100%?
Тем более что кроме скорости рендеринга вы получаете довольно мощную систему которая просто упрощает жизнь и ускоряет разработку. А слова про читаемость вообще спорны
вот пример с реального проекта:
.list_terms{}
.l_t_item{}
.l_t_item:first-child{}
.l_t_hline{}
.l_t_text{}
Мне кажется читабельность у данного кода лучше, но конечно это мое субъективное мнение.
Если где то по макетам используется элемент идентичный по смыслу и немного изменяющийся или вообще не меняющийся внешне, я могу его вставить в любое место страницы на любом макете и буду уверен что он не подхватит еще какие то стили прописанные глобально. И в таких случаях верстка превращается в собирание конструктора:)
>>Но для обычных сайтов эти доли секунды абсолютно не критичны
Почему не стремиться сделать свою работу на все 100%?
Тем более что кроме скорости рендеринга вы получаете довольно мощную систему которая просто упрощает жизнь и ускоряет разработку. А слова про читаемость вообще спорны
вот пример с реального проекта:
.list_terms{}
.l_t_item{}
.l_t_item:first-child{}
.l_t_hline{}
.l_t_text{}
Мне кажется читабельность у данного кода лучше, но конечно это мое субъективное мнение.
Был неправ, покаялся: delka.name/blog/2013/04/bem-otkroveniya-prinyavshih-veru/
Добавил пояснения какие ошибки валидации допустимы
- добавил про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.
- добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea.
Отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями.
- Добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS),
- необходимости вписывания в экран моб. устройства,
- заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css,
- поправил пример где в рекомендации встречался длинный каскад,
- упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
Давольно структурировання информация тема очень широкая и интересная. Как начинающий я много узнал и теперь начинаю понимать в какую сторону надо двигаться.
Добавлено требование использования препроцессоров и рекомендация использования систем сборки.
Я имею в виду саму идею использования мета-языков над CSS.
Не уверен стоит ли делать сноску вида «а вообще вы можете генерить css не только с помощью sass». Чеклист ориентирован на устоявшиеся практики (во многом он систематизировал их и помог им стать стандартом де-факто), практики, которые можно рекомендовать всем и в первую очередь — менеджеру/клиенту, который проверяет работу или выставляет это чеклист как гайдлайн. Код на sass будет легко развивать и поддерживать.
То что существуют постпроцессоры и их рекомендовано использовать — в чеклисте есть.
Не уверен стоит ли делать сноску вида «а вообще вы можете генерить css не только с помощью sass». Чеклист ориентирован на устоявшиеся практики (во многом он систематизировал их и помог им стать стандартом де-факто), практики, которые можно рекомендовать всем и в первую очередь — менеджеру/клиенту, который проверяет работу или выставляет это чеклист как гайдлайн. Код на sass будет легко развивать и поддерживать.
То что существуют постпроцессоры и их рекомендовано использовать — в чеклисте есть.
На GitHub подробней раскрыт пункт №12 «плохо»/«хорошо»
Пункт №12 — актуализирован:
— про хаки в css и как писать код для разных браузеров
— что пустые блоки не запрещены, а нежелательны и их можно заменить на псевдоэлементы
— добавлено пояснение, что нужно просто юзать Normalize для того, чтоб были базовые стили элементов (а не голые стили от CSS Reset)
— объяснил что «последовательное уточнение стилей» — это для текста и не касается стилей для блоков (там используем БЭМ)
— уточнил что не просто плохо, а нельзя вешать стили на селекторы вложенных элементов, без классов. И что именно вложенных элементов, а не одиночных, а для одиночных нужно юзать блок .b-text
— переформулировано без описания технологий пожелание о разбиении верстки на шаблоны
— добавлена рекомендация складывать иллюстрации в отдельную папку.
Пункт №12 — актуализирован:
— про хаки в css и как писать код для разных браузеров
— что пустые блоки не запрещены, а нежелательны и их можно заменить на псевдоэлементы
— добавлено пояснение, что нужно просто юзать Normalize для того, чтоб были базовые стили элементов (а не голые стили от CSS Reset)
— объяснил что «последовательное уточнение стилей» — это для текста и не касается стилей для блоков (там используем БЭМ)
— уточнил что не просто плохо, а нельзя вешать стили на селекторы вложенных элементов, без классов. И что именно вложенных элементов, а не одиночных, а для одиночных нужно юзать блок .b-text
— переформулировано без описания технологий пожелание о разбиении верстки на шаблоны
— добавлена рекомендация складывать иллюстрации в отдельную папку.
Актуализировал список исключений для CSSLint
Актуализировал рекомендации по оптимизации скорости загрузки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чек-лист вёрстки. Что можно отдавать клиенту, а что надо переделывать