Как стать автором
Обновить

Комментарии 244

Статья супер. Сам правда никогда не любил верстать. Но может если следовать советам из данной статьи, на выходе будет получаться хороший продукт, и я полюблю это дело.
Думаю, следовать этим советам следует прежде всего, если ты изначально умеешь верстать неплохо. А если верстальщих плохой, то советы эти вряд ли спасут. А пост неплохой, согласен, некий такой чеклист перед завершением всех работ.
Я старался написать чек-лист так, чтоб его критерии были формальными, а вёрстку можно было воспринимать как чёрный ящик.
Например «Корректная работа при вбивании реального текста» — её можно организовать и написал килобайты css-правил и несколько выверенных строк. Для клиента результат будет один. Верстальщику же, сталкиваясь с такими требованиями, проще научится делать качественный код.

С плохими верстальщиками дела не имел, но проекты написанные с соблюдением этих требований, ещё неопытными джуниорами, получились вполне качественными, мы время от времени вносим правки в старые проекты — желания «всё выкинуть и переписать» не возникает.
поправьте
через-чур -> чересчур
PRS -> GPRS
роуминт -> роуминг
аплетом -> апплетом
В целом неплохо, только под конец теряется общая структурированность.
Такой список уже пора и автоматизировать :)
поправил, спасибо

автоматизировать было бы круто! призываем гуру-тестировщиков в тред :)
Ещё должна быть PHP-валидация формы.

Какая блин php валидация на ВЕРСТКЕ?
Я так понял речь идет не только о верстке, а в целом, что следует проверять при создании сайта перед сдачей его заказчику. Потому что например
>Все страницы должны быть слинкованы и проверены на наличие битых ссылок.
этого верстальщик не обязан делать, имхо.

Статья хорошая, Delka все по-делу расписал! Редко встретишь код, соответствующий требованиям (рекомендациям) что здесь описаны.
Я придерживаюсь мнения что самые простые вещи на php, например запрограммить отправку письма, верстальщик должен уметь. Бывают маленькие сайты, на которых всё статично, и php используется только для порезки на шаблоны и отправки письма с формы контактов.
Одно дело — мнение о том, что должен уметь верстальщик (знать то он желательно должен куда больше), но совсем другое — то, что к верстке это не имеет ровно никакого отношения.
воспринимайте это как чек-лист frontend'a в том числе.
Ну, я бы не стал. Фронтенд — слишком обширная отдельная тема.
НЛО прилетело и опубликовало эту надпись здесь
Аналогично, 404 ошибка при вёрстке?
Речь о маленьких, почти статичных сайтах, которые в продакшен запускает верстальщик, а не программер.
Смотрите плиз мой коммент выше.
пхп-валидация наверное имеется ввиду проверка введенных значений :)

Автору статьи — Спасибо!
кэп?
Не забывайте только все эти требования оформить в виде ТЗ при заказе верстки, а то большинство ваших желаний отнюдь не обязательны по умолчанию.
конечно! ради того и писалось.
у нас в компании это — внутренние стандарты и требования для аутсорсеров.
В моей компании подобное не только не является внутренними стандартами, а вообще не рассматривается кем-либо, кроме меня, всерьёз. Это печально…
на самом деле, все правильно сказал)
Великолепная статья!
Маленькое дополнение: IE8 в режиме совместимости с IE7 != IE7. На хабре даже была статья с описанием, что за чудо этот режим совместимости, и как с ним бороться.
Да, есть небольшие отличия, но в целом, они почти идентичны. Во всяком случае если в режиме совместимости с IE7 возникает баг — он будет возникать и в реальном IE7.

А, глядишь, пройдёт ещё годик и похороним 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:
<IfModule headers_module>
Header set X-UA-Compatible: IE=edge
</IfModule>

ну или прямо в коде сайта отправлять этот header
На счёт .htaccess как-то не подумал. А вот по поводу IE=edge мне пока рано думать. В IE8 всё правильно отображается пока (собственно ничего специально под него не дорабатывал). А вот в IE9 проверять будет проблема — надо Windows 7 ещё найти.
Отличная статья — объёмистый материал в понятном и сжатом виде. Автору спасибо.

