Пользователь
11 августа 2010 в 11:34

Разработка → Требования к html-верстке

1. Верстка, аутсорсинг и технические задания


Верстка — относительно независимый этап веб-разработки и, к примеру, в маленьких веб-студиях часто — это первый кандидат на аутсорсинг в условиях ограниченных трудовых ресурсов.
Так сложилось, что мне часто приходилось отдавать эту работу субподрядчикам и, несмотря на предполагаемую однозначность результата, иногда верстальщики меня очень удивляли. Причем чаще — в негативном смысле.

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

И этот момент игнорируется. Часто это происходит из-за предположения, что трудозатраты на написание детального ТЗ в сумме со стоимостью аутсорсинга не окупаются сэкономленным временем штатного верстальщика. В конце концов, верстка — это ведь не так уж сложно — думает рядовой project менеджер. И, как правило, это действительно прокатывает, *хвала человеческому интеллекту*, профессиональные верстальщики в большинстве своем ограничивают буйство экспериментаторского духа и заранее знают, какие технические решения в верстке могут вызвать у заказчика геморрой не столь адский, чтобы забанить верстальщика, но все же исключающий радость и восхищение прекрасным html-макетом.

Тем не менее, вероятность факапов, как показывает практика, не столь мала, чтобы этим можно было пренебречь.

А основное заблуждение здесь в том, что детальное ТЗ — это сложно и трудоемко. Какие-то специфические требования к макету в любом случае приходится описывать, а вот на общие требования и рекомендации, как правило, забивают.

2. О, велика моя скорбь!


Я недавно получил макет, который менеджеры отдавали на аутсорсинг и просто не знал, смеяться мне или плакать. Если бы не мне предстояло интегрировать этот макет в систему шаблонов CMS, я бы наверно все-таки смеялся.

Табличная верстка и стили, не вынесенные в CSS файл и стандартный дримвиверовский скрипт для подсветки кнопок даже не воспринимаются как недостатки после того ада, который я увидел. Все поля ввода были вставлены внутрь тегов label, засунутых в отдельные формы, причем при попытках как-то привести это в человеческий вид, вся верстка разваливалась. CSS классы имели кириллические названия, причем не осмысленные, а вида «.стиль1,.стиль2». Большинство элементов форм стилизировались каким-то мало известным и до ужаса кривым скриптом на jQuery, некоторые элементы имели одинаковые ID и между ними был JS код, оперирующий как раз этими элементами и получающий их по ID, и верх маразма — это применение в конце документа метода jQuery.сss чтобы задать стили, которые ну совсем ничто не мешало просто прописать в CSS файл. А еще хедер сайта вместе с кучей ссылок (шрифтом Tahoma и без сглаживания) был сделан одной картинкой, на которую наложены элементы MAP и AREA. Не буду больше травмировать вашу психику описанием фейлов в этом замечательном макете, т. к. было их там еще бессчетное количество.

Картинка для устрашения html-верстальщиков В общем, поверьте, товарищи, это был ппц, который к тому же подкрался практически перед самым дедлайном.

Происшествия такого вот характера побудили меня опубликовать список требований и рекомендаций, которые будут полезны как людям, отдающим макеты на html-верстку, так и собственно верстальщикам.

Вы можете переработать эти рекомендации и дополнить ними свое типовое ТЗ на верстку. Многие вещи из перечисленных вполне очевидны, но вы можете извлечь profit из того, что все они собраны в одном месте. Некоторые пункты (к примеру требования к поддержке браузерами или используемым скриптам) для разных контор специфичны, но я не буду далее писать расплывчатых фраз, чтобы этот списочек можно было легко скопипастить и заточить под свою специфику работы.

3. Требования и рекомендации


1. Кроссбраузерность
Сайт должен нормально работать в IE7+, FF3+, Opera9+, Safari4+, Chrome последней мажорной версии (или в зависимости от условий договора с клиентом и года, в котором вы читаете эту статью).

2. Всегда описывайте цвет фона для body даже если он белый.

3. Если используете CSS хаки, комментируйте, что это и для какого браузера, а лучше используйте css_browser_selector.js. Заботьтесь о верстальщиках, которым придется работать с этим макетом после вас.

4. Названия классов и id должны по смыслу соответствовать применению
например, header, menu, footer, news

5. Просьба разделять основные html блоки комментариями. Примерно так:
<!--—BEGIN FOOTER -->
<!--—END FOOTER -->

Это нужно для создания из сверстанного html макета шаблонов для CMS, после чего комментарии будут удаляться.

6. Не пренебрегать возможностью использовать GIF/PNG с 8-битным альфаканалом вместо PNG-24, где это возможно.

7. Все что можно сделать без Javascript, делать без него.

8. Если Javascript кода много — нужно его выносить в отдельный файл. Обработчики событий тоже лучше отделить и объявлять в отдельном файле.

9. Если это еще не оговорено с заказчиком, предварительно оговорить, какие JavaScript библиотеки вы планируете использовать при верстке макета, чтобы потом не оказалось, что при верстке использовался, к примеру, PrototypeJS, а заказчик планирует в обязательном порядке внедрять на сайт jQuery.

10. Для резиновых макетов обязательно должна быть задана минимальная и максимальная ширина.

11. Если в Т.З. не сказано другое, макет обязательно должен помещаться без горизонтальных скроллбаров в развернутое на весь экран окно браузера при горизонтальной составляющей разрешения экрана 1024px, а если позволяет размер макета, то и 800px.

12. В папке с изображениями не должно быть картинок, не использующихся в верстке. Если что-то исключили из верстки или переделали — не забывайте удалять уже ненужные картинки.

13. Для всех элементов, которые могут содержать текст различной длины, который должен быть вписан в одну строку (например, для кнопок или заголовков, если в дизайне не предусмотрено, что они могут занимать больше одной строки), обязательно задавайте CSS свойство white-space:nowrap.

14. CSS файл должен быть разбит с помощью строк с комментариями на блоки по функциональному назначению, например:
/* ___________1. Сброс CSS____________________*/
/* ___________2. Типовые элементы____________*/
/* _______________2.1. Залоговки______________*/
/* _______________2.2. Ссылки________________*/
/* _______________2.3. Элементы форм_________*/
/*___________3. HEADER (Шапка сайта) __________*/
/*___________4. FOOTER (Подвал )_______________*/
/*___________5. SIDEBAR (Справа)_______________*/

Как именно структурировть стили — вопрос немного холиварный, но главное — как-то это делать.

15. Если сдача верстки производится более чем одним этапом (например, верстальщик отправляет страницы по одной, или если ему возвращаются на доработку уже сверстанные страницы) и вы не используете систему контроля версий для верстки, исполнитель должен в обязательном порядке прикрепить файл с описанием изменений в макете примерно такого содержания:
  • Добавил новые картинки в папку img,
  • Картинки btnHome.jpg и btnFeedback.jpg уже не нужны, можно удалять
  • Изменил html-код в секции файла anketa.html
  • Добавил в конец файла main.css новые стили (начиная с .form_row и ниже).

16. Оговорить, в какой кодировке должен быть html-макет. CSS и JS файлы должны быть в той же кодировке, что и макет, иначе вероятность долгой и утомительной охоты на баги критически возрастает.

17. Если в макете присутствует JS, изменяющий DOM — внимательно следить, чтобы все корректно работало в Опере, т. к. этот замечательный браузер при нажатии на кнопочку назад страницу не перезагружает, а отдает закешированный документ, причем очень важный момент: документ не просто закешированный, а еще и с учетом всех модификаций DOM, которые были выполнены с помощью JS

18. Не забывайте прописывать cursor:pointer для кнопок, сделанных не с помощью input. Если вы не знаете, будет на эту кнопку повешен обработчик событий с помощью JS или это будет ссылкой, лучше в любом случае использовать тег <a>.

19. Если вы делаете обработку событий при нажатии на ссылки, следите за тем, чтобы обработчики событий возвращали false, или же используйте href='javascript:void(0)' вместо популярного href='#', чтобы страница не скроллилась вверх.

20. Верстайте формы правильно: метки полей должны находиться в тегах label, имеющих правильно заполненный атрибут for. Предусматривайте при верстке форм элементы для вывода ошибок валидации и стили для неправильно заполненных полей. Если это не предусмотрено в т.з. и дизайне, обязательно обсудите это с заказчиком.

21. Если в макете используются нестандартные шрифты, обязательно оговорите, можно ли элементы с нестандартным шрифтом делать картинками, если нельзя — обсудите, с помощью какой технологии будет реализовано их отображение (sIfr, Cufon, etc.)

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

23. В макетах, где высота страницы зависит от контента (а таких, как правило, большинство), предусматривайте, чтобы футер был прибит к низу браузера при отсутствии/малом количестве контента, если не оговорено обратное.

24. Если макет не проходит 100%-ную html-валидацию, постарайтесь по крайней мере делать так, чтобы использование невалидного кода было оправданно. Не стоит факапить валидность верстки только потому, что «мне так нравится» или «так получается короче»

