Html — Оцените верстку и…..


Содержание

QA Шпаргалки

пятница, 19 июля 2013 г.

Шпаргалка: Тестирование верстки

Чек-лист вёрстки. Что можно отдавать клиенту, а что надо переделывать.

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

На хабре была статья про «Требования к html-верстке». Но это ТЗ для исполнителя/соглашение о кодировании/советы хорошего тона, но не проверочный список: готова-ли работа и можно-ли её принимать. Он хороший, но увы, его соблюдение не гарантирует что проблем не будет.

Для того чтобы отдавать вёрстку клиенту, достаточно соблюдения первых 4 пунктов.
Для выдачи в продакшен — первых 6.

0. Соответствие макету

  1. Кроссбраузерность, кодировка и DOCTYPE
  2. Валидность, доступность, микроформаты
  3. Независимость блоков в CSS: минимизация каскада, использование техник БЭМ/MCSS/SMACSS
  4. Сайт должен нормально смотреться во всех стандартных разрешениях от 1024 и выше, не иметь горизонтального скролла и вписываться в экран мобильных устройств
  5. Корректная работа при вбивании реального текста, надёжность вёрстки
  6. Проверка и оптимизация скорости загрузки
  7. Наличие Win/Mac/Linux-аналогов шрифтов
  8. Доступность при выключенных(загружающихся) картинках
  9. HTML5 формы, линковка, валидация
  10. Семантичность. Отсутствие глупостей в html и css, единообразие, аккуратность
  11. Правильная структура заголовков (H1,H2,… и т.д. и TITLE)
  12. Работоспособность при выключенном JavaScript
  13. Работоспособность при выключенном Flash
  14. Отсутствие багов при увеличенном шрифте
  15. И последний пункт – мелкие проверки (ниже подробней)

Пункт номер 0. Соответствие макету

Расположение блоков должно быть 1:1 по сравнению с макетом. Допускается расхождение до 5px для текста. Разрешены и даже приветствуются правки размеров и расположения криво нарисованных блоков (разница размерах в 1-2px на разных страницах).

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

Проверяется в Firefox через плагин Pixel Perfect. Для проверки в других браузерах используйте ModularGrid, но в принципе достаточно просто глянуть намётанным глазом, если расхождения заметные — они будут бросаться в глаза.

№1. Кроссбраузерность, кодировка и DOCTYPE