Автору:
— Следует указать, что необходимо проверять, как отображается страница при загрузке на малых скоростях (хотя бы 64 КБ). Очень часто в такие моменты пользователь видит разъехавшуюся верстку.
Throttle — плагин FF. Позволяет ограничить скорость браузера, тем самым спытать web-проект на разных скоростях интернет соединения.
большое спасибо, дополнил статью.
Выполнение всех этих пунктов увеличат себестоимость вёрстки как минимум в 2-4 раза. Не каждый заказчик согласится заплатить за вёрстку столько же сколько и за дизайн :) Но чеклист явно пригодится…
не вижу связи. в статье разобран подход к верстке, как к процессу. аналогично, как группа программистов договаривается о стандартах при создании кода.
Но вот работу программиста не всегда можно проверить, а вооружившись описанным в статье инструментарием среднестатистический заказчик начнет требовать соблюдения от вёрстальщика всех стандартов и правил при этом платя такую-же сумму как и раньше.
среднестатистический заказчик изначально имеет право требовать соблюдения стандартов верстки. другое дело, что
а) большинство заказчиков этим никогда не станут заморачиваться;
б) руководитель любой более-менее серьезной конторы должен сам требовать от своих подчиненных соблюдения стандартов. в данном случае, верстки. иначе и до гуано-кода докатиться можно;
в) будет происходить некоторый отсев при взаимодействии «среднестатистического заказчика, вооруженного описанным инструментарием» и представителей конторы-разработчика. с тем же успехом, отсев происходит по вопросам стоимости работ, срокам выполнения и т.д;
Одно дело стандарты, а другое pixel perfect вёрстка и оптимизация её загрузки в браузере, микроформаты тоже кстати можно отнести больше к гиковсим-фишкам, нежели к стандарту де факто.
Уж поверьте, я вёрстаю куда лучше вас.
НЛО прилетело и опубликовало эту надпись здесь
Вы наверное работаете в конторе которая берёт за проект от 300 тыс. рублей. Хочу вас обрадовать, не каждая фирма может позволить себе такие излишества.
Я думаю вёрстальщик бы с радостью потратил своё время на то, чтобы сделать качественный продукт и положил бы его в портфолио, если бы ему за это заплатили деньги и дали достаточно времени, а не как обычно у нас в стране бывает — «к вчера».
совсем нет, от $1000. Бывают и по $10000, но afaik средний проект в районе $5000.

сроки для вёрстки:
  • титулка — два дня
  • внутряк — полдня
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Забавно, у нас этим тестировщики занимались, а тут сам ПМ верстку чекает. Скажите, вы, наверное, еще и бэкенд весь проглядываете?
так точно. у нас маленькая фирма, а римт работ довольно спокойный.
Думаю, у каждого приличного ПМ, на основании предыдущего опыта, уже есть сформированный чек-лист или сервис в запасе, типа launchlist.net/
Отличная статья.
IE 6 можно проверять через IETeester
Вы ради интереса проверьте на родном IE6 и в IETeester — это небо и земля. Так что IETeester не выход.

Удачное решение от Adobe, где можно посмотреть отображение сайта во всех браузерах
target="_blank"

С удивлением обнаружил, что такого атрибута нет в xhtml1-strict
Вообще, читал, что использование этого атрибута не является «правильным», так как нарушает привычный паттерн — юзер просто хочет перейти по ссылке, а тут у него вдруг новое окно/вкладка открывается. Если я хочу новую вкладку, то я жму колесиком (если знаю о таком поведение), а _blank ломает шаблон.

Если уж придерживаться такого требования для внешних ссылок, то желательно тогда добавить еще одно: для таких ссылок как-то показывать, что ссылка внешняя (иконкой например).
вы правы, но уж больно не нравится клиентам, когда уходят с их сайта по какой-нибудь ссылке a-la «BBB Accredited Business».

да, желательно выделять такие ссылочки иконкой «внешняя ссылка», дополнил.
Клиент, который тешит себя ложными мыслями, которому больше нечем удержать посетителей, кроме как открытие внешних ссылок в новой вкладке, не вызывает восторга.
Некоторые браузеры подсвечивают, что будет открыто в новом окне (вкладке). Например, Konqueror подрисовывает иконку при наведении на такую ссылку.
Его вернули в HTML5.
Это я тоже обнаружил.

Только я ещё хотел намекнуть, что там есть ещё нижнее подчёркивание.
Ненависть ко всем, кто использует target="_blank"!
Все браузеры открывают страницу в новой вкладке при щелчке на колёсико (в крайнем случае можно выбрать новую вкладку в контекстно меню).
Колесика может не быть, а открытие контекстного меню долгим. Мне нравится как гугл в поиске сделала — открывать ссылки в поиске или нет задаётся в настройках. Жаль что ко всем ссылкам на гугле это не относится.
Всегда думал, что большинство пользуются Ctrl+click… но что-то в последнее время в сети встречаю описания только с колесом. Ну неудобно на него нажимать — слишком легко прокручивается и ссылка может уползти.
Вот Ctrl+Click не разу не пользовался, уж проще, через ПКМ. Но вообще я говорил выше о девайсах, где ни мыши нормальной, ни клавиатуры :)
DOCTYPE: HTML5
Зачем нужно: это современный стандарт, XHTML – тоже хорошо, но HTML5 – актуальней, да и это модный тренд сейчас.
Проверка: открываем исходный код страницы, первая строка должны быть <!DOCTYPE HTML>