P.S.


Надеюсь, этот списочек требований и рекомендаций будет вам полезен! Если есть конструктивные мысли, предлагайте в комментариях, чем его можно дополнить.
Виталий Степаненко @nayjest
карма
0,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (296)

  • +10
    Обычно стили не структурирую, но дописываю родительский элемент, и сортирую тоже по ним. Пример:

    #header span{color:white;}
    #header .button{margin:5px; padding:5px;}
    #content a{color:blue;}
    #footer .copyright {font-size:80%;}

    В одну строку написано для наглядности, обычно разворачиваю
    • 0
      Имелось ввиду, ближайший уникальный родительский элемент. Если в div#header содержится div#menu, то такая запись
      #menu a{font-weight:bold;}
      лучше чем
      #header a{font-weight:bold;}
      и даже лучше чем
      #header #menu a{font-weight:bold;}
      • +8
        Не стоит по-моему давать id меню навигации. Будете печальны, когда надо будет его дублировать где то еще на странице.
        Практически везде стоит использовать классы.
        ID это элементы форм (для label) и гарантировано уникальные элементы, с которыми нужно будет работать скриптово.

        Что касается ближайшего уникального родительского элемента, то тут вы полностью правы.
        Верстка должна состоять из набора блоков, разделенных в идеале по их семантическом наполнению.
        • +1
          div#menu я указал для примера. Точно также я редко в стилях указываю к tagName, использовать классы действительно лучше, так как привязываешь события к элементам с соответсвующим классом, и даже если div.menu_item вдруг станет li.menu_item, в скриптах ничего менять не придется, а в стилях разве что самую малость.
        • –1
          Ну как сказать, гарантированно уникальные элементы, в общем-то тоже неплохо с id живут (#header, #content, #footer). Зрительно быстрее распознаются.
          • НЛО прилетело и опубликовало эту надпись здесь
            • +3
              Или вдруг, вам, к примеру, потребуется еще один тэг body. Не смейтесь, я такое лично видел, штук пять на странице было.
              Не должно быть такого «вдруг», каждый элемент изначально уникален или же нет. Если уникален — присваивайте id, не уникален — класс.
              Все равно не могу представить ситуацию, когда нужно клонировать #content, #header или #footer. Приведите пример
              • +1
                конструктор шаблонов, где нужно внутри конструктора рисовать превью страницы
              • НЛО прилетело и опубликовало эту надпись здесь
              • –1
                Вы как с луны свалились. «Вёрстка независимыми блоками» вам ни о чём не говорит?

                vitaly.harisov.name/article/independent-blocks.html
      • +3
        обе записи плохи с точки зрения производительности, лучше всего
        .header_menu_link {font-weight:bold}
        или на худой конец
        .menu .link{font-weight:bold}
        • –2
          С точки зрения производительности, очевидно, лучше так и только так:

          #id {}
  • –3
    спасибо! все правильно
  • –3
    все по делу
  • –4
    по пункту 2:
    самим верстать нужно, а не искать за гроши левого фрилансера, который накуярит непонятно чего перед дедлайном.
    это проблема мелких веб-студий, которые экономят на верстке и это сказывается потом на их имидже
    • +6
      На самом деле если есть уже проверенный фрилансер-верстальщик, то для небольшого объема работ держать своего не вижу смысла.
    • –10
      Либо юзать p2h.com или вот наш аналог markuper.com
      • +3
        markuper.com капец, разработчики интерфейсов…

        зашел — почитал, стало интересно, а где прайс? где хоть какието контакты и хоть что то кроме текста? О__О
        • –22
          Если чесно, это я так себя пропиарил — етно Мы. Занялись таким делом, даже ка кто на хабре писали. Все только руки не доходят сделать калькулятор на сайт да портфолио повесить, так как хотим сделать все очень красиво, и чисто с точки хрения кода — сами думаю понимаете:). Впринципе если инетерсно по прайсу, в личку напишите, я Вас проконсультирую. Мало ли когда пригодиться.
          • +6
            как же вы зарабатываете деньги, если собственным сайтом отпугиваете клиентов?
            • 0
              В основном за счет личных связей с промо студиями(они обычно работают с флэшом), но иногда у них бывают заказы на обычные html сайты. Вот тут и Мы :)))) А что конкретно Вас отпугивает?
              • 0
                Дак отпугивает отсутствие тех же самих «контактов» и «портфолио»
                • –3
                  Ну вобщем как и все говорят. Если честно, наверно зря я дал линк, как на сайт продающий услугу, он конечно не выглядит, нету времени на доделать, хотя и осталось чуть. Пока есть заказы, вот мы особо и не заинтересованы в доделке. Большое спасибо за коммент.
                  • +7
                    а вы уроки на завтра уже сделали?
                    • 0
                      А почему Вас это так волнует?:)))
                      • 0
                        Ругать вас будут. Жалко.
                    • 0
                      Какие уроки в августе? =) Каникулы ведь отличная пора для своего маленького старт-апчика =)
              • +1
                нет контактов и прайса, хотелось бы портфолио…
                и еще сайт начисто убивает Chrome и Safari
                — вообщем — низкий класс
                • 0
                  Хотелось бы узнать какого рода убийство происходит. Так как мы не заметили убийства(с нашей точки зрения), сейчас даже заходил с htc desire(webkit)- все было прекрасно. А как профи посомтрите верстку(сам код), тоже интерсен Ваш коммент. Заранее спасибо.
                  • 0
                    падает при попытке нажать на линк.
                    при загрузке странице виден текст — который ВДРУГ исчезает и появляется заставка
                    • –1
                      graceful degradation в действии:))) приходится и такое объяснять, ессесно оно появляется, это если у вас js будет отключен, поэтому так мелькает. Причем это только на быстром вэбките, если скажите как от такого избавиться, это будет положительно.
                      • 0
                        Про #js не слышали?
          • +2
            "(клиентские стороны богатых веб-приложений)"
            Фраза убила насмерть. Богатые веб-приложения, ага.
          • 0
            Не забудьте еще за вычитку текста, когда дойдут руки доделать сайт: там немало очепяток и других помарок — лексических и орфографических.
    • +2
      Это всегда вопрос цены. Если внешний верстальщик выдаст тот же результат за меньшие деньги, в чём может быть резон использования своего верстальщика?
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Ещё раз повторюсь: при «том же результате». Доступность, загруженность, очное общение — как раз те вещи, которые позволяют повысить качество результата. Но они же, волей-неволей, повышают реальную стоимость работы. Ибо это и амортизация оборудования и арендная плата за помещение и налоговые/пенсионные выплаты по зарплате и необходимость оплаты времени простоя и т.д. и т.п.

          Короче, оценивается соотношение цена/качество.

          Иногда получается реально дешевле в финале иметь несколько фрилансеров на «чёрной работе» и, например, одного специалиста, который всё сведёт воедино, отшлифует, подправит, если надо. Говоря про дешевизну в финале имею в виду и расходы на подгонку к рабочему варианту получаемый от фрилансеров результат. Очень, очень часто бывает выгоднее использовать внешних разработчиков.

          И именно для того, чтобы их использование было максимально эффективным (читай — потребовались бы минимальные усилия для допиливания/доработки) и нужны эти правила.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Ну на самом деле Вы посмотрите на какое сообщение я отвечал и к чему именно относились мои возражения :) Я против категоричного утверждения, что верстать надо только самим а не искать более дешёвый вариант. Имхо практически любой девелопмент — часть некоего коммерческого проекта. А бизнес — он стремится снижать цену и повышать прафит.

              Так что если удастся использовать более дешёвую рабочую силу, застраховавшись от рисков (хотя бы при помощи правил или использования БЭМ) — то так и стоит поступить.

              ЗЫ: спасибо за ссылку, кстати, любопытненько.
    • 0
      Мелкие веб-студии как раз обычно сами верстают, а проблема аутсорс-фрилансеров – это проблема студий со штатом 20+ человек, когда поток проектов большой, и внутренних ресурсов не всегда хватает по дедлайнам – гораздо выгоднее сформировать аутсорс-команду и сливать работу им, а не пытаться вывозить всё на себе.
  • +52
    По первому пункту — сайт должен РАБОТАТЬ в IE6, но никак не выглядеть в нем так же, как в других браузерах. Пользователь хочет красоту — пусть обновляет IE или устанавливает другой браузер.
    • +3
      Поддерживаю. Тоже не правлю неправильные отступы и выравнивания в IE6, только ошибки скрипта и редкие случаи, когда элемент страницы вообще недоступен (наехало что-то сверху, селекты любят так делать)
      Хотя, как я убедился, многие вещи без проблем дожили до IE8, да и еще несколько прибавилось.
    • 0
      Это уже решать заказчику. Конечно, не обращая внимания на IE6, верстать на много приятнее и лучше, в том числе и для современных браузеров. Но бизнес–цели, зачастую, важнее.
    • 0
      Да, давно пора уже прекратить поддержку этого старья!
      IE6 ещё используют верстальщики, считающие, что есть пользователи, использующие IE6 :)
  • +5
    + старайтесь не использовать кириллические комментарии в CSS. чревато, особенно при дальнейшем переходе проекта на utf ;)
    • +2
      Предлагаю обсудить этот момент.
      Если кодировка CSS файла такая же, как HTML и в теге link для подключения CSS она тоже задана правильно атрибутом charset, то я так понимаю, никаких проблем не возникает.

      Возможно стоит лучше в пункте 16, где речь идет о кодировках, упомянуть об атрибуте charset тега link?
    • +38
      Старайтесь не переводить проекты на UTF, а сразу делать в нём.
      • +4
        Собственно да, как бы в первый (ладно, второй) пункт программы надо бы добавить требование использовать utf-8. И только если CMS его вдруг не поддерживает или ещё что… лучше выкинуть такую CMS а требование оставить)))
    • 0
      Бред.
  • 0
    спасибо, полезно да же для себя
  • +4
    Я бы добавил ещё обязательную проверку на CSS и HTML валидаторе куда-нибудь в начало, чтобы не было забытых обязательных атрибутов у тегов и просто неподдерживаемого синтаксиса. Для большинства проектов — настоятельная рекомендация полной валидности, для остальных — минимальное количество ошибок, и, как и написано у вас в последнем пункте, оправданных ошибок.

    А так всё очень по делу, спасибо!
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      да-да, и поменьше использовать каскад %-)
  • +4
    Всё верно написано. У нас даже есть своя внутренняя документация, чтобы все верстальщики писали однотипно.
    • +1
      Спасибо! Очень хороший пример внутренних правил
  • –13
    Забавно, мы так и делаем :) По умолчанию
    • –7
      Да-да, каюсь )
      • –3
        Привет конкурентам:)))))
        • –7
          А минусы от конкурентов? :))))))
          • –6
            Ребята, вы молодцы, чесно. Очень понравился дизайн вашего сайта — легкий, что надо. Удивили Ваши цены, у нас в среднем стоит 4000р макет за главную. Правда я так понял вы работаете как физические лица, а мы как юрики, отсюда и наши цены. Название себе прикольное выбрали, мы тоже долго думали:))) так что впринципе понимаем некий труд. Из минусов, довольно слабенький калькулятор у Вас, а мы сейчас какраз свой доделываем. Я вот пока писал коммент подумла, что с Вашими ценами, мы можем работать как партнеры:))))
            • –1
              Пишите в личку :)

              А калькулятор, лично я за простоту, свои задачи он решает.
              Хотя я думаю, пару пунктов мы добавим.
            • +1
              4тыр за верстку главной???
              черт возьми, а я все ломаю голову, сколько же за верстку брать…
              не, ну у нас столько точно не заплатят…
              но вообще — дали повод задуматься)
              • –1
                Ну я буду чесным, среди своих думюа не стоит скрывать:))) Тут вс епросто если ты рабоатешь как Юр лицо, тебе ндао платить за офис и бугалетра как минимум плюс зп верстальщикам + зп себе, любой бизнес если не имеет 100% накрутки не будет успешен, либо иметь огромный оборот(чего у нас точно нет). Поэтому в среднем верстальщик получает около 2000 ща униклаьный макет, а вообще то даже и все 2500, мы своих Верстаков не обижаем.
                • +1
                  да эт я все понимаю, сам учредитель студии)
                  просто у нас профиль по-ширше, и студия не берет такие мелкие заказы на всякую верстку.
                  а мне вот иногда предлагают поверстать на досуге, и я ломаю себе голову, сколько за это брать…
                  опыта много, знаю что сверстать могу любой макет (ну разве что не какой-то вообще нереальный), все валидно и кросбраузерно (кроме ИЕ6, манал я его, нервы дороже. хотя, конечно, и под него можно, но за отдельные деньги) и т.д. и т.п.
                  но вот во сколько все это оценить — это проблема…
            • 0
              А по вашему сайту, тяжеловат. Да и дизайн если честно, так себе, если быть конструктивным. В Хроме действительно тяжеловато работает.
              • –3
                ))) Да ладно, сам по себе дизайн хорошенький — легковатый такой. Конечно видно что дизайнер делал на отъебись, так как мелочи не доработаны. А концепт как мне кажется хороший. Но это все IMHO.
    • +7
      Я не поленился, сделал карту кликов для главной страницы:



      Скажите, почему самый привлекающий внимание элемент оформления — простая статичная картинка. Хот-бы интерактив какой-то сделали.
      • 0
        оп. а подскажите плиз, как сие сделать?
        • +4
          В фотошопе, кисть с большой дистанцией (про карту кликов это была шутка) :) А вообще, есть сервисы, которые ставят скрипты и делают такие карты.
          • +2
            Шутки шутками, но вы чертовски верно угадали :)
      • 0
        Этот вопрос мне задавали тысячу раз если честно :)
        На самом деле интерактив там будет. С цветом и типом фона.
        • +4
          у вас если кликнуть в пункт меню, ползунок прыгает к нему.
          логично было бы сделать, если ползунок передвинуть к пункту меню, то он кликается.
          а то сейчас болтается без дела, как говно в ополонке… все его дергают, а толку никакого…
          • 0
            Это его временный action, пока не реализовали функционал выше.
        • 0
          Сделайте там на каком-то небольшом участке пасхалку в виде купона на скидку. Крутишь эту штуку и в какой-то точке всплывает окошко: «Нашему клиенту пытливому от разработчиков благодарных великая скидка предоставляется!»
  • +1
    Для пункта 15 отлично подходит система контроля версий, которую, правда, использовала лишь одна контора, с которой я работал.
  • +4
    Как по мне, оптимизация изображений — вообще очень важная составляющая верстки. Понимать, когда сохранять в jpg (и до какой степени его сжимать), когда в png-8 или png-24 — значит, сохранять драгоценные килобайты странички. Веб-страничка — как девушка, большой вес должен быть чем-то оправдан.
    • +2
      Размером сисек?
  • +4
    По пункту 20 я бы не согласился. Вставлять элемент формы внутрь тега label вполне допустимо и не нарушает стандартов, более того, позволяет избавиться от атрибута for и, как следствие, атрибута id у элемента формы.
    • 0
      То что вставка элементов input внутрь label позволяет избавиться от for — не знал, спасибо.

      В принципе, как вариант, можно делать и так. Но это немного ограничивает дальнейшую свободу в стилизации форм, да и при табличной верстке форм (от которой все-таки желательно уходить) такой вариант неприменим.
      • 0
        Ну я думаю, где какой подход применять, зависит от ситуации. Просто я хотел указать на то, что запрещать такой вариант вообще нецелесообразно.
        • –2
          Ваше указание совершенно справедливо. Ставлю +1 Вам в карму.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Уточню, что не работает в IE ниже 7-го.
        Но, я лично забиваю на это, если это не интранет-приложение рассчитанное на IE 6.
  • +3
    Сомневаюсь, что стоит нанимать верстальщика, которому нужно все это объяснять.
    • +1
      К сожалению, можно предположить, что если не объяснять, то у нас не будет появляться новых верстальщиков.
      А старые достойные давно уже заняты делом :-)
    • –1
      Пусть всяк верстальщика такого нанимает,
      который понимает.

                                        (подражание Козьме Пруткову)
    • 0
      Человек обычно идёт по пути наименьшего сопротивления. И верстальщик тоже может попытаться решить какие-то проблемы наиболее «простым» (читай быстрым) способом, даже если результат будет заведомо плох. Ибо если нигде не обговорено иное, то можно и «схалтурить». Например, структуризация CSS файлов — дело нужное для дальнейшего девелопмента, но не имеющее явного внешнего отображения. Потому, если сроки поджимают, а требование не сформулировано явно — его можно и не выполнять. Даже зная, что так сделать — не совсем правильно.
  • –1
    хороший список. правда в списке упоминаются все моменты высокого уровня. дополню из своего опыта:

    — css классы должны быть в определенной иерархии. например нельзя использовать *{margin:0; padding:0}, можно #header *{margin:0; padding:0}. Таким образом мы избежим будущих коллизий при установки новых модулей.

    — имена картинок должны быть в нижнем регистре, и без кириллицы, и без пробелов

    — имена css классов должны быть в нижнем регистре, и без кириллицы, и без пробелов

    — пункты навигации(меню, pager...) должны выделяться исключительно добавлением определенного класса в элемент. например: ".selected", ".hover"

    — в тег «a» всегда должен входить тег «span», пример: <a href="/path/path/" class="ico_home"><span>Link</span></a>.
    Нужно для контроля стиля всей ссылки и текста по отдельности. В примере указан случай навешивания иконки на ссылку, но подчеркивание должно быть только у текста

    — фоновый цвет иконок должен быть прозрачным. Очень часто при незначительных изменениях дизайна, цвета иконки остаются без изменений.
    • 0
      Воздержитесь от использования *, заклинаю! Поиск элементов во многих браузерах идет спава налево, т.е. при записи #header * {...} сначала будут найдены все элементы DOM, а из них отсортируются все те, которые принадлежат #header. Представляете что будет с браузером на слабой машине при большом документе?
      • –1
        этот пример был приведен исключительно в контексте о иерархии
      • 0
        ничего особо страшного не будет. иб оищутся на элементы для правила, а правила для элементов
        • 0
          Зависит от размера таблицы стилей
    • +1
      Спасибо за советы, но по большему счету рекомендации, которые вы предлагаете, могут быть использованы в качестве внутренних правил конкретной организации для штатных верстальщиков к примеру, а я старался писать о максимально общих моментах. Я вот не принуждаю верстальщиков использовать underscore вместо любимого горбатого регистра, т. к. не вижу для этого никаких объективных причин глобального характера. А вот внутри организации конечно же верстальщикам стоит договориться, как именовать классы.

      Пункт про навигацию мне понравился больше всего.
    • 0
      «В примере указан случай навешивания иконки на ссылку, но подчеркивание должно быть только у текста»
      a img { text-decoration: none; }

      Кроме того, обязательно включать span в a неверно с идеологической точки зрения. Потому, что представление начинает диктовать семантику.
      А подталкивает вас к этому, видимо, использование «звездочки».
      • 0
        иконка навешивается на «а» с помощью css. я не вижу в моем примере использования тега img. и вообще стараюсь использовать тег img как можно меньше. стараюсь делать дизайн макета по максимуму контролируемым при помощи css
      • 0
        согласен про a+span
        иконку, думаю, лучше вешать на ссылку определенного класса через background без лишних элементов
  • 0
    «Все поля ввода были вставлены внутрь тегов label»

    А тут что не так? К label пишется for если input не внутри. А в остальных for опускается. Тут нет ничего плохого
    • 0
      Плохое в том *читайте далее*, что каждая такая конструкция была вставлена еще и в отдельную форму, причем при попытке убрать лишние формы, верстка разваливалась.

      А то что вставка элементов input внутрь label позволяет избавиться от for — не знал, спасибо
    • +1
      К сожалению, это не работает в ие, приходится делать кучу айдишников и привязывать к ним лейблы.
      • +3
        Зачем это делать, пусть пользователи IE6 прицеливаются и тыкают прямо в радио-батоны, за удобством будьте добры обновить браузер.
        • +1
          Така позиция понятна. Но тот, кто платит, заказывает музыку. Бывают требования, чтобы и в ие удобно было.
          • +2
            Ни разу не встречал подобные тонкости в требованиях, обычно указана необходимость поддержки ИЕ 6, но против graceful degradation никто никогда не возражал.
    • +1
      Соглашусь.
      Атрибут for у label сделан как раз для тех случаев, когда нельзя вложить в него input или элемент формы, связанный с ним, если не ошибаюсь.
      Но вроде бы работает криво без указания for в IE6/7.
    • +1
      да, меня тоже удивило возмущение о вставке инпутов в лейблы. это валидно и нормально. а местами очень-очень удобно, т.к. позволяет сделать инпут с подписью единым неразрывным целым, не оборачивая их в лишний блок.

      но про отдельные формы — это да…
      вообще, там такой ад описан, что я такое делал когда впервые открыл фронтпейдж лет в 16…
  • 0
    я бы еще добавил css reset
    • 0
      не всегда это нужно
      • +1
        гм… зато это в 99% избавляет от непонятных отступов в IE и Опере… особенно когда верстаешь сложные формы — тут даже не всегда и reset спасает.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Нифига :)… бордеры забыли — а бордеры очень важный элемент в формах… потом голову ломаешь почему у тебя форма в IE расползается… причем было пару случаев что даже border: 0; не помогал, но как ни странно помогало border: 0 none;
            • НЛО прилетело и опубликовало эту надпись здесь
              • +1
                Так а кто говорит об использовании чужих ОС элементов???
                Видимо у вас или нет опыта или нет проблем с одинаковостью верстки — когда то или другое появится и вёрстка формы поплывёт — советую посмотреть на свойство border — вдруг это решит ваши проблемы :).
                • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              В целях обучения, без резета полезнее.
              Если какая-то проблема лучше знать как её решить (хотя бы подсмотреть в тот же самый резет), чем всё время резет цеплять целиком.

              Просто из него в большинстве случаев требуется лишь малая доля, так как часто приходиться переопределять большинство дефолтных значений при вёрстке и то, что они сначала были сброшены, оказывается лишним.
        • +1
          Я просто про то, что у макета иногда/частенько (у кого как) приходится описывать все эти самые отступы и прочее. В таком случае получается, что сначала идут стили сбрасывающие всё в ноль, а потом определяющие нужные значения css-свойств, отсюда излишняя избыточность. Не говоря уже о том, что в резете есть ещё куча правил, которые никогда и не используются.
          • +1
            очень часто стандартные браузерские стили по-умолчанию очень сильно друг от друга отличаются… это характерно даже для разных версий ИЕ, не говоря уже про другие браузеры…

            и кто мешает из резета поубирать неиспользуемые правила — для firebug есть плагин, который позволяет отследить неиспользуемые стили. Есть и подобные сервисы — которые не зависят естественно от браузера.
            • 0
              То, что стили у браузеров разные, это не имеет значения. Так, например, отступ у какого-то элемента может стоять у них самый разный, зачем мне его сбрасывать сначала резетом, а потом прописывать нужный, когда можно сразу прописать требуемый.

              Сервисы это хорошо, но смысл моего высказывания был в том, что иногда лучше прописать нужное свойство явно, если возникает проблема, чем цеплять целиком резет.
              • 0
                Я понял вас, но очень часто верстальщик забывает прописывать такие стили — собствтенно именно «благодаря» такой забывчивости и появился reset.
                • +1
                  На самом деле часто проблема в дизайнерах=),
                  которые забывают описать стили текстов, и прочего=), а верстальщик что нашёл, то и прописал=).
            • 0
              >>>для firebug есть плагин, который позволяет отследить неиспользуемые стили
              Подскажите, пожалуйста, название
              • 0
                CSS Usage 0.2.2
                https://addons.mozilla.org/ru/firefox/addon/10704/
                • 0
                  спасибо :)
  • +2
    Все правильно, все верно, только вот мне интересно, до каких пор будет поддерживаться IE6? Что это за некрофилия? Не пора ли всем верстальщикам дружно отказаться от этого геморроя, дабы он вымер окончательно и безповоротно?
    • +1
      До тех пор, пока это в ТЗ будет прописывать заказчик. Как вариант — можно за этот пункт повышать цену.
    • +2
      Лично я за, как и все верстальщики, но это зависит не только от моих личных пожеланий.
      p.s.: некрофилия по отношению к IE6 — очень удачная метафора, улыбнуло )
      • +3
        мы вон на сайте студии подумали, и решили уже и ИЕ7 отфутболивать на заглушку с обновлением браузера: bicycle-day.com/ie.html
        Ну тут логика была примерно следующая: если на сайт зайдет «маркетолог», который не в состоянии даже браузер нормальный поставить, то работать с ним в направлении вэба (да и не только) будет невыносимо и лучше ну его в пень. Нервы дороже.
        • 0
          +1000
          правда я отфутболиваю все ИЕ ниже 7
        • 0
          кстати если можно заверните страничку в zip со всеми ресурсами )) я бы скачал…
          • 0
            на работе где-то она, а я сейчас дома…
            так просто страницу сохраните из браузера, он же подтянет и картинки и цсс
            • 0
              я так и сделал… а вот возможно начинающим будет полезно…
              • 0
                так а куда ее выложить-то?))
                • 0
                  можно внизу этой же странички дописать линк на zip «Поставь себе на сайт — Убей IE» + пример правил для .htaccess
                  • 0
                    я на нее кстати не аксесом шлю, а простым условным комментарием и редиректом
                    • 0
                      ну можно и так… но htaccess как то правильней и надежнее
        • 0
          хоть и сижу на фф, но довольно интересно почему не предлагаете оперу, зато есть сафари?
          • +4
            До тех пор пока опера не выпилит ряд очень мерзких багов в движке рендера страниц (которые тянутся уже многие годы), я никому и никогда ее не посоветую.
            Вот как только — так и сразу. Т.к. в остальном браузер очень даже.
        • 0
          Спасибо за ссылки на портативные версии, мне не пришло в голову вставлять их в заглушки.
  • 0
    Замечательно собранная подборка самых основных советов по верстке. Схоронил в избранном, благодарю.
  • 0
    Для пункта 15 — оговорить использование систем контроля версий — SVN или других.
    Для непутевых — дать ссылку на FAQ и все дела.
    В Windows — TortoiseSVN или TortoiseHG довольно простые, а на уровне commit/update использовать даже обезьянка сможет:)
    • +2
      Git лучше SVN
      • +1
        Так кто бы спорил. Но, ЕМНИП, в Git как-то не очень все тривиально.
        Я бы порекомендовал Mercurial, он проще в настройке.

        Но суть моего комментария не в этом, а в том, чтобы использовать хоть какую-то систему контроля версий.
  • +3
    Список неслишком строг.
    1. Я не вижу причин, по которым может быть принят не well-formed макет. То что он проходит валидацию — дополнительная страховка от проблем.
    2. CSS и JS всегда должны быть только во внешних файлах и никак иначе.
    3. CSS на мой взгляд лучше разбивать по файлам, а не комментариями.
    4. Описывать изменения, которые были внесены в макет в каждой итерации описывать, на мой взгляд, не оправдано. Это нужно только в случае если шаблон уже внедрен. В остальных случаях просто не стоит внедрять шаблон пока он полностью не утвержден.
    5. За п.3. надо давать по рукам! Никакого JS там где он не обязателен. Вот как поведет себя такая верстка с отключенным JS?
    6. Кодировка должна быть UTF-8. Я не вижу причин, по которым на сегодняшний день стоило бы использовать другую. По крайней мере в моих проектов я таких точно не встречал.
    7. Минимальное *и максимальное* разрешение на которое рассчитана верстка, поведение футера (липкий/не липкий) всегда стоит уточнять у клиента.

    Как то так.
    • –1
      Да… 3ий пункт совершенно верный.
      Иногда ИЕ начинает игнорировать написанное после коммента
      • +2
        не бывает такого. значит где-то есть перекрывающие стили или комментарий неправильно оформлен.
        ИЕ много чего чудит, но не надо его в таком абсурде обвинять…
    • 0
      да, все правильно.
      только п.3 спорный, все-таки с точки зрения оптимизации, они должны быть слиты. другой вопрос, что это могут сделать уже прогеры в продакшне — слить и сжать
      • +1
        Эм… стили сливаются в один файл в обязательном порядке. Но на продакшене.
        Пока верстка в процессе — их удобнее (мне) держать в отдельных файлах.
        • 0
          Мне кажется, не всегда разумно сливать их в 1 файл. Например есть общие стили, а есть дополнительные для конкретных страниц (корзины там, фильтров с списке товаров). Зачем на главной грузить лишнее? Пусть оно будет загружаться по мере необходимости. Понятно, что в сумме их должно быть не много (то есть если в процессе вы используете отдельно top-menu.css и header.css их конечно надо объединить в продакшене).
          • 0
            Ох строго говоря, естественно, надо смотреть каждый конкретный проект, смотреть где какие файлы стилей присутствуют и формировать из них на этом основании сшиваемые группы… но это уже совсем на уровне запредельном. Часто это же время лучше потратить на то что бы найдти причину массивных утечек память в ваших JS скриптах, оптимизацию серверсайда или еще что то, что даст значительно большую отдачу. В 90% случаев слить все стили в 2 файла (с фильтрами для IE и без) более чем достаточно.
            • 0
              >но это уже совсем на уровне запредельном

              Некоторые CMS/фреймворки/шаблонизаторы делают это на уровне движка:
              — в код шаблонов вставляется что-то вроде {% use_style common.css %}, {% use_style header.css %}, {% use_style menu.css %} {% use_style contact_form.css %}и т. п. только там где они нужны в коде
              — движок для каждой комбинации на лету генерирует css файл в кеше (если его ещё там нет), при этом могут удаляться комментарии и лишние пробельные символы, упаковка в gz и производить прочую «обфускацию», и подставляет его имя в link

              Основной недостаток: нельзя кешировать на стороне клиента общий для всех страниц css, для каждого нового сочетания исходных css он будет передаваться по новой. Хотя, конечно, никто не запрещает использовать один общий css традиционно в html, а странично-специфичный генерировать при обработке шаблонов (как вариант в шаблонизатор можно встроить группы css файлов, но мне такие реализации не встречались)
          • 0
            Вообще поддерживаю, но в статье я говорил о каких-то максимально общих случаях, процитирую себя: «Как именно структурировть стили — вопрос немного холиварный, но главное — как-то это делать.»
    • 0
      4. Я и рассматриваю случай, когда проект уже внедрен. Понятно, что не стоит внедрять макет, пока он полностью не утвержден, но иногда бывают моменты, когда с точки зрения менеджера проектов макет выглядит вполне нормально, а баги находятся уже на стадии внедрения.

      6. Иногда приходится работать с чужими проектами, которые вовсе не на UTF-8
      • 0
        4. Когда внедрен, то да, писать обязательно. Надо экономить время программиста.
        6. Могу только посочувствовать. Но я таких довольно давно уже не видел, слава Веаликому Раздавателю Проектов.
        • 0
          4 — вообще, да. Нормальные люди используют SVN, только их я встречаю весьма редко. (Пошел выгружать верстку на ftp поверх старой, и надеяться что ничего не напортачил нигде)
  • 0
    Вообще, для хорошего верстальщика это все уже в подсознание забито…

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

    п.21 — fontsquirrell.com, и не парить себе мозги. выдает универсальное решение

    ну а так, есть спорные моменты…

    и да, ну зачем, зачем пинать чертов ИЕ6?
    я только за это требование взвинтил бы вам цену на верстку минимм вдвое, а то и втрое
  • +1
    Спасибо за минусы :) habrahabr.ru/blogs/webdev/101464/#comment_3144657

    А если по делу, я бы добавил еще версию для печати. Как минимум, что бы не разъезжалось, при чем готовых версий довольно много.

    Но конечно, по любому, этот момент тоже обсуждается с заказчиком.

    Потом, я бы добавил min-height и max-height для textarea в WebKit. Раздражает когда, textarea ломает макет при расширении размера.
    • +1
      Мне кажется, если пользователь сам себе расширяет textarea — значит ему это надо, и я бы отрывал руки, если бы мне не дали расширить поле ввода до того размера, до какого мне нужно, пусть даже я поломаю этим макет. Это я его ломаю, а не верстальщик. Я, как юзер, привык что могу менять, не запрещайте мне этого делать!!!
      • 0
        Я имел в виду min-width и max-width если честно. Вопрос спорный, но, я смотрю по тенденциям, что даже Google в своих сервисах это практикует (только вчера видел, точно не понмю в каком именно).
        • 0
          Если задать rows и cols то меньше тех значений хром не даст уменьшить.
      • 0
        раздвинь на хабре поле слишком широко ;-)
        • 0
          Раздвинул. Заходит за правую боковую панельку и стает невидимым. Но это моя и только моя проблема. Я, как юзер, не хочу чтобы за меня решали стоит мне растягивать поле, или нет, и на какую ширину/высоту.
          • –1
            а я не хочу, чтобы у меня были проблемы из-за того, что я могу сделать обратимую гадость самому себе, пытаясь сделть хорошо
            • 0
              *необратимую
    • 0
      Кстати, resize: vertical ещё не помешает для вебкита и на будущее.
  • +1
    Спасибо,
    еще на хабре есть полезная статья как правильно писать css. Здесь
    • 0
      Хорошая статья, поддерживаю. Этим можно дополнить рекомендации верстальщикам.
  • 0
    По п.3. еще можно порекомендовать www.modernizr.com/
    Это на тот случай, если graceful degradation предусмотрено ТЗ.
    • 0
      это противоречит 7 пункту
      • 0
        Тогда уж сам мой пункт 3 противоречит 7-му пункту, но если не забывать о 9-м пункте, то это имеет право на жизнь :)
    • 0
      Спасибо, интересная библиотечка, поковыряем. По логике вещей это правильней — отталкиваться от поддерживаемых фич а не от версии браузера, но проблема в том, что помимо поддержки каких-то фич, браузеры отличаются еще и специфическими багами в вещах, которые как бы поддерживаются.
  • 0
    Оффтопик.

    Дорогие верстальщики, вас много в этой теме, плз откликнитесь те, кто верстает на 960gs (сетка, 24 колонки, 960.gs/demo_24_col.html ) и кому в целом данная статья показалась правильной.

    (всё верно, но 24-ого пункта быть не должно — всё должны быть валидным хотя бы в маркетинговых целях + можно пожелать использовать теги html5)

    если это про вас, вы это умеете — напишите мне в хабрапочту, изредка требуется такое…

  • 0
    По пункту 15: может быть попробовать использовать системы контроля версий?
  • +2
    2. не только цвет фона, но и цвет текста. и делать так каждый раз когда цвет фона меняется в дочерних элементах.

    5. зачем? можно же использовать элемент footer

    7. противоречит 3 х)

    14. лучше разбивать по файлам с соответствующими названиями и использовать автоматический сборщик типа css-suki

    15. если этапов больше одного — надо завести репозиторий. и по коммитам это всё будет видно

    16. utf-8, и нечего тут обсуждать.

    17. она не кэширует, она замораживает страницу. со всеми вытекающими.

    19. href=«javascript:// load details»

  • +2
    В добавок ко всему упомянутому, стоило бы еще сразу зафиксировать, с каким DOCTYPE делать верстку.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +3
        согласен. ибо нефиг на месте топтаться
      • 0
        Лучше пока предупреждать о верстке в HTML5. А то можно и поушам получить.
        Хотя пару проектов на html5 я сделал… и ничего. Вроде бы все довольны.
        • 0
          Ну возможно стоит просто указать «правильный» список совместимых браузеров? :)
          • 0
            У HTML5 особых проблем с совместимостью не наблюдается.
            • 0
              Эээ… Експлорер нумер шесть корректно обрабатывает HTML5?
              • 0
                6 и 7 используют скрипт. Но у нас в любом случае, как правило, для них используются фильтры и экспрешены. Ни то ни другое не работает без скриптов. Так что это не самое страшное. Можно смириться, хотя конечно необходимость включенного JS печалит.
                • 0
                  О чём собственно я и написал :) Если правильно указать список поддерживаемых браузеров, то можно писать на «чистом» HTML5, без применения скриптов и хаков.
                  • 0
                    Шестому ИЕ без включенного яваскрипта что хтмл5, что иксхтмл 1 показывать — одинаково.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            новые тэги можно писать так без скриптов:

            [h:footer xmlns:h=«www.w3.org/1999/xhtml»]...[/h:footer]

            h\:footer {...}
    • –1
      комментирование в *Doc формате — это хорошо, но не в production-версии проекта.
      применимо на этапе _разработки_ большого проекта с большой командой, в продакшн-версии лучше не использовать, а минимизировать css автоматически.
      • 0
        А никто и не говорит про production
        Вы же не согласитесь принимать от фриланс-верстальщика податый css и html
        • 0
          не податый, а пожатый))))
  • +1
    считаю что если у фрилансера нет мозгов, то ты хоть 3 тех-задания напиши, толку не будет — получишь кашу!
  • +1
    Еще стоило бы оговорить, что количество подключаемых CSS должно быть минимизировано. Незачем выносить шрифты в один файл, цвета в другой, а оступы в третий. Практика довольно распространенная. Может разработчику оно и удобно, но сопровождать это дело, мягко говоря, не в кайф. Многократно проверено на личном опыте.
  • 0
    Еще мегаважное требование: строгое соблюдение отступов во вложенных тегах. Желательно делать отступы табами. Иногда такая мешанина тегов попадалась — хоть рыдай. Прежде чем разобраться в структуре, приходилось самому отступы расставлять. Вот тут-то и всплывали незакрытые или дважды закрытые теги…
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Угу



        и




        две большие разницы. Впрочем, фиксировать этого не стоит. Если верстальщик не знает таких вещей — это очень слабый верстальщик.
        • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Прошу прощения, примеры Хабр съел =))
      • +1
        Пробельные символы можно загнать в html-комментарий и всеравно перенести правильно. Это тоже не слишком красиво, но лучше, чем в одну строчку, или (о ужас!) делать перенос внутри тегов. Кстати, в django потом комментарии можно убрать и обернуть код в {% spaceless %}.
        • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    а чем не угодил png-24? Проверил только что на нескольких файлах в фотошопе — в подавляющем большинстве случаев размер файла png-24 меньше (иногда незначительно, но меньше) чем png-8.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        CS4… ну не знаю… лично меня устраивает png-24, и экономия 100 байт на иконке при наличии, например, фонового изображения в 60-100кб — это немного странно. Тем более что картинки кешируются. Опять же — css спрайты, как средство уменьшения трафика и увеличения скорости загрузки страницы никто не отменял. А так — вы только потеряете на качестве. Хотя конечно каждому своё — везде надо соблюдать разумный баланс.
        • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Это разные форматы для разных целей. Про то, где их применять, можно написать отдельную статью (и скорее всего она уже написана). Кстати, GIF с альфаканалом, на сколько я знаю, не существует. Да и, строго говоря, полупрозрачный 8-и битный PNG тоже не содержит альфаканала.
      • 0
        А как в таком случае в нем описывается степень прозрачности?
        • 0
          Это часть палитры.

          Грубо говоря в gif:
          цвет 1 — #405060
          цвет 2 — #4a8d5a
          цвет 3 — #f0f0f0
          transparent — цвет 3

          В png:
          цвет 1 — #ff405060
          цвет 2 — #804a8d5a
          цвет 3 — #00f0f0f0
        • 0
          А полноценный альфаканал, это когда:
          пиксель 1,1 — #ff405060
          пиксель 1,2 — #804a8d5a
          пиксель 1,3 — #00f0f0f0
      • 0
        ну да не содержит — кто ж спорит? :)))) когда речь идёт о полупрозрачности png-8 сразу не подходит :)
        тут автор имеет ввиду что png8 использовать всегда, когда возможно — вот я и не понял почему — мои небольшие тесты показывают, что png-24 в большинстве случаев всё-равно меньше чем png-8 (имеется ввиду размер файлов :)).

        Ну а если файл с иконкой будет не 128 байт, а 136 — я это как-нить переживу :)
        • 0
          когда речь идёт о полупрозрачности png-8 сразу не подходит :)
          Видимо вы не все знаете о PNG :)
          www.artlebedev.ru/tools/technogrette/img/png-4/
          • 0
            да-да, про PNG8A знает мало кто
            ну это скорее всего потому, что ФШ его не умеет, а фаерворкс знают далеко не все
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                optipng и pngout оптимизируют алгоритмы упаковки пнг32, но не конвертируют его в пнг8А, если нужно.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      хм. занятно.
                      не знал, спасибо
                      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      сильно зависит от характера изображений
    • 0
      «PNG с 8-битным альфаканалом вместо PNG-24»
      IE6 gracefully degrade
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Комментарии делаю несколько иным способом:
    <div class="myclass myotherclass">
    ...
    </div><!-- myclass myotherclass -->
    <div id="myid">
    ...
    </div><!-- #myid -->


    это облегчает понимание где что заканчивается даже в случае путаницы с табулированием
    • +1
      аналогично, только я просто копирую class=«myclass myotherclass» или id=«myid» в комментарий к закрывающему тегу — во-первых быстрее, во-вторых проще, в-третьих нагляднее.
      • 0
        это дело вкуса, но, пожалуй, попробую ваш вариант в следующий раз. спасибо за подсказку =)
      • 0
        а при редактировании синхронизация летит к чертям…
        • 0
          Не очень понял о какой синхронизации идёт речь? В смысле если вы отредактировали значение параметров id или class? А кто вам мешает опять скопировать и вставить в комментарий к закрывающему тегу новые отредактированные значения? Или вы о другом?
          • 0
            лень и невнимательность
  • –1
    2. Всегда описывайте цвет фона для body даже если он белый.

    Можно я на Вас буду молиться?
    Подавляющее большинство верстальщиков и разработчиков забывают об этом. В итоге очень смешно смотрятся такие сайты в моём дефолтном браузере, у которого фоновый цвет по умолчанию совсем не белый.
    • +3
      А по моему это детские болезни
    • +5
      сам себе злобный буратин…
      • 0
        Извините, но ATimofeev, написавший выше, прав.
        Это — детские болезни. Но они встречаются очень и очень часто. Мне кажется, что не продумать такой простой вещи, как
        body {background-color:#FFFFFF;}
        — просто небрежное отношение к своей работе.
        • 0
          это всё-равно, что дублировать все надписи в здании на уровне 30см от пола для любителей ходить на руках ;-)
  • +5
    Сразу видно, что писал программист )

    Ваши требования к вертке явно ориентируются на сложный проект, поддержкой и сопровождением которого предстоит заниматься и дальше. Причем не одному человеку. А для среднего сайта достаточно соответствия пунтам хотя бы с первого по четвертый.

    Как результат – куча оголтелых манагеров, которые прочли этот пост, будут бездумно тыкаться в ваш чеклист даже при верстке элементарной однодневной фигни. Думаю, не будет лишним отметить, для проектов какого масштаба следует оперировать вашим чеклистом.
  • 0
    А подскажите вот какой момент: когда в дизайне в .psd файле повторяющийся фон, как он должен передаваться верстальщику? Дизайнер должен на отдельном слое дать один фрагмент? В общем, чтобы потом верстальщик-нарезальщик не тратил время на поиск фрагмента, который размножался.
    Как вообще принято?
    • 0
      Хороший верстальщик должен быть с фотошопом на ты. И должен уметь преобразовать нарисованную дизайнером кнопочку, фон, элемент управления и т. д. таким образом, чтобы облегчить себе жизнь в процессе вёрстки. Например, если у дизайнера нарисовано 10 кнопок разных цветов с градиентом от светлого к тёмному, то верстальщик (если конечно требования заказчика не позволяют использовать css-градиент) должен сам сделать полупрозрачную картинку бело-черного градиента и менять потом только лишь background-color, а не создавать 10 картинок buttonBlue, buttonRed, buttonYellow и т. д.
      • +1
        Хм… дизайнер при изображении кнопок уже создал этот градиент. Зачем верстальщику это делать снова? Тем более как-то ведь надо дать понять верстальщику, что все кнопки будут выглядеть именно так, именно с таким градиентным переходом.
        • 0
          Дизайнер создаст 10 кнопок разных цветов с градиентом. В фотошопе это будут градиенты от светло-зеленого к тёмно-зеленому, от светло-красного к тёмно-красному и т. д. Хороший верстальщик создаст градиент от чёрного к прозрачному и будет накладывать его поверх кнопок. Таким образом ему не придется делать 10 картинок для кнопок. И в css он будет менять только свойство background-color, а градиент на кнопке будет создаваться автоматически.
          • +1
            Я понял, что Вы имеете в виду. Конечно, так и стоило бы сделать. В идеале. Но дизайнер разве не такой же метод использует? Вернее, похожий?

            Ибо если так, то кто ему мешает положить этот градиент на отдельный слой, чтоб верстальщик мог использовать готовую заготовку? К тому же и у дизайнера работа упростится — не надо плодить градиентных кнопок, а просто повторно использовать готовую методу.

            А если он использует другой метод — кто поручится, что просто наложение градиентной кнопки на фон даст точно тот же переход цветов, который был нарисован?
            • +1
              В идеале конечно должно быть так как вы говорите. Но это лишь один нюанс, а их гораздо больше. И обучить дизайнера всем этим нюансам займет слишком много времени. Поэтому чаще всего верстальщик перелопачивает потом весь макет. Рисует градиенты, стандартизирует отступы, подгоняет под сетку и т. д.
              • 0
                О да. И это, кстати, одна из распространённых проблем — многие дизайнеры не придерживаются каких-то стандартов, в результате на разных макетах могут быть разные отступы, кнопки могут быть выполнены с разными градиентами, блоки на страницах перекрывать друг дружку и т.д. и т.п. Но, имхо, указать метод «рисования» кнопок — это всё же работа дизайнера. Верстальщик не должен гадать, так или эдак рисовать градиенты.
              • 0
                если дизайнер не поддаётся обучению — гнать его надо
      • 0
        Я этого не умею.
        • 0
          Надо учиться!)
  • +1
    п. 14:
    Даже в комментариях не использовать кириллицу.
  • +5
    Поддерживать оперу < 9.5 — ад. Тем более количество пользователей таких версий меньше процента
    • 0
      На чём основывается ваше утверждение? У меня другая статистика.
      • 0
        На статистике конечно. Приведите вашу и тематику сайта тоже. Количество посетителей тоже имеет значение : ) Есть информация по развлекательно-информационному сайту с посещаемостью 35000 посетителей в сутки (общая статистика по браузерам такая же как по рунету) + есть информация по узкоспециализированным сайтам (лидируют IE, в том числе 12% с IE6) — и там и там пользователей < 9.5 меньше процента, что позволяет на них забить
        • +1
          www.yandex.ru

          Opera 10.6		8.71636
          Opera 10.5		3.57901
          Opera 10.0 - 10.2		3.36054
          Opera 9.6		2.66327
          Opera 9.0 - 9.2x		1.32989
          Opera 9.4 - Opera 9.5	0.95827
          Opera 7.x - 8.x		0.18064
          


          Выборка за последнюю неделю июля, 40M посетителей.
          • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              IE 8.x    24.48231
              IE 7.x    10.68470
              IE 6.x     8.92085
              IE 5.x    0.02473
              
              Firefox 3.6    17.33115
              Firefox 3.5     5.47517
              Firefox 3.0 - 3.2    3.45191
              Firefox 1.x - 2.x     0.67717
              Firefox 4.0     0.01455
              Firefox 3.7     0.00496
              
              
          • 0
            Ха, ну у вас тут другое дело ; )
  • 0
    Кстати, господа верстальщики, если кто-то из вас согласен с большей частью этого списка и в данный момент ищет постоянную работу в Питере, напишите мне в личку.
    • 0
      предлагаю себя, но удаленно
      • 0
        сорри, работа в офисе
  • 0
    Лучше всего сверстать самому!!!
  • –1
    Спасибо, буду давать ссылку на этот пост верстальщикам.
  • 0
    Если уж cursor:pointer, то тогда сразу и для IE:
    cursor:pointer;//hand;

    За href='javascript:void(0)' я бы по рукам бил. Лучше все-таки прописать href='#', а потом довесить на domload:
    $$("a[href=#]").each(function(a){
      a.href="javascript:void(0)";
    })
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Спасибо большое! Очень полезные советы. Ко многому уже со временем сам пришёл, но попадись мне такой материал в то время, когда я только учился верстать, то, я думаю, я сэкономил бы очень много времени.
  • –4
    Кроме п. 1 все — на любителя, спорно(любой можно повернуть с точностью до наоборот) и сильно зависит от задачи…
    Как то при социализме уже жили, когда все ходили в одинаково пошитых штанах :)
    Как можно уместить в 22 надуманных кем-то пункта все случаи?

    Сорри, глянув на возраст топик стартера — все списал на юный возраст и квалификацию начинающего…
    • 0
      Безусловно, большинство рекомендаций — дело вкуса. Но устаканивать их все-таки надо. Когда меня спрашивают, а почему такой стандарт а не такой, то я говорю, что в общем-то без разницы. Главное, что СТАНДАРТ ДОЛЖЕН БЫТЬ.

      Зачем оно надо?

      После того как статический HTML-макет сайта сверстан, его «оживляют» зачастую совсем не те программист(ы), которые делали верстку. И если верстка сделана плохо, это сильно усложняет жизнь девелоперам. Комменты в CSS и HTML, отступы в разметке — все это сильно поможет девелоперам при сопровождании.

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

      Так что штаны должны быть пошиты одинаково. Разумеется, стандарт может отчасти меняться от проекта к проекту. Но еще раз повторюсь, что стандарт должен быть. Обязательный к исполнению всеми членами команды. И как девелопер должен заметить, что соблюдать стандарты не так уж и сложно.

  • +7
    Мои 5 копеек, чуть запоздало.

    19. Если вы делаете обработку событий при нажатии на ссылки, следите за тем, чтобы обработчики событий возвращали false, или же используйте href='javascript:void(0)' вместо популярного href='#', чтобы страница не скроллилась вверх.

    Если это реальная ссылка, то настоящий адрес в ней уже будет. Если адреса нет, то и ссылки быть не должно. А должен быть любой элемент с cursor:pointer и обработчиком onclick. Это называется семантика и обратная совместимость.

    17. Если в макете присутствует JS, изменяющий DOM — внимательно следить, чтобы все корректно работало в Опере, т. к. этот замечательный браузер при нажатии на кнопочку назад страницу не перезагружает

    Если почитать соответствующие спеки внимательно, то именно такое поведение и подразумевается. Если кто-то «не как все», то это не значит, что он ошибается в своих действиях. И ведь мало кто из разработчиков вспоминает, что кроме возвращений назад, бывают ещё и автозаполнители форм, которые не вызывают ожидаемых событий. Это вообще очень сложный вопрос. Единственный возможный совет: «проверяйте всё и всегда, особенно подразумеваемые вещи».

    8. Если Javascript кода много — нужно его выносить в отдельный файл

    Весь JS нужно выносить во внешний файл. В этом вопросе стоит быть гораздо категоричнее, иначе JS-код пухнет, теряет логику и начинает подчинять весь документ. Разве что вы Яндекс и занимаете супер-оптимизацией… но это вряд ли :)

    3. Если используете CSS хаки, комментируйте, что это и для какого браузера, а лучше используйте css_browser_selector.js

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

    В общем, список получился довольно сумбурным. Важные вещи перемешаны с сиюминутными проблемами.
    • +1
      Если это реальная ссылка, то настоящий адрес в ней уже будет. Если адреса нет, то и ссылки быть не должно. А должен быть любой элемент с cursor:pointer и обработчиком onclick. Это называется семантика и обратная совместимость.


      Использование ссылки вместо кнопки частенько помогает избежать использование яваскрипта для обработки «hover». Можно, конечно, утверждать, что всё это финты ушами, но…
      • 0
        Использование ссылки вместо кнопки частенько помогает избежать использование яваскрипта для обработки «hover». Можно, конечно, утверждать, что всё это финты ушами, но…

        JS для имитации :hover на любом объекте нужен только для IE6 и младше. Проблема теряет свою актуальность с каждым днём, а для некоторых уже давно потеряла.
        • –1
          Можно конечно попробовать придраться, но по сути я с Вами согласен. И ссылка должна быть ссылкой. И :hover в нормальных браузерах обрабатывается корректно. И шестой експлорер надо выкорчёвывать калёным железом. Так что проблема теряет актуальность с каждой минутой.
        • +1
          Рано вы его хороните, это зависит от клиентов. И не говорите, что на таких клиентов следует забивать. Бизнес важнее, чем технологический экстаз и мы должны отталкиваться от сугубых реалий действительности. Да, проблема теряет свою актуальность, но она все еще есть.
          • 0
            ну если его не хоронить, так он ведь, сука, никогда и не сдохнет! :(
          • +1
            Это не технологический экстаз, это банальное уважение к самому себе. Гораздо приятнее, полезнее и просто выгоднее для вас будет тратить время на новый проект, а не на танцы вокруг трупа IE6.

            Но, опять же, я не отрицаю, что бывает и клиника — ваш заказчик сельская бухгалтерия, а верстальщики прикованы наручниками к батарее. Тогда — да :)
            • –1
              Сельская бухгалтерия — это вполне себе могут быть корпорация с десятками тысяч рабочих станций и кучей унаследованного внутреннего софта, который писался в эпоху IE6 и заточен под него. Так, что можете быть отвязанными от батарее и от заказов от таких компаний, которые наверняка имеют финансы и потребность, в отличии от «уважающих себя» тинейджеров, с ворованным Win7…
            • –1
              Я почему-то не теряю уважения к себе, делая качественную верстку, выглядящую одинаково хорошо во всех браузерах, даже в IE6.
              Да, лично мне как верстальщику, было бы и приятнее и полезнее и выгоднее тратить время на новый проект, а не на адаптацию макетов к IE6. А еще мне хотелось бы жить на Гаваях в домике с видом на море и жену негритянку.
              Но в организации, в которой я работаю, на первом месте интересы клиента.

              Взгляните на проблему шире, она актуальна не только для сельских бухгалтерий. Вы обошли своим вниманием кучу брендов, у которых, к примеру, целевая аудитория — домохозяйки.
              Я думаю, такие заказчики вполне грамотно поступают, требуя поддержку IE6 от веб-разработчиков.

              Чтож, кто-то возможно отказался бы от такой грязной и невыносимой работы. А мы все еще, о ужас, соглашаемся делать сайты с поддержкой IE6 :)
              • 0
                Повторюсь: я не отрицаю, что в специфических случаях важна поддержка IE6. Есть куча вариантов, начиная с сельской бухгалтерии, заканчивая домохозяйками. Но список универсальных правил будет полезен чуть больше, чем двое суток, если он будет смотреть в перспективном направлении, а не копаться маргинальных случаях.

                Поэтому:

                — Элемент должен быть ссылкой только если он содержит осмысленный URL или якорь в атрибуте href, иначе это должен быть любой другой подходящий элемент с cursor:pointer и onclick="…".
                — Для имитации :hover на других элементах, в IE6 можно использовать: a:hover, expression или Javascript

                Так ведь лучше, правда?
      • 0
        У разве нет :hover?
        • 0
          тега button
          • 0
            Если б всё ограничивалось только тегом button… А если хочется сделать целый «блок» реагирующим на hover? С картинками внутри?
            • 0
              что мешает засунуть его в буттон? ;-)
          • 0
            Погорячился. В ie6 таки только у якорей.
            Но скрипты никто не отменял.
        • 0
          IE6, например, игнорирует этот псевдокласс для всех элементов, кроме «a». Вот такой вот фикус-пикус :(
          Но в дискуссии выше мы сошлись во мнении, что правильная семантика важнее, чем шестой експлорер.
      • 0
        а на кнопках разве ховер не работает? :-о
        • 0
          Ну если речь идёт об единичной кнопке — всё неплохо. Но порой нужно хавер наложить на большую конструкцию — со сдвигающимися бакграундами, несколькими блоками текста и т.п. Например, как-то выделять анонс статьи на странице при наведении курсора. Там «кнопкой» не отделаешься.
          • 0
            почему это? о0
  • +1
    Также при создании макетов и отправке их на верстку нужно обращать внимание на наличие стилей для:
    — Заголовков 1-3 уровня в контенте;
    — Нумерованных и маркированных списков;
    — Таблиц, названий и заголовков таблиц;
    — Элементов форм, также верстать поля форм заполненными, чтобы можно было сразу видеть стиль текста.

    Также стоит проверить стили для:
    — strong,
    — em,
    — dl, dt, dd
    — blockquote

    Обязательно нужно указать какими должны быть активные ссылки (и другие кликабельные элементы), посещенные, при наведении курсора.

    Это необходимо для того, чтобы потом, при заполнении сайта контентом не возникало проблем.

    Требования к структуре каталогов, например:

    htdocs (тут лежат все файлы .html)
    └─-- (каталог «-» дефис, файлов не содержит)
       ├─css
       ├─img
       ├─js
       ├─plugins
       │ ├─jquery
       │ ├─jquery-fancybox
       │ └─swfobject
       └─swf
    


    Файлы .html называть именами соответствующих *.psd файлов.

    Именование CSS-файлов:
    — reset.css — css-ресет.
    — style.css — основные стили, которые относятся ко всему сайту и главной странице.
    — inner.css — выносить стили, которые относятся к внутренним страницам, если нужно что-то переопределить.
    — form.css — стили форм.
    — pages.css — стиль постраничного вывода (страницы 1 2 3 4… 11 12)
    — debug.css — временный файл используется программистами для правок верстки, которые потом должен пересмотреть верстальщик и вынести/подправить соответствующим образом.
    — ie.css — стили для ИЕ.
    — ie6.css — для ИЕ6.

    В основных файлах не использовать хаков, только валидный CSS. Все что касается ИЕ — в отдельные файлы и подключать через Conditional Comments.
    • –1
      Каждый HTTP-запрос к серверу имеет довольно ощутимые накладные расходы. Поэтому количество скриптов, картинок и стилевых файлов желательно минимизировать. Подробнее см. в книге «Разгони свой сайт». Лично я обычно весь CSS храню в 1-2 файлах, но стили сгруппированы и снабжены комментариями.
      • 0
        При деплое все файлы склеиваются в один/несколько и минимизируются. Изначально всё делать в одном файле — ад. Если вы конечно не делаете сайт-визитку из 2х страниц
      • 0
        Забегая наперед, скажу

        1. Все запросы к каталогу «-» обрабатывает nginx.

        2. Для всех файлов стилей используется minify

        3. Все файлы на продакшине, как css так и js сливаются в один.

        Так и выходит, как вы говорите, всего 2 файла — 1 css и один js, но для девелопмента это неприемлимо, так как править файлы по нескольку десятков килобайт — удовольствие еще то.

        Кроме того, разбивка на файлы бывает и больше, может быть так, что в отдельные файлы выносятся стили для текста и для основной разметки макета, а также стили, которые использует javascript. Также бывает еще файл basis.css, в котором после ресета устанавливаются основные отступы, начертания, кегль и размеры шрифта.
  • 0
    очень полезный пост, хотя бы тем, что к нему написали много интересных комментариев :)
  • +1
    Отличная статья получилась. Много рекомендаций добавил в свои. Хочу поделится некоторыми своими:

    • Соответствие стандартам W3C.

    • Верстка должна быть логически верной:
    o При отключенном css, сайт должен отображаться в следующем порядке: шапка, главное горизонтальное меню (если есть), левая часть (если есть), контентная часть, правая часть(если есть), подложка.
    o На страницах обязательно использовать теги h1, h2, h3 в соответствии с логической нагрузкой надписи. Например, название страницы делать h1.
    o Все выделения жирным и курсивом должны быть сделаны с помощью тегов strong и em соответственно. При необходимости использовать CSS, но только с вышеуказанными тегами. Теги b и i не использовать, для выделения блоков со смысловой нагрузкой. (пункт появился, после того как кто-то сделал: span class=«b»)

    • Контентные части сайта, куда будет выведен текст из визуального редактора, должны корректно отображать текст (p, b, i, etc), картинки (img), ссылки (a ), таблицы (table, tr, td, th), списки (li, ul и т.д.), без использования в тегах классов стилей. Необходимо использовать только класс внешнего контейнера.

    • Рамки на картинках всегда являются элементом верстки, а не картинки. Тени, отблески и т.д. считаются рамкой картинки.

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

    • Если сайт будет на нескольких языках, то нарезать все картинки с надписями для разных языков. Называть картинки необходимо %название%_%указатель языка (ru|ua|en|…)%.jpg|gif|etc.
    • 0
      Спасибо!
      Пункты 2.2, 4 и последний — однозначно очень ок, первый входит в то, о чем я говорил в своем последнем пункте, остальные можно пообсуждать или возможно как-то по-иному сформулировать.

      2.1 — а в каких случаях сайт вдруг может отобразится без CSS, просветите? Браузеры без поддержки CSS все еще популярны? :)
      2.3 — почему именно так с i,b,em,strong?

      • 0
        2.1. — это требование со стороны SEO, а не со стороны отображения дизайна.
        2.3. — b и i, решили не использовать, т.к. визуальные редакторы вставляют именно strong и em, потому для единообразия и решили.
        • 0
          2.1. Тогда нужно говорить не о порядке отображения блоков на странице с отключенным CSS, а о порядке их расположения в html-макете. А этот порядок может очень зависеть от типа контента конкретного сайта.
        • 0
          2.3. Решение такого характера можно и полезно использовать во внутренних правилах вашей фирмы, но опять же, в статье я пытался говорить о каких-то максимально общих моментах.
    • 0
      Предпоследний пункт я бы вот как-то переформулировал
  • 0
    Есть над чем подумать спасибо автору. Стандартизация это экономия времени.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.