Проверка: открываем исходный код страницы, первая строка должны быть .

  • Кроссбраузерность:
    • Firefox (последний)
    • Chrome (последний)
    • Safari (последний) и если у вас нет Mac чтоб проверить «размытые Mac’овские» шрифты (они чуть большего размера, из-за этого бывает вылазят баги) то установите в Preferences→Appearance, «Font Smoothing» в Medium (по дефолту там «Windows Standart»).
    • iPhone (смотрим в landscape и portrait режимах, т.е. вертикально и горизонтально) + Android. Тут важно чтоб верстальщик не забыл указать правильный viewport.
    • Opera (последняя) Имеет смысл также посмотреть на 12-версии с движком Presto, если там есть баги в отображении — это признак потенциальных проблем в качестве кода
    • IE7+ (для IE6 выводится уведомление о неподдержке и предложении скачать другой браузер или установить Google Frame, но с возможностью всё-таки просмотреть сайт)
    • Opera Mini (проверяется в Opera Developer Tools→Opera Mini Simulator, нужно установить Java плагин к браузеру, или в крайнем случае: Opera 9.64→Вид-Маленький экран, но в 9.64 JS будет работать полноценно в отличие от настоящей Opera Mini, это нужно учитывать)

    Проверяется просмотром сайта в вышеперечисленных браузерах.

    • Проверка в IE7 делается переключением IE8 в режим IE7 (F12→Режим обозревателя→Internet Explorer 7).
    • В IE6 можно посмотреть на ipinfo.info/netrenderer/ или на виртуальной машине (удобно использовать Windows XP Mode в Win7).
  • №2 Валидность, доступность, микроформаты

    1. Не должно быть js-ошибок!
    2. Титулка должна быть валидна в любом случае. Ошибки на внутряках простительны в следующих случаях:
      • Упоротая секретарша копипастит тексты из Word’а в визиг;
      • Программеру ну очень нужны какие-то кастомные атрибуты (хотя для этого в HTML5 ввели специальные пользовательские атрибуты «data-*»).
    3. CSS валидируется по версии 3.0, его валидность не требуется (да и валидатор ещё кривоват), а вот синтаксические ошибки (типа margin: 10xp) исправлять надо.
    4. Микроформаты должны быть. Как минимум – hCard. Желательно также hCalendar, XFN, hAtom.
    5. Проверка статическими анализаторами качества кода: CSSLint и JSHint

    Ошибки js проверяются просмотром сайта в IE – в левом нижнем углу не должно быть значка «есть js-ошибки».

    Зачем нужна валидность? Главнейший практический плюс: валидный код обладает заранее известной структурой и упорядоченностью. Если в коде царит порядок, то такой код проще обрабатывать, обслуживать, видоизменять… Маленькое лирическое отступление: инженеры уже давно поняли, что унификация и стандартизация значительно снижают стоимость изготовления и, главное, обслуживания изделий… Код с ошибками — чаще всего именно кустарщина.

    HTML5 помогает нам в случае необходимости своих, кастомных, невалидных атрибутов для элементов. Просто указываем атрибут «data-чтоугодно» — и можем использовать! Это валидно!

    Микроформаты не только полезны для SEO, но и здорово упорядочивают код. Не нужно полчаса думать как назвать новый блок. Выбирай из существующих стандартных имён! Бери entry-content, не ошибёшся :)

    В настоящее время (2012 год) микроформаты постепенно вытесняются microdata, стоит использовать и то и другое.

    В идеале вёрстка должна соответствовать стандарту доступности: WCAG.
    Он имеет три уровня сложности, если проходит хотя бы WCAG1 A (Priority 1) – уже хорошо. Идеальный вариант – WCAG2 Priority 3 (AAA). Самый просто способ проверить что скорей всего WCAG1 Priority A соблюдён — www.cynthiasays.com/ (или Web Developer →Инструменты →Проверить WAI). Почему «скорей всего»? Некоторые требования WCAG невозможно проверить автоматически. Вот ещё несколько скриптов помошников:

    • Check a Site: scan web sites for over 450 quality problems
    • Total Validator: (X)HTML validator, an accessibility validator, a spell checker, and a broken links checker
    • Validación de accesibilidad de acuerdo a las WCAG 2.0 con PISTA

    И собственно сам чеклист WCAG2:

    • www.w3.org/TR/WCAG20/#guidelines
    • и детальнее: www.w3.org/WAI/WCAG20/quickref/
    Некоторые ошибки в валидации допустимы.
    1. По-умолчанию валидатор CSS проверяет код согласно стандарту 2.1, а не 3.
      Поэтому допустимы ошибки такого рода:
    2. Валидатор считает ошибкой указание вендорных префиксов
      Поэтому допустимы ошибки такого рода:
    3. Раньше проприентарные свойства IE было рекомендовано выносить в отдельный CSS. Сейчас стоит использовать HTML5 Boilerplate и фильтровать в style.css с помощью html.oldie, html.ie7 и т.д.
      Тогда допустимы ошибки такого рода:

    Настройки CSSLint:

    Выключить опции:
    — Beware of broken box sizing
    — Disallow adjoining classes
    — Disallow empty rules

    Настройки JSHint:

    Выключить:
    — When code is not in strict mode

    №3 Независимость блоков в CSS: минимизация каскада, использование техник БЭМ/MCSS/SMACSS

    Проверяется в FF через плагин Firebug
    При наведении на любой блок, в его стилях не должно быть множество перечёркнутых правил (следствие длинного каскада).
    Для минимизации каскада и построения надёжной, современной, масштабируемой вёрстки сейчас применяют следующие техники: БЭМ, MCSS и SMACSS.

    №4 Сайт должен нормально смотреться во всех стандартных разрешениях от 1024 и выше, не иметь горизонтального скролла и вписываться в экран мобильных устройств

    Проверяется в FF через плагин Web Developer→Resize
    Список классических разрешений:

    • 1024×600
    • 1024×768
    • 1152×864
    • 1280×800
    • 1280×1024
    • 1440×900
    • 1680×1050
    • 1920×1080

    На больших разрешениях нужно обращать внимание что не пропадает фоновая графика по краям сайта (что размера картинки хватило на большое разрешение).

    Вписывание в экран мобильных устройств лучше проверять на самих мобильных устройствах. Множество проблем решается указанием верного Viewport. Подробнее: прекрасный доклад Вадима Макеева «Прокрустовы окна. Как вписаться в устройства с минимальными потерями».

    Вёрстка и её критерии качества

    Вёрстка — это процесс преобразования картинки (например, в PSD, JPG, PNG и других форматах) в HTML-страницу. То есть Вы сделали дизайн страницы, но это ещё не страница, так как ещё нет абсолютно никакой интерактивности. И вот после создания дизайна настаёт время вёрстки. А в этой статье я расскажу о критериях качества вёрстки.

    Вот те критерии качества вёрстки, по которым можно определить, насколько качественно сделана вёрстка:

    1. Совпадение с дизайном. Редкое явление, когда дизайн на 100% совпадает с вёрсткой, но очень близкое совпадение необходимо обеспечить. Очень близкое совпадение с дизайном означает, что при взгляде сначала на дизайн, а потом на вёрстку, крайне трудно назвать отличия. Безусловно, если в дизайне отступ 10 пикселей, а Вы поставили 8, то никто этого не заметит, и дефектом это являться не будет.
    2. Кроссбраузерность. Этот критерий характеризует, насколько сайт хорошо смотрится в разных браузерах. Сразу скажу, практически невозможно сделать 100% одинаковое отображение во всех браузерах (тем более, что их сотни, а вместе с версиями и тысячи). Однако, обеспечить адекватное отображение во всех современных браузерах (Firefox, Opera, IE, Chrome — последних версий), а также некоторых старых (IE8, IE7, IE6) обязательно нужно.
    3. Адаптация под разные разрешения. В большинстве случаев проблема возникает при низких разрешениях, а точнее при маленькой ширине экрана. На данный момент адаптировать сайт рекомендуется под ширину экрана 1024 пикселя и больше. Адаптирование под разные разрешения экрана, в большинстве случаев, означает отсутствие горизонтальной полосы прокрутки.
    4. Чистый и валидный код. Под чистым кодом подразумевается такой код, в котором без проблем разберётся посторонний человек. То есть всё должно быть структурировано, внутренние теги должны иметь отступ от внешних, все классы и id должны иметь адекватные имена. А про важность валидности писалось здесь: валидность html-кода.

    Примерно 50% верстальщиков (в том числе и всякие компании) обеспечивают лишь 1-й пункт и чуть-чуть 2-й. Где-то 49% не обеспечивают вообще ничего, то есть их вёрстка просто безобразна. И лишь 1% действительно качественно верстают. К сожалению, я не знаком с такими верстальщиками, но сайты хорошо свёрстанные есть, значит, и отличные верстальщики имеются, но их очень мало.

    Мне бы очень хотелось, чтобы Вы попали в этот 1% асов вёрстки, которые обеспечивают все 4 пункта, но для этого нужно очень хорошо знать HTML и CSS и, главное, практиковаться, регулярно практиковаться, причём в простом редакторе, а не в каком-нибудь DreamWeaver (если используете визуальную часть этого редактора, то Вы автоматически попадаете в те 49%). Поэтому ежедневно практикуйтесь, и уже через пару месяцев Вы будете хорошо верстать.

    И, наконец, отличным вариантом обучения вёрстке будет вот этот курс: Вёрстка сайта с нуля — который обучит Вас всем азам, покажет несколько примеров вёрстки различных страниц и даст массу упражнений для закрепления знаний.

    Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

    Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
    Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

    Если Вы не хотите пропустить новые материалы на сайте,
    то Вы можете подписаться на обновления: Подписаться на обновления

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

    Порекомендуйте эту статью друзьям:

    Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

    Она выглядит вот так:

  • BB-код ссылки для форумов (например, можете поставить её в подписи):
  • Комментарии ( 15 ):

    Михаил, в 3 пункте говорится о адаптации сайта к разным разрешениям экранов пользователей и о горизонтальной полосе прокрутки. У вас на сайте есть горизонтальная полоса прокрутки. Я смотрю ваш сайт через Google Crome с разрешением экрана 1366×768. Попробуйте в CSS-файле этой страницы к тегу BODY добавить padding: 0; margin: 0; должна исчезнуть.

    Да, нет, проблема не в этом была, тем более, что margin и padding стояли. Было некорректное отображение рамки в chrome у верхнего меню. Подправил, теперь должно быть нормально.

    Возможно, в хеше сохранилось, потому что только что посмотрел — проблемы больше нет.

    Михаил, а не могли бы вы написать очерк про среду разработки, программки-сайтостроители? Расставить точки над ё по поводу DreamWeaver-ов и поделиться своим мнением о том, какая прога лучшая? Понимая, тема индивидуальная, каждый под себя выбирает.

    Вот про Dreamweaver: http://myrusakov.ru/html-dreamweaver.html К любой другой аналогичной программе данная статья также полностью относится.

    Согласен. Читая статью про DW, не раз ловил себя на мысли, «это же можно сказать и про мою программу». Уже убедился, если делаешь код в какой-то программе, не забудь потом проверить его в обычном блокноте. Тем более, что блокноты ведь тоже разные бывают.

    Здравствуйте Михаил.Могли бы Вы проконсультировать меня как профессионал по такому вопросу? Я полностью заменила дизайн сайта(шаблон). Подскажите пожалуйста,как лучше загрузить его на сервер? Сначала удалить старые страницы, а потом загрузить новые или как?

    Сначала удалите всё старое, а потом загрузите новое.

    Михаил, прослушал видео урок по этой теме и хочу задать вопрос. Прослушивал однажды курсы достаточно профессионального товарища, так он утверждает, что поддержка браузера IE6, а порой и IE7 для интернет проекта должна быть экономически оправдана. IE6 практически мертвый браузер и вложенные в него усилия и средства должны окупаться, и если этого не происходит, поддержка его должна прекращаться. Как Вы относитесь к данному утверждению.

    Цукерберг рекомендует:  Используем WordPress как рабочую среду PHP для создания статических страниц HTML

    Самый частый аргумент бездельников и халтурщиков. Даже сейчас этими браузерами пользуются примерно 3.5% всех пользователей. И как показывает практика, практически всегда сайт, плохо отображающийся в IE6 и IE7, будет также плохо отображаться в некоторых других браузерах. Таким образом, процент будет возрастать. Для всяких левых сайтов, возможно, эти 3.5% и немного, но для серьёзных сайтов 3.5% — это очень много, особенно, если посещаемость огромная.

    Насчет халтурщиков не знаю, эта лекция читалась в Бауманке. В качестве примера приведен магазин OZON, якобы они сворачивают поддержку IE6 поскольку затраты на эту поддержку приносят явные убытки ресурсу. Я так предполагаю, что все маркетинговые исследования были проведены.

    Это их ошибка, но они от этого сильно не обеднеют. Хотя никаких проблем с отображением Ozon в IE6 я не увидел.

    Не «внутренние тегА должны иметь отступ от внешних» А наверное «Внутренние тегИ» ?

    Для добавления комментариев надо войти в систему.
    Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.

    Copyright © 2010-2020 Русаков Михаил Юрьевич. Все права защищены.

    10 пунктов для проверки вёрстки

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

    В этой статье я собрал 10 требований, которые стоит предъявлять к верстальщику.

    1 Проверка валидности

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

    2 Онлайн-сервисы

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

    Лично мне нравится первый сервис.

    3 Реальные устройства

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

    4 Зоопарк браузеров

    Традиционно у верстальщиков установлены все популярные браузеры, каждый из которых имеет своеобразные особенности. Но бывает так, что верстальщик ленивый или ему мало платят, поэтому он работает только в одном браузере, который считает эталоном, а остальные не нужны.

    Автоматизировать проверку можно с помощью данного сервиса https://developer.microsoft.com/en-us/microsoft-edge/tools/screenshots/, который сгенерирует скриншоты сайта из различных браузеров и устройств.

    5 Различный контент

    Зачастую при разработке дизайна сайта упускается важный момент — содержимое может быть различного объёма (разрешение изображения, количество символов текста). Анонс новости может быть не только в 4 строки, как красиво нарисовал дизайнер, а в 3 или 5. А, может, и все 100. Изображение в слайдере, загруженное контент-менеджером, может вдруг оказаться не эталонного размера, как нарисовано в макете, а вообще повёрнутым на 90 градусов. Или вообще не существовать.

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

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

    7 Выбор фреймворка

    Фреймворки служат для ускорения разработки. Одним из популярных фреймворков является Bootstrap, который содержит множество готовых типовых решений (кнопки, типографика, формы, модальные окна и пр.).

    Но у этого удобства есть обратная сторона — объём данных. Использование фреймворков может замедлить работу сайта, что особенно заметно на мобильных устройствах или при медленном соединении.

    8 Исходники

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

    Но если проект будет переходить из рук в руки, то стоит предупреждать последующих исполнителей об этом.

    9 Производительность

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

    Вообще, это относится в том числе и к дизайнеру.

    10 Семантика

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

    Интерактивные элементы вроде кнопок тоже стоит реализовывать с помощью тега button, а не div или span.

    Как оценить качество html-верстки

    В процессе обучения на html-курсах у меня постоянно возникает потребность оценивать качество html-верстки учеников. Данная тематика очень большая и неоднозначная: о неё спотыкались почти все, что так или иначе использует чужой код. Некоторые компании придумывают сложные чек-листы, чтобы хоть как-то форматизировать свои требования. Другие, наоборот, упрощают подход: сайт «не разваливается», уже хорошо. :-)

    Обычно смотрят сразу на весь сайт, поэтому часто возникают требования имеющие лишь второсепенное отношение к html-верстке. Например использование H1-заголовка и SEO-оптимизация. В данном случае верстальщик не обязан знать всю контекстную составляющую сайта, а в большинстве случаев, это даже неизвестно. Например в шаблонах CMS наполнением занимается конечный пользователь.

    Существуют и другие, совершенно «безумные» требования, вроде запрета использовать !important в CSS. То что это стандарт CSS, автор требования, видимо, не в курсе. Или только один css-файл на все страницы. C учётом lazy-загрузки данное требование можно трактовать исключительно как «вредное».

    Потихонечку я пришел к выводу, что оценивать html-верстку нужно в основном по качеству кода. Причем код бывает двух видов: первый — исходный, второй — готовый (скомпилированный).

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

    На сегодняшний день существует только одно требование: готовые файлы должны быть минимизированы, а значит физически отделены от исходных. Когда верстальщик сдаёт работу, то в комплект в обязательном порядке должны входить и исходные файлы.

    К исходным файлам уже можно предъявить требование по форматированию кода. Здесь самое главное — это обеспечить высокую читабельность. Обычно речь идёт об отступах, которые формируют визуальные блоки. Будут ли это пробелы или табуляторы — не имеет никакого значения, хотя табулятор проще и для использования и настраивается в любой кодерской программе (то есть у верстальщика и проверяющего могут быть разные настройки по своим предпочтениям, пробелы же фиксированы).

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

    Всё это приводит к первому важному критерию оценки: код должен быть аккуратным и читабельным. Неряшливость кода — больше демонстрируюет неуверенность и неумение его создавать.

    Хорошо оформленный код ещё ничего не говорит о его качестве. Например верстальщик написал css-класс из 10 стилей и красиво его оформил. Если на странице таких классов несколько десятков/сотен, то никто не будет проверять каждый стиль: скажем вместо padding нужно было использовать margin , а для выравнивания использовать не float , а flex . Погружаться в код, чтобы его полноценно изучить,- потребуется не только соотвествующая квалификация проверяющего, но и немалого времени. Чтобы упростить эту задачу кодер, по возможности, должен комментировать свой код.

    Поэтому следующий критерий — комментирование своего кода. Особенно это важно, когда известно, что код будут проверять или менять в будущем. Обычно при верстке комментарии размещаются в css/sass-файле, но не везде, а только там, где необходимо уточнить смысл (отвечать на вопрос «для чего это сделано?»). В PHP комментирование вообще является обязательной практикой, включая описание функций, параметров, алгоритма и т.п. В HTML комментирование не так актуально, но всё-равно в некоторых случаях это необходимо.

    Покажу на простом примере с использованием атомарных классов UniCSS. Вот такой простой блок (можете его загрузить в UniCSS.Builder и проверить):

    Здесь может возникнуть вопрос зачем верстальщик использовал класс mar0 (это margin: 0 )? На самом деле это нужно, чтобы обеспечить 20px отступ, который задан у родительского блока, ведь H3 имеет ещё и свой 10px верхний отступ. Если померить линейкой, то без mar0 отступ окажется больше. Это неочевидный момент, которы можно легко упустить из виду. Более того, может возникнуть ощущение, что css-класс вообще лишний. Но верстальщик сделал «пуленепробиваемый» код, где H3 можно заменить на любой другой тэг. Осталось только указать это в коммментариях. Теперь код не только хорошо читается, но и понятен его смысл:

    При этом описывать смысл bg-green или bg-gray нет необходимости — это очевидные классы, используемые по своему прямому назначению.

    Другой критерий — это понимание основ HTML. Например при html-верстке использование BR вместо P — будет большой ошибкой. Также довольно большая проблема — «новые» семантичные html-тэги, вроде SECTION, ARTICLE и т.п. Использование данных тэгов всегда сопряжено с риском нарваться на критику по их неверному использованию. Верстка — это в первую очередь положение элементов, а семантика обычно требуется на уровне SEO. Поэтому более надежней будет верстать на «обычных» тэгах, а семантику расставлять на заключительных этапах, в зависимости от пожеланий клиента.

    Ещё очень важно понимать структурный подход к html-верстке. Современная верстка — модульная, где каждый блок представляет собой некий «компонент» и в идеале должен без каких-либо переделок менять своё положение на странице. Такой подход базируется на разделении модульной сетки сайта от составляющих её блоков. Модульная сетка — это каркас, фундамент, который отвечает только за компоновку главных блоков. В CMS обычно это шапка, подвал, основной контент-блок и сайдбары. При этом модульная сетка может содержать общий контейнер для всех этих блоков — это необходимость, если нужно визуально их объединить (тень, фон или граница).

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

    Отдельно стоит отметить верстку лендингов, где часто нет общего контейнера и модульной сетки как таковой (точнее это один общий BODY). Здесь верстальщик должен понимать, что каждый блок лендинга должен быть сверстан так, чтобы мог поменять своё положение на странице. Особо интересны случаи, когда блоки могут занимать разную ширину: в центре по всему браузеру, по центру с ограничением, по краям браузера и т.п. В этом случае модульная сетка как раз и описывает такое расположение, а внутреннее содержимое отвечает за поведение внутри этого контейнера.

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

    Существуют ли критерии оценки качества CSS-кода (вне описанных выше критериев)? Здесь всё сложно. CSS позволяет решать задачи разными способами, поэтому сказать, что какой-то вариант лучше другого, проблематично. Единственным вариантом, пожалуй, будет выбор в пользу более простого и понятного кода. Если нужно задать отступ, то используем margin или padding , но не line-height . Первые простые и понятные, второй более сложный и не такой очевидный. То есть по возможности css-код должен быть как можно проще.

    Мне иногда приходится разбирать сложные css-классы, где ученики использовали с десяток стилей. Как правило это обычное copy/paste с какого-нибудь старого сайта. Объяснить зачем нужные те или инные строчки ученик не может: если код работает, то вроде как всё правильно. Но потом оказывается, что такой код излишний, а задачу можно было решить гораздо проще, нужно было просто над ней подумать.

    При именовании css-классов нужно придерживаться какого-то одного стиля или методики. Если всё в разнобой, неявные имена классов, то такой код «грязный» потому что его будет сложно поддерживать. Представьте себе, что этот код будет переделывать другой верстальщик, а значит он должен его понять. Львиная доля времени уходит не на исправление/доработку css-кода, а на поиск его классов в html-коде и sass-файлах.

    Именно поэтому верстальщики массово и переходят на Atomic CSS.

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

    В современных реалиях верстка должна быть адаптивной. Поведение блоков нужно задавать для разной ширины экрана и обязательно проверять в браузере ( Ctrl+Shift+M в FireFox). Настройка адаптивности порой занимает больше времени, чем для обычного десктопа. Часто это приводит к появлению дополнительных css-классов, которые не всегда очевидные с первого взгляда. Верстальщик, после того, как настроил десктопную версию, должен отработать меньшие экраны. Если появляется горизонтальный скроллинг, это значит, что адаптивность скорее всего вообще не настраивалась. Бывают, конечно, сложные блоки, но горизонтальный скролл недопустим.

    Затрагивая адаптивность, нельзя не упомянуть о требовании pixel perfect. С моей точки зрения попиксельное соответствие макету возможно, но с рядом оговорок — дизайнер должен проработать все экраны, а также использовать рендеринг шрифтов, скругления, тени и прочие дизайнерские элементы как в браузерах, а не как это делает фотошоп. Потому что когда дизайнер предусмотрел отступ 8px, а размер шрифта 14.8px при непонятном интерлиньяже, то «пиксель перфект» превращается в откровенный мазохизм.

    Адаптивность — это «резиновая» верстка, где описывается поведение элементов (выравнивание, отступы и т.д.), причём часто на произвольных текстах и иконках. Задать здесь точные пиксельные размеры уже проблематично, поэтому на сегодняшний день требования к pixel perfect обычно сводятся к «как можно ближе к макету». Если перевести на числа, то в больших блоках (более 50px) точность 10..20px, а на малых 5..10px, вполне достаточна. Поэтому я думаю, что требование к pixel perfect на сегодняшний день мягко говоря неактуальна. В реальности такая точность просто не нужна.

    Цукерберг рекомендует:  Представление LESS

    Вот, собственно, и все критерии. Мало, потому что это все имеет непосредственное отношение к работе верстальщика. Всё остальное — это методики и инструменты. Нет никакого смысла обсуждать и требовать html-валидации кода — это и так очевидно. Нет никакого смысла указывать на необходимость использования resets.css или normalize.css — это очевидно даже новичку. Нет никакого смысла указывать на необходимость тестирования верстки на разных экранах — это даже не сколько тестирование, сколько непосредственный процесс верстки. В лучшем случае все эти дополнительные требования можно оформить в виде чек-листа, благо Интернет ими заполонён.

    Впрочем возникает ещё один вопрос: как оценить профуровень самого верстальщика? Скорее всего лучшим способом будет его тестирование. Но не опросник/анкета, а практическое задание на верстку каких-то блоков или небольших страниц с обязательным комментированием своего кода. Можно усложнить задачу, например выдвинув требование на использование какого-то css-фреймворка или, наоборот, только свой «ручной» код. Такое тестирование может показать реальный уровень подготовки и способность решать поставленные задачи.

    Урок 7. Блочная верстка web-сайта. Часть 1

    Наиболее популярной является блочная верстка сайта или div верстка. Наш урок блочной верстки сайта поможет начинающим освоить основные приемы div верстки.

    1. Основные понятия

    Многие web-дизайнеры отдают предпочтение блочной верстке сайта, которая осуществляется с помощью тега

    Блок – это обычная прямоугольная область, обладающая рядом свойств, таких как: рамка, поля и отступы (рис. 1). Содержимым блока может быть что угодно – текст, картинки, списки, формы для заполнения, меню навигации и т.п.

    Рамка (border) – это контур, для которого можно задать такие характеристики как толщина, цвет и тип (пунктирная, сплошная, точечная).

    Поля (padding) – отделяют содержимое блока от его рамки, чтобы текст, например, не был «впритык» к стенкам блока.

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

    Блочная верстка сайта включает в себя блоки. Блоки, как и таблицы – это элементы, всегда располагающиеся на странице вертикально. То есть, если в коде страницы записаны подряд два блока, то отобразятся они в браузере один под другим. Если нам нужно расположить несколько блоков горизонтально, то в их свойствах задается такой параметр как «обтекание» (float). Но об этом чуть позже.

    В данной работе мы создадим web-страничку из блоков. Сначала создадим контейнер, в который, как в коробку сложим наши блоки. Для наглядности каждый блок будет иметь свой цвет. Конечный результат должен быть таким как на рис. 2.

    Контейнер будет содержать в себе пять блоков:

    TOP – шапка сайта, обычно содержит логотип компании, название, заголовки и слоганы, поиск, навигацию;

    LEFT и RIGHT – левая и правая колонки, обычно содержат рекламу, навигацию, рассылку, новости и т. д.:

    CENTER – содержит основной текст страницы;

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

    Для теста нашего сайта нам понадобятся как минимум три самых популярных браузера – Opera, Fire Fox, Internet Explorer.

    Описание web-страницы в основном делается в CSS документе.

    2. «Фиксированный» дизайн методом блочной верстки

    1. Создайте в блокноте новый документ с расширением css и сохраните его под именем mystyle.css.

    2. Создайте HTML-документ и сохраните его в той же папке.

    3. В самом начале HTML-документа впишите следующую строку:

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

    Мы определили нашу страничку в соответствии с DOCTYPE под названием Strict 1.0.

    Требования здесь весьма строгие – все тэги, не имеющие закрывающей пары, должны заканчиваться пробелом со слэшем / перед закрывающей угловой скобкой. Но вот ведь сам DOCTYPE тоже выглядит как тэг! Почему же у него нет этого пробела со слэшем? А просто! Захотелось так разработчикам этих строгих правил. Но это единственный случай, где правило не работает.

    4. Одной строкой между тегами и присоедините документ mystyle.css к документу HTML (рисунок 3).

    5. В таблице стилей наберите код как на рисунке 4.

    # этот знак говорит, что элемент является уникальным атрибутом и используется в HTML документе в теге div один раз.

    6. Добавьте в mystyle.css шапку сайта (рисунок 5).

    7. Добавим HTML документ следующий код между тегами body (рисунок 6).

    И у Вас должно получиться следующее (рис. 7).

    Следующим этапом блочной верстки сайта является расположение трех блоков последовательно по горизонтали, для этого в блочной верстке, как правило, используется элемент float. Он позволит обтекать другим элементам наш блок справа или слева.

    8. Откройте css-документ и добавьте следующий код (рисунок 8).

    Каждая строка кода имеет комментарий, заключенный в скобки /* комментарий */, который не отображается в браузере. Напомню, элементы со знаком # используются в теге div >

    9. Сразу после закрывающегося тега

    10. Откройте HTML-документ в браузере. Должно получиться такая div верстка (рисунок 10).

    11. Теперь добавьте блок footer самостоятельно. Браузер должен показать такую блочную верстку сайта (рисунок 11).

    Рассмотрим атрибуты relative и absolute.

    Иногда бывает необходимо разместить какой-то блок в строго заданном положении относительно родительского.

    Рассмотрим простейший код.

    1. Создайте html-документ, в теле которого разместите код, как на рисунке 12.

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

    Попробуем сделать так (т.е. абсолютно позиционируем дочерний блок относительно родительского).

    2. Создайте таблицу стилей, в которой наберите код из листинга на рисунке 13.

    3. Проверьте web-страничку в браузере. Вот что получилось (рисунок 14). Это не то, что мы хотим, не так ли? Наш дочерний элемент ушел не к маме, а к дедушке (т.е. BODY)!

    Проблема решается довольно просто: родителю дополнительно задаётся position: relative;

    4. Измените код своей таблицы стилей в соответствии с рисунком 15.

    5. Проверьте web-страничку в браузере. Результат на рисунке 16. Оцените разницу.

    Создать web-страницу, внешний вид которой изображен ниже на рисунке 17

    3. «Резиновый» сайт методом блочной верстки

    В заданиях 1 и 2 мы рассмотрели «фиксированный» дизайн методом блочной верстки, т.к. все блоки имели точное значение по ширине и высоте в пикселах.

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

    Задание 3. Создадим «резиновый» блочный макет как на рисунке 18.

    1. Создайте HTML-документ с кодом, как на рисунке 19. Сохраните документ.

    2. Создайте таблицу стилей как на рисунке 20. Сохраните документ. Вы должны получить результат ка на рисунке 18.

    3. Изменяя размеры браузера, проанализируйте поведение макета.

    4. Комбинированная блочная верстка

    Комбинированная блочная верстка (div верстка) включает как блоки фиксированной ширины, так и блоки в процентном отношении к ширине экрана.

    Задание 4. Создадим комбинированный блочный макет как на рисунке 21.

    1. Создайте HTML-документ с кодом, как на рисунке 22.

    2. Создайте таблицу стилей как на рисунке 23. Сохраните документ. Вы должны получить результат ка на рисунке 21.

    3. Изменяя размеры браузера, проанализируйте поведение макета.

    Методом блочной верстки создайте web-страницу для сайта архитектурных проектов коттеджей так, как изображено на рис. 24. Изображение для шапки сайта (shapka_div.jpg).

    Требования к макету:

    • В HTML-коде не должно быть локального форматирования элементов, все оформление должно быть сделано через внешнюю таблицу стилей;
    • При наведении на ссылку «Проекты таунхаусов и блокированных домов» гиперссылка должна менять цвет (рис. 24);
    • При нажатии на гиперссылку «Проекты таунхаусов и блокированных домов» должна загружаться страница о проектах, внешний вид которой изображен на рис. 25.
    • При нажатии на логотип должна загружаться главная страница сайта (рис. 24).

    Тестирование верстки

    Зачем тестировать верстку?

    «Если звезды зажигают – значит – это кому-нибудь нужно»? Если макет отрисован до мелочей – казалось бы, так и должно получиться в итоге! Но есть один нюанс: страница должна не только соответствовать макету, но и работать.

      • тестирование внешнего вида;
      • тестирование адаптированности страницы.

    Возникает вопрос: а так ли важно тестирование интерфейса? Это ведь не функционал и не безопасность. Разве не может верстальщик сравнить заданную картинку с тем, что получилось в итоге? Может! Но замечать детали – это все-таки удел тестирования. Кроме того, не стоит забывать и про человеческий фактор: у верстальщика часто просто «замыливается глаз» в процессе работы. Хотите проверить свою внимательность? Посмотрите это небольшое видео, и Вы удивитесь, сколько всего очевидного можно не заметить.

    Как тестировать внешний вид страниц?

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

    Начнем с тестирования внешнего вида страницы. В первую очередь сравним имеющуюся страницу с макетом. Блоки должны совпадать с макетом идеально, для текста же существует допустимый зазор в 5 рх. Для измерения таких деталей существует инструмент PerfectPixel: достаточно наложить полупрозрачный макет на итоговое решение – и мы сразу увидим различия, ежели таковые имеются.

    После проверки общей картинки переходим к деталям. Разобраться со шрифтами поможет, например, What Font. Проверить многообразие цветов – Color Zilla. Убедиться в правильности написания контента – Spell Checker или Орфограф Артемия Лебедева (в Орфограф мы вводим адрес своей странички, после чего все неизвестные или неправильно написанные слова выделяются цветом, который мы сами выбираем).

    Как проверить адаптированность страницы?

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

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

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

    По клику на картинку откроется полная версия.

    Копаем вглубь страницы!

    Можем ли мы после учета всех перечисленных ранее проверок остановиться и выдохнуть? Нет! Итак, курсор на кликабельных элементах появляется. Теперь пришло время проверять ссылки, ведь они могут открыть как заложенную в логику программы информацию, так и всем нам печально известную страницу 404. Ссылка на наш или чужой контент может устареть, а отследить такие моменты поможет приложение Black Widow. Периодически запуская проверку сайта с его помощью, мы получим возможность отследить битые ссылки раньше, чем их найдут пользователи.

      • кодировка UTF-8 (либо другая оговоренная в ТЗ);
      • стандарт HTML;
      • стандарт CSS (стоит отметить, что в этой проверке предупреждения допустимы, а ошибки – нет).

    В правильности соблюдения стандарта написания кода мы можем убедиться с помощью сервисов от w3.org: достаточно написать адрес страницы в специально отведенное поле и запустить проверку. Все, что не попадает под «стандарты», будет обозначено словом ERROR.

    Как мы можем заметить по скриншотам проверки, валидатор выдает сообщения об ошибках, так как он опирается на самые свежие правила и стандарты. К сожалению, это не всегда можно сказать о ПО: при появлении изменений код далеко не всегда пересматривается и переписывается (тем более, если по факту он остается рабочим). Кроме того, нередко при создании программы применяются «авторские» решения, абсолютно правильные с точки зрения работы страницы, но невалидные для общепринятых стандартов. Сможет ли сам тестировщик определить, насколько критичны найденные ошибки? Скорее всего, потребуется консультация специалиста, умеющего писать код. Некоторые ошибки повлекут за собой серьезные исправления, в других же случаях вполне достаточным будет «причесать» элементы кода или тэги до их обновленной версии. После корректировки код станет идеальным, стандартизированным и не вызывающим ни единого подозрения… До следующего обновления стандартов.

      • при отключенных картинках;
      • при выключенном Flash;
      • при выключенном JavaScript.

    Даже во время загрузки страница должна выглядеть достойно: все надписи должны быть читабельны, картинки – подписаны, основной функционал сайта – доступен. Это особенно важно в тех случаях, когда мы имеем дело с низкой скоростью интернета или же с дорогостоящим трафиком у клиента. Но в любом случае все они – наши пользователи: мы их любим и заботимся о них!

    Дополнительные возможности тестирования верстки

      • Веб-аналитика (Гугл-аналитика, Яндекс-метрика и пр.). Нужно убедиться в наличии самого счетчика в нашем коде и проверить корректность ID счетчика.
      • SEO. В этом случае мы обращаем внимание на тэги. На всех страницах, которые индексируются, должны быть прописаны тэги «keywords» и «description»; на не подверженных индексации страницах или конкретных элементах должен быть тэг «noindex».
      • Электронная коммерция. Цель тестирования – проверить информацию о завершенных покупках. Например, при просмотре ранее купленного товара должна выводиться информация о том, что данный продукт мы уже покупали. Другая возможность – просмотр всей предыдущей истории заказов: начиная с информации о номере и стоимости заказа и заканчивая видом и количеством товаров и адресом доставки (набор обязательных параметров задает заказчик на свое усмотрение).
      • Интеграция с соцсетями. Для отслеживания ответов, перепостов и лайков разработчик прописывает в коде определенный метод. Наша цель – найти этот метод и проверить его на работоспособность. Например, внешний вид кнопок для шаринга или отображаемых блоков для подписки должен быть узнаваем и визуально отличен от стиля другой соцсети. Другой важный момент: мы должны убедиться, что при появлении информации о каком-либо сообществе или человеке контент отобразится корректно (пост будет выглядеть постом, а картинка – картинкой).

    Выводы

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

    Однажды руководство одной из служб перевозок города N приняло решение добавить строку с именем клиента в окно заказа для водителей. Идея была немедленно передана разработчику. Разработчик буквально за пару часов справился с задачей, после чего было запущено обновление программы. Практически сразу в техническую поддержку начали поступать жалобы на слишком мелкий текст в измененном окошке. Сама идея водителям понравилась, но теперь самую важную информацию – адрес клиента – приходилось искать глазами. Замечания были переданы в разработку.

    Цукерберг рекомендует:  Php - Почему нужно писать это условие с $_SERVER['REQUEST_URI']

    Вскоре новая версия программы была подготовлена, строку «адрес клиента» увеличили до предыдущего значения. Отдел тестирования приготовился к своей непосредственной работе, но руководство решило отказаться от проверки, основываясь на мнении работников технической поддержки, измученных постоянными звонками: «Да там только адрес увеличили, подумаешь! Пока проверим – наши телефоны взорвутся. Запускайте обновление!»

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

    В этой статье мы кратко рассмотрели необходимость тестирования верстки и некоторые методы этого тестирования. Все они – простые или более сложные – послужат на пользу продукту. Выбор же оптимального набора методов в каждом конкретном случае остается за Вами!

    Тестовое задание для кандидатов на вакансию: «WEB разработчик, HTML верстальщик»

    Перед началом выполнения тестового задания, пожалуйста, убедитесь, что данная вакансия открыта. Ознакомиться со списком актуальных вакансий можно на https://career.pixelplus.ru.

    Тестовые задания представлены в 3-х уровнях сложности и состоят из следующих частей:

    • Макет в JPG.
    • Макет в PSD (разбит по слоям и сгруппирован по папкам).
    • Текстовое описание задания и требования.

    Общие требования и пожелания

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

    Схема получения и сдачи задания

    После того как вы выберите уровень задания, вам необходимо сообщить по адресу hr@pixelplus.ru (тема письма «Тестовое задание на вакансию «WEB разработчик, HTML верстальщик»») о том, что вы приступили к выполнению задания (в письме укажите выбранный вами уровень) и ориентировочные сроки его выполнения.

    Результат должен быть представлен в виде архива с версткой макета, указанием затраченного времени и возможных комментариев к макету.

    Вступление на путь верстальщика

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

    Что же такое верстка?

    Если вкратце, то это процесс создания страницы сайта. Заметьте, статичной страницы, без каких либо скриптов. Верстальщик использует языки разметки, в данном случае подразумевается HTML5/CSS3, с помощью которых размечает страницу. Создает ее с самого зеро, то есть с пустого документа.

    HTML – используется исключительно для разметки. CSS или каскадные таблицы стилей – для управления потоком документа, придания элементам, заранее созданным в разметке определенной формы, размещения их в том или ином порядке, манипуляций с текстом, размерами etc. Они идут в связке.

    В итоге получается готовая страница сайта. Сайты верстают, чаще всего с psd макетов, которые предоставляет дизайнер. Макет разбирают в фотошопе. После верстки готовый документ не является завершенным сайтом. Это просто оболочка, причем статичная. Дальше идет обработка с помощью JS, подключение скриптов, работа серверных программистов и еще куча всего.

    По сути, если собрался становиться именно верстальщиком, то необходимо не слишком большое количество скиллов.

    Однако верстальщики сейчас на рынке не так востребованы. Намного чаще требуются именно фронтендеры. Фронт-енд – клиентская сторона создания сайта. То есть работа на стороне браузера. Если сильно обобщить, то она включает в себя как верстку, так и работу со скриптами.

    Есть еще бэкенд. Бэкенд – серверная сторона, отвечает за взаимодействие с сервером, непосредственно работу сайта, оперирование данными от пользователей и т.д. В этой пасте бэкенду почти ничего не посвящено. Материалов у нас очень мало, ткак не то направление. Если кто поделится, будем рады пополнить свои закрома.

    Так вот, фронтендер, даже самый начинающий должен знать сильно больше верстальщика. Тут лучше продублирую ОП-пост:

    На данный момент фронтендеру новичку нужно учить больше, чем просто HTML/CSS. В частности необходимы продвинутые инструменты разработки, автоматизаторы, работа со скриптами, сам Js и Jquery, в перспективе что-то из Js фреймворков, MVC и прочего дерьма.

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

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

    И это отмечу, далеко не предел, даже на начальном этапе расти есть куда. Вариантов масса. От псевдотрехмерных техник создания сайтов на параллаксе, до запила крутых приложений на JS, с перспективой перехода на мобильные платформы. Да что там говорить, даже игры умудряются пилить, и довольно удачно.

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

    Основные направления: фриланс или конторки.

    О фрилансе ты наверняка слышал хоть немного. Есть местные или зарубежные биржи, где люди выкладывают свои заказы разных уровней. От «поправь шрифт на сайте для мобильных версий» до «запили мне рабочий аналог фейсбука за 30 долларов» (утрировано). Из зарубежных самый популярный – Upwork. Кстати в воркаче есть постоянно живущий тред по апворку, где можно узнать больше информации, советую читнуть тамошний фак.

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

    Конторки – местные кружки веб-макак локального или глобального уровня. Пилят от мелких сайтов торгашам с рынка, до довольно крупных продаваемых приложений (если тебе повезло в такую попасть со старта). Основная задача местных анонов – пробиться в одну из них. Собственно, материалы в треде как раз и предназначены для того, чтобы выбить ентри левел. Через несколько месяцев пребывания там, ты, если не конченый дебил, уже и сам будешь знать, что тебя ждет, что дальше делать и куда двигаться.

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

    МАТЕРИАЛЫ, ПОЛЕЗНЫЕ ССЫЛКИ И СОВЕТЫ ПО ОБУЧЕНИЮ.

    Сначала вкратце по процессу обучения: если совсем нихуя не знаешь, то лучше начинай учить именно HTML/CSS. Сверстаешь свой первый макет – учись верстать адаптивно. Почитывай материалы в инете, разные статейки, смотри интересные примеры, практикуйся, спрашивай непонятное в треде, читай литературу представленную здесь и ищи что-то сам. Постепенно придет понимание всех этих процессов, и че это вообще за хуйня. Как почувствуешь уверенность в верстке – перекатывайся на JS (мастхев, если хочешь развиваться). Можешь параллельно прикручивать готовые скрипты к своим сайтикам, смотреть что как работает. Ну а дальше работы не паханое поле. Двигайся, куда тебе захочется.

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

    1. Первичные материалы в хаотичном порядке. Они часто дублируют друг друга. Можно проходить что-то одно по одному из направлений. Личные предпочтения выскажу ниже.

    http://htmlacademy.ru/ — ультрагоднота, советую начинать изучение HTML/CSS отсюда. У них же есть интенсивы (обучающие видеоуроки, для лучшего понимания предмета, тоже мастхев) ссылки чуть ниже.

    http://learn.javascript.ru/ — по JS на русском лютая годнота. Годнее только Флэнаган. Лучше начинать учить язык отсюда, потом уже книги.

    http://codeschool.com/ — тут платно, но есть бесплатные курсы, годные вещи про jquery и git

    http://htmlbook.ru/ Справочник. Каждый верстальщик пользуется им. Все непонятное смотрим там.

    http://teamtreehouse.com — тут все платно, но первые две недели бесплатно, можно успеть пройти пару курсов, объясняют хорошо.

    Интенсивы от академии:

    Базовый интенсив HTMLacademy за 2015 год:

    Продвинутый интенсив HTMLacademy за 2015 год:

    Лично я бы советовал сначала браться за http://htmlacademy.ru/ . В идеале пройди базовые курсы у них на сайте, затем купи/скачай с торрента интенсивы, пройди их.

    Курсы дадут понимание элементов верстки, но только разрозненное. Вряд ли ты сможешь после них сверстать полноценный сайт самостоятельно, это нормально. Для того и нужен базовый интенсив. После него ты сможешь делать фиксированные простенькие странички. Запили минимум 3 из представленных учебных макетов. Практика просто необходима.

    Затем переходи на продвинутый интенсив. Твоя основная задача там — освоить продвинутые инструменты верстки и адаптивность. Сверстай парочку тамошних тестовых макетов применяя все вышеописанные технологии и приемы.

    Дальше можешь выкачивать макеты с простор интернета и верстать уже их. Наращивание сложности приветствуется. Где не прописана адаптивность, тоже запили сам. Старайся в каждом новом проекте улучшать код. Черпай инфу из инета и литературы. Узнавай полезные приемы.

    Не лишним будет ознакомиться с сетками на flexbox и прочими новыми фишками. Вот здесь уже можно проплатить, если есть желание, продвинутые курсы в академии. Месяц там стоит 300 рублей, и за это время ты вполне успеешь пройти все даже дважды. Это не то чтобы мастхев, но понимание работы ксс-анимаций, хороших практик верстки, различных продвинутых элементов в новой спецификации и т.д. там дается. Хотя я буду лукавить, если скажу что всю эту инфу нельзя найти в инете и в разрозненном виде.

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

    Тут надо выбирать индивидуально. Если по HTML/CSS, то желательно, чтобы книга была не старше 2012 года, ну или хотя бы переиздана. Читай все что интересно. В любом случае это будет полезно.

    http://www.ozon.ru/context/detail/id/20279391/ — «Создаем динамические веб-сайты с помощью PHP, MySQL, JavaScript и CSS» Весьма неплохая книга, бегло позволит ориентироваться в основах веб-технологий и понять, как же все это говно вместе работает.

    http://habrahabr.ru/post/240219/ — «Выразительный Джаваскрипт» Хавербек Марейн. Вводна книга по JS и программингу в целом. Для новичков может быть сложноватой.

    http://frontendbookshelf.ru/ — список полезных книг. Большинство актуальны, можно выбрать по языку, технологии и конкретному уровню знаний. Первооочередную литературу желательно брать оттуда.

    http://scanlibs.com/ что-то типа хранилища айти книг. Скачать книги можно бесплатно. Там есть дохуя всего. Если в свободном доступе не найдете, попробуйте поискать там.

    Учебное задания УЛЬТРА ХАРДКОР ЛЕВЕЛ. Если считаешь, что тебе мало учебной хуйни. Сделай это и положи к себе в портфолио. Будет что показать на собеседовании. На данный момент устарели, но попрактиковаться все-таки можно:

    Появились новые тренировочные задания с ТЗ:

    ПРИМЕРЫ ВЕРСТКИ ДЛЯ САМЫХ МАЛЕНЬКИХ:

    Внизу видеокурс о том, как верстать PSD шаблон. Просто пример, чтобы посмотрели как выглядит работа и как верстают С НУЛЯ.

    Лично я все же посоветую черпать инфу по базовой верстке из интенсивов, ссылки чуть ниже. Там ребята показывают весь процесс и делают это качественно. Никаких ошибок, минимум стилизации и отсебятины.

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

    Оцените, пожалуйста, качество верстки

    Рекомендованные сообщения

    Создайте аккаунт или войдите в него для комментирования

    Вы должны быть пользователем, чтобы оставить комментарий

    Создать аккаунт

    Зарегистрируйтесь для получения аккаунта. Это просто!

    Войти

    Уже зарегистрированы? Войдите здесь.

    Похожие публикации

    Первый раз создаю сайт на хостинге. Не видит блок о компании. Он в конструкции есть, на сайте пустота.

    Верстальщик HTML (HTML-верстальщик)

    HTML-верстальщик – это специалист, выполняющий вёрстку web-страниц. Другими словами, он создаёт HTML-шаблон для web-сайта с использованием знаний HTML-кода и всех особенностей стиля и графического оформления. Профессия подходит тем, кого интересует информатика (см. выбор профессии по интересу к школьным предметам).

    HTML — аббревиатура от Hyper Text Markup Language (англ.) — это язык разметки гипертекста, принятый в World Wide Web для создания и публикации web-страниц. Соответственно, HTML-верстальщик – это специалист, выполняющий вёрстку web-страниц. Другими словами, он создаёт HTML-шаблон для web-сайта с использованием знаний HTML-кода и всех особенностей стиля и графического оформления. Созданный код должен одинаково отображаться во всех браузерах («кросс-браузерность») с учетом разных разрешений монитора и количества цветов.

    Особенности профессии

    Верстальщик посредством кода HTML, CSS и JavaScript создает HTML-шаблон, реализация которого состоит из нескольких этапов:

    • анализ графического дизайна сайта;
    • подборка модели шаблона;
    • нарезка графических спрайтов;
    • сборка HTML-шаблона.

    В настоящее время существует большое количество компьютерных программ, которые автоматизируют труд верстальщика, различные текстовые редакторы с подсветкой кода, визуальные редакторы (Notepad++, Adobe Dreamweaver), front-end фреймворки (наборы фрагментов кода и библиотек классов для ускоренной разработки макета сайта путем прототипирования — ZurbFoundation-4 и т.п.). Они позволяют писать большие фрагменты кода в наглядном режиме, то есть результат каждого этапа работы можно наблюдать в отдельном окне. Но профессиональный HTML-верстальщик этими программами не пользуется. Он должен уметь использовать кодировку HTML вручную, без помощи визуальных редакторов, чтобы обеспечить максимальную корректность кода в минимальном весе.

    HTML-верстальщик должен знать каскадные стилевые таблицы CSS, владеть JavaScript и базовыми навыками web-программирования на языках PHP, Perl или Java, а также основными графическими редакторами Photoshop, Fireworks, Gimp. Опытный верстальщик может создать небольшой сайт, используя текстовый редактор Microsoft Word c минимальным количеством средств и инструментов.

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

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

    Плюсы и минусы профессии

    Плюсы:

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

    Минусы:

    • присутствует доля рутинности и однообразия
    • необходимость долговременного сидения за компьютером

    Место работы

    Интернет-компании, фирмы по разработке сайтов, дизайн-студии, организации со своими интернет-проектами, фрилансерская работа.

    Понравилась статья? Поделиться с друзьями:
    Все языки программирования для начинающих