Это минимально необходимый доктайп, чтобы IE не свалился в Quirks, а не HTML5
На что вы намекаете?
спасибо, забыл самую главную причину то написать, настолько привык к тому что правильный doctype дожен быть, что уж и позабыл что его могут вообще не указать и не знать зачем он :)

дополнил.
Плохо когда нет постепенного уточнения стилей, а стиль выписывается для каждого элемента отдельно

Здесь частично не соглашусь. Плохо — только при плохом подходе. Например, если у каждого такого уточнения стоит разный 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" == невалидность хтмла
В HTML5 target="_blank" снова разрешили.
Грамотно, нравится, но так из проекта в проект?
Рассматривались ли возможности автоматизировать проверку, не говоря уже о процессе верстания?
Вёрстку автоматизируем за счёт максимального повторного использования кода. После вёрстки каждого нового проекта мы добавляем в коллекцию готовых решений те блоки, которых там ещё нет.

Автоматизировать проверку бы очень хотелось, будем искать гуру-тестировщиков.
Вместо пиксел-перфекта пользуйте ModularGrid (http://habrahabr.ru/blogs/webdev/109988/). В разных браузерах макет может выглядеть по-разному.
Всё так. Ох уж этот пиксел-перфект — жечь его надо каленым железом. Очень часто PM требуют его, тратя драгоценное время разработчиков на статисфакцию никому ненужных пожеланий, когда они могли бы заняться чем-нибудь более полезным для проекта. Я о тех клинических случаях, когда приходят нервные письма с кучей скриншотов и гневными возгласами «Катастрофа! В FF шрифт больше на полпиксела! И вот input, у формы, не такой как в макете.» Особенно если речь про большие проекты, к презентационным сайтам это не относится (идиотизм пиксел-перфект в этих случаях вполне оправдан).
Согласен, многим не хватает здравого смысла в этом вопросе.

Попросите вашего PM'а сверстать в HTML страницу своего резюме что ли =)
Стараюсь не сталкиваться с подобными PM.
Конечно во всём нужно знать меру.
Тем более обязанность ПМа — не затягивать сдачу проекта, тратя время (а значит и деньги фирмы) на вылизывание каждого пикселя.
спасибо, дополнил
Да, и ещё, на главной странице ставить название компании в h1 можно только с разрешения оптимизатора.

Вообще, в h1 лучше запихнуть текст ключевого запроса для сайта, или название ключевой услуги. Название компании прекрасно себя чувствует в strong, например.
СЕОшников забыли спросить, что ставить в h1 а что в strong :-)
Вы правда думаете, что мы верстаем сайты чтобы верстать сайты?
Я думаю, что большинство СЕОшников имеют довольно смутное представление о html и неимеют никакого представления о семантики. В первую очередь нужно помнить, что html — язык разметки web-документа, а не инструмент для СЕО
Мне кажется, что в первую очередь нужно помнить о цели создания сайта — ну это так, лирика. Я сдаюсь перед вашим упорством =)
спасибо.
буквально вчера озадачился таким чеклистом
спасили кучу времени
1.1, 1.2 — не профессиональная аргументация
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)
спасибо. дополнил.

В версии для печати и должен печататься только контент, без иллюстративной графики. У нас там по сути картинок нет, ну кроме фото товаров у клиента.
2.2 Упоротая секретарша копипастит тексты из Word’а в визиг — это надо предусматривать, и чинить, и инструкцию секретарше писать, и теги лишние фильтровать где можно :)

Прекрасно лечится jevix'ом и избавляет от лишней головной боли верстальщикам
оно то да, и в идеальном мире программеры не выводят картинки не того размера в шаблон, а визиг в админке — textarea где можно вбить только текст :)) вот, только бывает по всякому, хороший верстальщик должен делать свой код пуленепробиваемым.
Спасибо. В Избранное.
Ну и вопрос, в каких ценовых пределах находится создание сайта, удовлетворяющего этим требованиям?
Я верстаю по данным стандартам. Цена примерно в 3 раза выше рыночной. Но заказчики готовы платить, даже очень.
Под рыночной я имею ввиду среднюю цену на фриланс-сайтах.
Заказчики платят за отсутствие головной боли в дальнейшем…
А вот по поводу html5 я не согласен. Слишком мало браузеров его нормально понимают, т.ч. пока верстаю по старинке в XHTML Strict.
Не-ве-рю! В смысле, не верю, что верстаете именно по всем стандартам. Чего только стоит сделать правильный сайт под WCAG/WAI/Section 508. Именно правильный для людей с ограниченными возможностями, а не для валидатора. Таких сайтов единицы на весь интернет.
Тут вы несомненно правы, это очень сложно, и за это оглашается дополнительная цена, если заказчик потребует.
$200-250 титулка, $50-60 внутряк.
SEOник отдельным пунктом у вас?

потому что про микроформаты, карты и т.п. — я лично это считаю обязательным и очень важным, всегда делаю сам и от других требую, а кто-то считает баловством (категорически не согласен, есть печальные примеры)

у вас очень грамотно, если вы действительно всё это внедрили в процесс разработки, — то честь вам и хвала

отдельная благодарность за статьи, за то, что делитесь знаниями (я не знал 1 или 2 пункта всего, но они довольно интересные), за то, что дорабатываете посты и активно обсуждаете в каментах (конструктивно)

ваши посты читаю, заношу в избранное, распечатываю, внимательно анализирую
и потом ещё возвращаюсь за новыми комментариями
спасибо,

Извиняюсь, не совсем понял вопрос «SEOник отдельным пунктом у вас?»

Про организацию отдела вёрстки планирую сделать доклад этой весной/летом.
У вас всё хорошо написано именно с точки зрения SEO.

Некая изначальная семантичность/оптимальность входит в базовый набор услуг и оговаривается в брифе/ТЗ?

К верстальщикам есть требования SEO-грамотности, знания важных основ?

Вы это как-то специально упоминаете в рекламе? (IMHO имеете право, если приведённый checklist — каждодневная, обычная практика)
1. да входит.
2. наверно благодаря тому что пишут качественный код, оно само собой получается, знают что к чему, сами задумываются как лучше разметить, перенести ли контент в начало страницы (кстати! забыл-то упомянуть, сейчас допишу!) и т.п.
3. да, упоминаем.
думаю что пункт о показе банеров даже с включенным адблокером лучше не упоминать
Отличная, полезная статья. Несколько замечаний:

Есть несколько специфичных моментов. Вы пишете на 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.
Только если вы «Яндекс».

Всё это обнаружилось беглым пробегом, уверен, что если поискать и попридираться, можно найти ещё. Но, прошу прощения, у меня тут не школьные каникулы :-)
> Пункты 8, 9, 10.
>Только если вы «Яндекс».

Вот так и остаются некоторые пользоватеи с Интернетом, в котором работает один Яндекс.
А, ну давайте теперь и поддержку IE5.5 обязательной делать. Иначе что, у них тоже один Янекс работать будет?
IE устарел, отсутствию js есть другие причины.

Прочитайте статью внимательнее. Там всё есть.
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. Конечно в первую очередь это семантика документа, дополнил. Но согласитесь — стили для разных устройств можно написать и для сайта где кроме span class ничего не используется.

8,9,10 — полезно всем. Дополнил что если уж впадлу делать — так хоть уведомление через noscript выведите.
>Я считаю не стоит цепляться за старое, доля IE6 уже меньше 4%.
Доля IE7 IE8 = 25%. Они поддерживают HTML5?
graceful degradation для IE8 и тем более IE7 допустим.

некоторые наиболее востребованные css3-свойства весьма клёва эмулируются через pie.htc (там через VML, всё кошерно).
1.2 По сути сейчас HTML5 поддерживает более-менее нормально только WebKit. Остальные должны игнорировать незнакомые элементы (вместе с содержимым). Всех пользователей пересаживаем на Хром(иум) и Сафари?
всё зависит от конкретных фич, которые вы используете в конкретном проекте, что именно из html5 и css3 вам нужно. обычно не так много то и надо :)

смотрите плиз коммент чуть выше про graceful degradation.
Я про всякие section, article, header, footer и т. п. Свойства-то понятно, что если даже игнорируются, то не смертельно.
Ну вот и хочется эту семантику нести не в классах или ид, а в элементах, раз уж html5.

По-моему, дело одним IE не ограничивается, но это ладно, какие-нить хаки наверное есть, хотя что этот скрипт делает не понял, уж очень всё минимизировано, а вот насчёт гугла-яндекса вообще не уверен, парсят ли они html5 или нет.

Вы назвали статью чушью основываясь на своем субъективном мнении, а оспаривая, сами соглашаетесь с некоторыми выводами автора. Вы не там чушь увидели ;)
Возвращайтесь, когда школьные каникулы начнутся :-)
>HTML5 – актуальней, да и это модный тренд сейчас
HTML5 уже принят в качестве стандарта? Тыркните где об этом можно почитать.
Наверно этот комментарий не ко мне?
Очень много спорных заявлений. По поводу тренда и моды на доктайп, рекомендую посмотреть небольшой доклад Вадима Макеева Доктайп. Точка.
> IE7+ (для IE6 выводится уведомление о неподдержке и предложении скачать другой браузер, но с возможностью всё-таки просмотреть сайт)
> Safari 3 (в нём «размытые Mac'овские» шрифты, они чуть большего размера, из-за этого бывает вылазят баги) + последний Safari

Странные требования. Что-то мне подсказывает, что Safari 3 в разы меньше, чем IE 6
Ну, чтобы «поддерживать» Safari 3 никаких особых дополнительных усилий не надо, а вот IE6 — жесть.
Вообще-то, дизайнер/верстальщик должен следовать не мантре «мне так удобнее» или «это жесть», а хотя бы таблице graded browser support

Правда, в первой четверти этого года IE6 переходит в C-grade, так что уже неважно
Ну вот о том и речь, никто и не говорит, что с IE6 вообще не надо заморачиваться, просто должно выводиться предупреждение о том, что браузер устарел и советовать его обновить.
В идеале верстальщик должен уметь поддерживать всё хоть как-то еще встречающееся — и IE6, и Safari 3. Но нормально объяснять клиенту (или ПМ-у, а тот — клиенту… нутыпонел) стоимость поддержки каждого динозавра.
Уметь — да, конечно, должен!

Я отчасти понимаю ваше желание поддерживать 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. Вкусно и питательно!
Вчера вот верстал под хром, слои фона очень понравились.
Страничку на float-блоках делать не надо. Я правильно понимаю что вы задавали почти всем блокам float: left? они тогда схлопываются до своего содержимого и друг за дружкой идут, похоже на ячейки таблицы. Это очень плохо, очень.

Да, рюшечки и селекторы :)

CSS3 gradients, rgba, box/text-shadow, border-radius — на самом деле очень большой шаг вперёд — прописать несколько правил, а не нарезать картинки и мучатся с их позиционированием.

Нет, не всем. Все float-блоки у меня собраны внутри div с фиксированной шириной. Раньше там вообще таблицы были =)

Рюшечки css3 с приличной деградацией в IE6-8: imperion.kirilloid.ru/beta/
3 картинки + один спрайт на все иконки + спрайт с подписями к «лампочкам».
ЗЫ: индикаторы «врут» — ошибки нет )
Это всего-лишь способ проверить сглаживание шрифтов «как на Маке», дополнил статью пояснением.
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 на мобильнике.
хихи, расскажи Макееву про Оперу
уже рассказывал :)
а что ж поделать, я сам Оперу очень люблю, но ни что не идеально
Симулятор Opera Mini — это Java-приложение, требует соотв. плагин. Java в обычных системах это вроде бы не бог весть какая редкость. Так что это не похоже на проблему. По меньшей мере, стоит тестировать в эмуляторе Opera Mobile, хотя соотношение пользователей Mini/Mobile — 85/15%.

В любом случае, даже если подргузится handheld.css вы не вспомните про ограниченный JS, особенности рендеринга и потенциальные проблемы. Так что разумнее будет открыть страничку с симулятором, а не держать на машине 9.64.
ага, спасибо, отредактировал статью.
с версткой статьи все ок, но вот сетка поехала ;)
Вы имеете в виду что некоторые картинки меньшего размера по ширине? они некрасиво смотрелись в полную ширину, а я увы не нашел ничего лучше чем уменьшить их размер чтоб было симпатичней.

А если вы про отступы у заголовков, списков — я боролся с хабра-парсером за красоту как мог :)
да картинки можно думаю все убрать только скачут, читать мешают, можно было пиктограммами html5 го все оформить, только размер их уменьшить раза в три
спасибо,
уменьшил размеры картинок, сделал все одинаковыми слева
В целом хороший список, отражает, скажем так, «Best Practices» для работы с версткой, хотя тут и не все пункты и подпункты касаются именно верстки.

Однако на практике некоторые пункты несут определенный «overhead» в объеме работ, и нужно уже смотреть по конкретным требованиям, а не пытаться сделать каждую и каждую страницу максимально доступной (accessible). Ну типа круто бы, конечно, чтоб даже при выключенном мониторе отображалась надпись «Включите монитор для полноценной работы сайта», но сделать — сложно, и не всегда нужно.

Я бы добавил еще по пунктам:
0. Не забываем, что есть еще весьма полезная штука — SuperPreview, особенно для тестирования в IE.

3. В большинстве (абсолютном большинстве) я бы использовал или WYSIWYM-редактор, или простой текст с Markdown вместо этих TinyMCE, FCK и прочих. В любом случае — стили должен задавать дизайнер сайта, а не пользователь.

15. > «Расширение страниц на сайте всегда должно быть ».html", а все созданные странички изначально должны иметь расширение .php, быть порезаны на шаблоны и работать через mod_rewrite."
А зачем там вообще какое-то расширение. Ну и, конечно, ".php" совсем не «должны» :)

Ну а заодно,
16. Лого на главной должно быть активным и вести на главную же страницу. Вопреки расхожему мнению, лого-ссылка — это не обязательно лишь ссылка, а некоторый контекстный элемент с очень удобным поведением — на всех страницах это ссылка на главную, а на главной — это основной инструмент «рефреша» страницы. Особенно актуально для часто-обновляемых ресурсов.

Ну и, в заключение добавлю, что львиную долю проверки перечисленного в топике можно автоматизировать.
Хотя я и 10 лет «верстаю» — и половины наверное не делаю. Это ужасно.

«Skype-плагин не должен ломать вёрстку» — FFFFFFUUUUUUUUUUUU я бы на манагера накинулся наверное скажи он мне такое)))))) «Эти суки лезут в код ломают его а я должен теперь из-за них работать дополнительно!!!!»)
Думается, когда проекты стоят не 20-40 килорублей, а 1000-1500, такие вещи выслушиваются и делаются.
это вы про проекты из РосПила говорите?))))))

вообще-то конечно да, я сам сторонник «заплати налоги и спи спокойно»
Если используем html5 доктайп, то можно ли использовать тэги, которые есть в html5, но нет в html 4? :)
да конечно
Статья хорошая, но немного спорная. И чуть смешано с программной частью разработки сайта.
Если же вставляем хаки для 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 в конец страницы, для быстрой загрузки страницы.
Я как раз за Conditional Comments. Просто настолько привык к ним, что воспринимаю их как само собой разумеющееся, а в примерах приводил лишь «как не должно быть», спасибо, дополнил. Про html5boilerplate.com в курсе)
Со многим согласен. Некоторые вещи из выше написанного не знал. Конечно присутствует мое дилетантское ощущение — что слишком уж многое надо проверять.
Огромное спасибо за расшаренный боевой опыт!

P.S.
Удивлен что ПМ должен выполнять работу тестера. Но как ни странно — на практике инициатива чек листов обычно исходит именно от ПМ.

воспользуйтесь Safari 3 под win

— «маковское» сглаживание есть и в новых Safari под Windows.
Ctrl + «,», закладка Appearance, меняем Font Smoothing из установленного Windows Standart в Medium.

Как для моих глаз — сглаживание шрифтов точно такое же, как в Mac OS X. Или в Safari 3 какое-то более маковское сглаживание?
ух ты! спасибо огромное!
отредактировал статью.
Вам спасибо за отличный пост. :)
hCard — не слишком ли упрощает жизнь спамерам?
Для какихто внутренних вещей, CRM и пр., может и хорошо, но надо ли иметь hCard в каком-нибудь внешнем сайте?
у спаммеров эти адреса всё равно появятся, раз они на сайте написаны.

иметь микроформаты на сайте надо, полезно для SEO:
Всё клёво, разве что смущает указание на конкретные инструменты для проверки. Почти везде указаны Fx, PHP, SVN и всё-такое, тогда как лучше было бы или привести по несколько вариантов или ограничиться более общими фразами:
  • «Все бекапы можно вытянуть из SVN» → «Все бекапы можно вытянуть из системы контроля версий»
  • «Ещё должна быть PHP-валидация формы» → «Ещё должна быть деградация на серверную валидацию форм» (хотя я тоже против этого пункта в этом списке :)
Ну и т.п. Скажем, многие вещи, которые советуется проверять в Fx (вид без картинок, без яваскрипта) гораздо лучше делать, например, в опере — там это делается встроенными в браузер средствами, да и тот же вид без картинок «честнее». Ну а скорость загрузки и много чего ещё отлично проверяется в вебкитовском инспекторе.
спасибо, про php/svn — поправил.

про FF — старался не плодить сущности, чтоб проверка была проще, согласен что что-то наверно можно лучше проверить другим средством.
Прекрасная статья!
Еще заказчиков найти бы, готовых все это оплатить, самому было бы очень интересно.
По некоторым пунктам с вами будут несогласны гуру.
буду рад замечаниям, в споре рождается истинна :)
Просто апплодирую стоя! Очень полезная статья. Именно ради таких топиков, которые позволяют повышать свой уровень, я и хожу на Хабр. Спасибо!
Очень плохо — презентационные классы (right, red).

Объясните свою позицию. У меня всегда есть заготовки float: left/right; для случаев, когда больше ничего для элемента не нужно. Например для иллюстраций в тексте. Мне кажется, что это достаточно семантично.
ну для иллюстраций в тексте можно
Браво! Спасибо за чек-лист, все сам давно собирался сделать такой :)

Вот только я не согласен с тем, что в стилях нужно писать теги. В стилях вообще не должно быть тегов, только классы (и иногда 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
В данном случае теги i, b используются скорее как оформительские вспомогательные элементы (для допололнительных фонов, уголков или еще чего-нибудь). Для них, конечно, нет смысла задавать классы (подразумевается, что класс задается семантически осмысленной единице контента).
Когда код состоит из одних дивов, да спавнов, то перечислять тэги смысла нет, конечно. Но вот менять селектор вида
#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. под Касту — тоже классно.
>Все ссылки должны как-то реагировать на :hover
ИМХО, все ссылки ДОЛЖНЫ быть подчёркнуты (если это, конечно, не новостной сайт)
Это не исключает того, что они должны реагировать на :hover, верно?
Ну, лично я бы сказал, что скорее могут и не всегда должны. :)
(когда подчёркнуты)
Я согласен про подчёркнутость, но одно другому не помеха.
Лично я бы сказал, что реакция на :hover — это именно то действие, которое я жду от ссылки, в противном случае мне очень… некомфортно что-ли. :)
Подчёркивание очень часто некрасиво вписывается в меню и прочие навигации, которые обычно и так выделены отлично от всего остального сайта. Но вот реально бесит, когда подчёркивают то, что ссылкой не является :)
Представьте верстку под Андроид с разными dpi, под iPhone учетом ориентации окна(горзонтально или вертикально) а потом советуйте этот дурацкий PixelPerfect. За последние, примерно, 7 месяцев работы уже забыл что это такое расположение блоков 1:1. Прибъете размеры шрифтов в пикселях, и соотвественно отступы и посмотрите на разных андроид устройствах и iPhone/iPod/iPad — в целом статья классная, все гуд, но вот на счет пиксель перфект, и вообще прибивания чего-то гвоздями в верстке… я бы несоветовал.
конечно, при смене ориентации соответствия 1:1 макету уже не получится.
но это ведь не значит что вообще не стоит сравнивать вёрстку с макетом? разве есть проблема расположить блоки как на макете? чтоб у них были такие же размеры, отступы.

ясное дело что при изменениях контента, размеры блоков могут меняться (по высоте например), но это нормально, адекватный ПМ не должен затягивать сдачу проекта, тратя время (а значит и деньги фирмы) на вылизывание каждого пикселя.
Считаю что да. Я часто для своих проектов, делая верстку сталкивался с такой проблемой что на 1280-800 все классно а на 1024-768 не так уже смотретиться. И я искренне рекомендую всем клиентам(своим) что бы они прислушались и использовали относительные размеры и т.д. потому как важна то информация, если по части дизайна, и качество кода, если по части верстки. Но это имхо, и то часто приходиться прибивать гвоздями :) правда потом не редко клиенты просят переделать…

Ну а поповоду вылизывания каждого пикселя, я как то думал что именно для этого всем так нужен пиксельперфект :)
спасибо что обратили внимание на эту двусмысленность, дополнить статью пояснением.
Что, так часто требуют верстать под мобильники?
более того — зачастую заказывают только мобильную версию. Ситуация когда обычный сайт у клиента давно есть, а теперь он хочет чтоб вёрстка и на айфончике красиво открывалось.
В таких случаях конечно делается отдельная вёрстка, т.к. пытаться только стилями, не меняя порезки сделать мобильную версию из старого чужого говнокода нерационально.
Да… довольно. На аутсорсе цена верстки под дестопы от 9$ до 15$ в час под мобильники от 30$ в час но со знанием дела… Да и потом, посмотрите на мир реально, планшеты, Андроидфоны, Айфоны… вы думаете это не придет и к нам?
Хех, тут за сервер-сайд бы 10$ получать ))

Не знаю, на мои сайты заходят с мобильников мизер, может ЦА не та. Аппараты-то уже пришли в принципе, но вот, по-моему, опсосы наши ещё долго будут держать мобильный интернет в чёрном теле.
Статья -однозначано избранное. 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
приятно видеть в статье сеошные тремины!)
вы имеете в виду что картинки должны быть в отдельной папке, css — в отдельной и js — в отдельной?
разумеетя так и должно быть, неужели кто-то ещё делает иначе?
спасибо, дополнил статью.
И еще как писать, точнее, с чего начинать, урлы в файлах макета:
../images/
/images/
images/
.../images/

в html, css, js файлах — везде могут накосячить (просто сделать по разному)…
/images/
Не скажу что это супер-эталон, но много полезного есть. Хотя и есть то с чем можно поспорить.
буду рад замечаниям, они делают статью лучше и повышают собственные скилы.
Сомневаюсь, конечно, как-то измените свой чек-лист из-за одного хабра юзера. Максимум можем развести холивар. Всё же.

№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.
Видимо не правильно выразился. Имелось ввиду не именно #fff (белый) или #000(чёрный), а любой другой цвет.

Почему отдельно? Не помню точно на каком именно браузере, но был пару раз глюк то ли с позиционированием фона, то ли с повторением. Но он решился разделением этих параметров. С тех пор как бы всегда прописываю отдельно.
>Все ссылки должны как-то реагировать на :hover

многие забывают также прописать :active и :focus — для клавиатуры и тач-скринов (которые не генерируют событие hover, в результате вид ссылки не меняется)

еще на ссылках меню (если оно «красивое») можно задавать :focus { outline: 0; }, чтобы пунктирная обводка фокуса его не уродовала
на обычных ссылках это не желательно — юзабилити и аксессибилити портятся :)
кстати, да, спасибо, дополнил! мы прописываем такие штуки, но в правила не внесли, теперь есть.
НЛО прилетело и опубликовало эту надпись здесь
IE 6 — это до сих пор ~10%, а JavaScript отключен у 1%, так что решайте, что поддерживать, а что — нет
меньше 5% вообще-то.
кстати, css-ресет — это плохо, в битриксе, например, админка херится (только давайте без холиваров про битрикс)
А что тут холиварить… не хочешь ресет делать не делай.
Забыл основную мысль сказать: нельзя говорить что ресет это плохо только из-за одного Битрикса. ИМХО!
вообще-то у админки обычно свой отдельный css, не связанный с продакшеном.
нет возможности — ну и не делайте там ccs reset.
CSS-ресет — это всегда хорошо для верстальщика. Гораздо ближе к стандартам все браузеров. Интересно сколько времени займёт у верстальщика кроссбраузерная вёрстка без него?
+1

Я раньше непонимал смысла css-reset — зачем «все базовые стили мы сотрёт до основанья, а затем...», зачем? Считал что надо просто сразу прописать все стили для всех элементов.

Писал, дополнял, смотрю, много получается, начал оптимизировать, выносить повторяющиеся стили в отдельные правила… И шо вы таки думаете? Смотрю — css-reset получается :)
Эволюция.
согласен, с оговоркой, цсс ресет — плохо, если не восстановили ожидаемое поведение элементов со сброшенными стилями (например отсутствие отступов ломет li ol/ul)
конечно после reset'a нужно выставлять базовые стили для всех элементов. reset — лишь оптимизация сброса умолчаний, чтоб меньше кода писать при прописывании дефолтов.
Статья хорошая только в одном не соглашусь.

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 свои законы, там и семантика будет лишним тормозом.
Если использовать эту систему с умом и доработать под свои нужды то она сильно упростит жизни при верстке даже не очень больших сайтов из 3-4 макетов. Ну а на 20-30 это просто спасение.

Если где то по макетам используется элемент идентичный по смыслу и немного изменяющийся или вообще не меняющийся внешне, я могу его вставить в любое место страницы на любом макете и буду уверен что он не подхватит еще какие то стили прописанные глобально. И в таких случаях верстка превращается в собирание конструктора:)

>>Но для обычных сайтов эти доли секунды абсолютно не критичны
Почему не стремиться сделать свою работу на все 100%?
Тем более что кроме скорости рендеринга вы получаете довольно мощную систему которая просто упрощает жизнь и ускоряет разработку. А слова про читаемость вообще спорны
вот пример с реального проекта:

.list_terms{}
.l_t_item{}
.l_t_item:first-child{}
.l_t_hline{}
.l_t_text{}

Мне кажется читабельность у данного кода лучше, но конечно это мое субъективное мнение.
Приятно признавать что ошибался в прошлом. Это самая наглядная иллюстрация «роста» как специалиста и личности.
Добавил пояснения какие ошибки валидации допустимы
  • добавил про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.
  • добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea.
Отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями.
  • Добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS),
  • необходимости вписывания в экран моб. устройства,
  • заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css,
  • поправил пример где в рекомендации встречался длинный каскад,
  • упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
Давольно структурировання информация тема очень широкая и интересная. Как начинающий я много узнал и теперь начинаю понимать в какую сторону надо двигаться.
Добавлено требование использования препроцессоров и рекомендация использования систем сборки.
НЛО прилетело и опубликовало эту надпись здесь
Я имею в виду саму идею использования мета-языков над CSS.
Не уверен стоит ли делать сноску вида «а вообще вы можете генерить css не только с помощью sass». Чеклист ориентирован на устоявшиеся практики (во многом он систематизировал их и помог им стать стандартом де-факто), практики, которые можно рекомендовать всем и в первую очередь — менеджеру/клиенту, который проверяет работу или выставляет это чеклист как гайдлайн. Код на sass будет легко развивать и поддерживать.

То что существуют постпроцессоры и их рекомендовано использовать — в чеклисте есть.
На GitHub подробней раскрыт пункт №12 «плохо»/«хорошо»
Пункт №12 — актуализирован:
— про хаки в css и как писать код для разных браузеров
— что пустые блоки не запрещены, а нежелательны и их можно заменить на псевдоэлементы
— добавлено пояснение, что нужно просто юзать Normalize для того, чтоб были базовые стили элементов (а не голые стили от CSS Reset)
— объяснил что «последовательное уточнение стилей» — это для текста и не касается стилей для блоков (там используем БЭМ)
— уточнил что не просто плохо, а нельзя вешать стили на селекторы вложенных элементов, без классов. И что именно вложенных элементов, а не одиночных, а для одиночных нужно юзать блок .b-text
— переформулировано без описания технологий пожелание о разбиении верстки на шаблоны
— добавлена рекомендация складывать иллюстрации в отдельную папку.
Актуализировал список исключений для CSSLint
Актуализировал рекомендации по оптимизации скорости загрузки.
Добавил требование поддержки Retina.
Дополнил «18. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.