Фреймворков, таких как или , которые существенно облегчают и ускоряют верстку страниц.
подразумевает под собой отличное отображение веб страницы на всех устройствах и расширениях мониторов. Наверное, не у каждого верстальщика имеется полный набор девайсов со всеми возможными расширениями дисплеев, для тестирования своей верстки
. Это и не удивительно, ведь техника нынче не дешевая.
Итак. Покупать горы мобильников и планшетов, не вариант - разоримся. Что же делать? Для этих задач были разработаны сервисы для тестирования адаптивных сайтов
. Принцип работы их очень прост. Чаще всего имеется фрейм определенного размера, где открывается страница. Эффект получается примерно такой же, как и при просмотре на мобильном устройстве. Хочу заметить, что сервис не всегда в точности покажет отображение страницы на телефоне или планшете. При верстке следует тестировать с помощью сервисов, но после завершения, по возможности, протестировать на наиболее распространенных устройствах.
Итак. К вашему вниманию лучшие инструменты для тестирования адаптивных сайтов
.
Инструмент для тестирования адаптивных сайтов от компании Adobe. Для его использования требуется установить себе на компьютер.
Программа позволяет синхронизировать ваши устройства по WIFI и просматривать сайт так, как он будет отображаться на вашем девайсе. На данный момент поддерживаются устройства с такими ОС: iOS, Android, Kindle Fire.
Тест показывает, как выглядит адаптивный сайт на различных мобильных устройствах. Для проверки ваш сайт должен поддерживать загрузку и работу во фреймах. Для удобства просмотра переведите браузер в полноэкранный режим.
Проверить
Что такое адаптивный сайт?
Адаптивный сайт автоматически подстраивается под ширину устройства. При этом блоки сайта могут скрываться или видоизменяться. Например, на компьютере логотип и меню сайта располагаются слева направо, а на телефоне — сверху вниз.
Чем отличается адаптивный сайт от мобильной версии?
Если у сайта есть мобильная версия, то при загрузке такого сайта с мобильного телефона, вас перенаправят на другой адрес: site.ru → m.site.ru. Мобильная версия — это отдельный сайт с другим адресом.
Если же у сайта нет мобильной версии, адрес сайта не изменится при загрузке с телефона. На телефон будут загружаться те же самые данные, что и на компьютер. Чаще всего это неудобно для пользователя, потому что экран телефона меньше в несколько раз.
Данная проблема решается двумя способами: добавить мобильную версию m.site.ru или НЕ делать отдельный сайт, но добавить вашему основному сайту адаптивности. Это специальные стили и скрипты, которые включаются, если ширина экрана слишком мала: например, спрятать меню, увеличить шрифт, вместо крупных изображений показать маленькие и т.п.
Строго говоря, нельзя сравнивать адаптивный сайт и мобильную версию сайта. По сути адаптивный сайт = полная версия + версия для планшетов + версия для телефонов (мобильная), и всё это в одном флаконе. То есть, одно понятие заключено в другом.
Адаптивный сайт совмещает в себе и обычный (для PC), и мобильный (для телефонов), и несколько промежуточных вариантов (крупные телефоны, планшеты, телевизоры и т.д.). Главное преимущество адаптивного сайта — он хорошо выглядит на любой ширине экрана.
Почему ширина телефона в данном сервисе такая маленькая?
Реальное количество пикселей на современных гаджетах, как правило, очень велико, а сайты не рассчитаны на такую огромную ширину. Поэтому мобильные устройства с экранами повышенной чёткости открывают сайты, приведя их к некоему виртуальному стандарту. Чтобы узнать эти цифры у себя, нажмите кнопку, открыв эту страницу с телефона или планшета:
Какой у меня размер окна браузера?
На устройствах с ретино-подобными дисплеями показанные размеры будут отличаться от реального разрешения в пикселях, которое указано в спецификации устройства. Смартфоны покажут 320×480 или 480×800 пикселей, планшеты — 1280×800.
Здравствуйте, дорогие читатели блога. Как уже и не удивительно, что адаптивный дизайн становится всё популярнее в русском интернете. И конечно же верстальщикам нужно изучать его. Так как адаптивный дизайн скоро будет практически на всех сайтах, потому что всё больше лди пользуются мобильными устройствами.
И хочется сказать, что сайты с на много удобнее читать на таких устройствах нежели без него.
Сегодня я хочу представить Вам 5 очень полезных и классных сервисов, с помощью которых Вы сможете проверить сайт на адаптивность.
И так, поехали.
5 сервисов на которых можно проверить сайт на адаптивность.
www.responsivedesigntest.net
Хороший сервис для проверки сайтов. Есть множество разрешений экранов как планшетов так и телефонов.
mattkersley.com
Простой сервис для проверки сайта на от Matt Kersley. Так же доступны все популярные разрешения мобильных девайсов.
screenqueri.es
Очень классный сервис, который проверит любой сайт. Очень понравилось оформление, а так же функциональность.
quirktools.com
Очень красивый и функциональный сервис. Есть возможно даже проверить как будет выглядеть сайт на телевизоре:-)
Одна из самых примечательных задач, которая когда-либо стояла перед QA-отделом EastBanc Technologies, заключается в создании автоматизированной системы тестирования сайта
www.washingtonpost.com . Это электронная газета, реализованная в виде информационного и новостного портала.
Основной причиной необходимости создания системы автоматизированного тестирования явилось то, что в приложении был запланирован переход на новую CMS (так называемый PageBuilder), которая должна заменить несколько других CMS, используемых до этого для публикации контента в различных разделах сайта. При подбного рода миграции очень важно не допустить ошибок, чтобы опубликованный через новую CMS контент на различного рода страницах выглядел надлежащим образом.
Перед нами не стоит задачи проверить все страницы на соответствие нашим тестам. Наша задача - выявить баги PageBuilder’a, проверить надежность верстки страниц, созданных свежеиспеченным PageBuilder’ом, обратить внимание редакторов Вашингтонпоста на те ньюансы наполнения конкретной страницы контентом, которые могут повлечь за собой потенциальные проблемы в отображении страниц.
Создание системы тестирования находится в стадии активной разработки, но некоторые, интересные на наш взгляд, моменты уже можно представить на суд широкой публики.
Прежде чем мы это сделаем, необходимо отметить одну особенность проекта: все тестирование у нас происходит «снаружи». Т.е. мы, как и любой другой юзер, используем для тестирования боевую версию сайта.
Выбор инструментов тестирования верстки
Исследовав просторы интернета, мы остановились на следующих подходах и инструментах. Для тестирования каркаса страницы мы взяли на вооружение фреймворк
Galen , который после интегрировали с testNG.
Естественно, что пройденный Galen-тест для каркаса страницы еще не означает валидность верстки. Помимо месторасположения блоков, нужно еще проверять отображение различных элементов внутри блока. Внутреннее содержимое блоков мы решили тестировать методом сравнения скриншотов.
На откуп скриншот-тестов выпадают различные лого, кнопочки, некоторые блоки со специфичным отображением - все, до чего не дотягивается Galen и что сложно/невозможно проверить функциональными тестами.
Лазурным цветом - тестируется Galen’ом, залитое зеленым - скриншот-тесты:
Осторожно! Большая картинка
Скрытый текст
Galen и Screenshot тесты могут успешно заменять некоторые функциональные тесты, выигрывая при этом иногда в наглядности, иногда в быстродействии, а, бывает, и в том, и в другом. Выбор метода тестирования для конкретного случая осуществляется нами посредством коллективного обсуждения тест-кейса для каждого типа страниц на основании критериев быстродействия, простоты поддержки, полноты тестового покрытия и наглядности.
К примеру, есть 2 блока, на проверку которых у нас изначально были написаны функциональные тесты: Most Read и Information Block. Теперь мы первый проверяем скриншотами, а второй - гален-тестом.
MostRead Block, проверка скриншот-тестом:
Относительно функционального теста: строчек кода стало существенно меньше, полнота тестового покрытия увеличилась, и обновление теста при изменении внешнего вида данного блока на странице не займет много времени.
Тестирование этого блока рассмотрено в главе о скриншот-методе.
WaPo Information Block:
Galen без проблем справляется с проверкой соответствия текста и линков данного блока: сами ссылки заданы в локаторе, а соответствие текста - внутренней galen-проверкой. Относительно функционального теста полнота тестового покрытия не изменилась, но, за счет того, что проверки проходят в рамках одного теста, мы существенно экономим время.
Код Гален-теста .
Наша автоматизированная система тестирования использует: Java, Maven, TestNG,
Selenium WebDriver , Selenium Grid,
Galen Framework .
В создании Screenshot-based тестов нам активно помогает кроссплатформенный набор утилит
ImageMagick .
Сразу хотелось бы отметить, что код тестов мы пишем на Java с применением паттерна PageObject и фрейморка от Яндекс -
HTML Elements . Для запуска тестов используются maven и testNG.
Для облегчения запуска тестов, просмотра истории запусков тестов, просмотра отчётов без привлечения высококвалифицированных специалистов нами разрабатывается отдельное приложение - Dashboard.
Нелишне будет подчеркнуть, что сейчас мы всё ещё находимся на стадии исследования того, как правильно организовать весь процесс тестирования, и не все подходы ещё до конца освоены и изучены
Тестирование при помощи Galen Framework
Galen Framework обладает множеством несомненных преимуществ: это гибкий, простой в применении инструмент, имеющий широкие возможности тестирования адаптивного дизайна. Ко всему прочему, он неплохо документирован и активно развивается на данный момент.
Galen Framework уже был достаточно подробно описан в одной из
статей . Если кратко описать принцип работы с Галеном, то выглядит это примерно следующим образом: вы пишете спецификацию страницы (так называемый spec файл), используя специальный, хорошо документированный и интуитивно понятный синтаксис. В spec файле описывается взаиморасположение, размер, отступы, вложенность элементов страницы и некоторые другие параметры и условия, которым должна соответствовать верстка страницы, можете проверить даже соответствие текста внутри элемента. И все эти проверки будут применяться в зависимости от указанных нами тэгов.
Тэги в spec-файле могут задаваться таким образом:
Гален выполняет все проверки, после чего генерирует наглядный отчет в виде html-файла. В отчете указано, какие конкретно проверки провалились для данного теста, и для каждой из завалившихся проверок можно увидеть полный скриншот тестируемой страницы, где будут выделены элементы, не прошедшие конкретной проверки.
К примеру, не прошедшая проверка на расстояние между соседними элементами будет выглядеть в отчете следующим образом:
При клике на подсвеченную красным проверку отображается скриншот всей проверяемой страницы с такой подсветкой элементов:
Galen Framework принимает на вход следующие параметры:
- браузер, в котором будет проходить проверка
- разрешение, на котором следует запустить тест
- url тестируемой страницы
- Javascript-файл, который нужно (если нужно) применить на запускаемой странице до начала проверок по.spec файлу (например, если нужно проверить отображение страницы залогированному на сайте пользователю)
- имя запускаемого.spec файла
- тэги, которые необходимо применить к проверкам.spec файла (например: desktop, all, если мы тестируем лэйаут для десткопа).
Как видите, варьируя подаваемые Галену параметры можно добиться практически полного тестового покрытия каркаса нашего сайта.
После того, как определились с инструментом тестирования каркаса сайта, следующей задачей было выбрать схему, позволяющую обеспечить максимальное покрытие страницы Galen-тестами.
Выбор тестируемой страницы из подмножества однотипных страниц
А какие страницы выбрать для тестирования верстки, если тест предназначен для проверки множества однотипных страниц?
Мы решили, особо не заморачиваясь, при каждом запуске тест-сьюита выбирать рандомную страницу из подмножества (т.е. для тестирования подмножества страниц рецептов выбрали один из рецептов и передаем его url всем тестам по лэйаутам). Так как проверить все страницы задачи не стоит, посему вариант выбора рандомной страницы показался оптимальным. Url рандомной страницы подмножества проверяемых страниц передается Галену методом, общим для всех тестов внутри нашей системы автоматизированного тестирования сайта (кроме тестов на тестирование верстки, у нас есть также функциональные и скриншот-тесты).
Для примера есть 2 варианта отображения одного и того же типа страниц - страниц кулинарных рецептов, в одном из которых верстка содержит ошибку:
Из примера видно, что блок “Most Read”, который должен располагаться в правом столбце страницы, на левой странице располагается в основной части, а не справа. Чтобы проверить отсутствие подобного рода проблем, нужно проверить большое число страниц и учесть множество факторов.
На каких разрешениях запускать тесты?
Сначала появилась идея выбрать наиболее распространенные девайсы и использовать для запуска тестов их разрешения. Однако, явно прослеживающаяся тенденция ускоренной мобилизации планеты не позволяет выделить (и, тем паче, предсказать) каких-то безусловных лидеров на этом поприще. Девайсов, позволяющих просматривать веб-приложения, великое множество, и унификация разрешений для таких девайсов – совершенно не модное нынче занятие. Внезапно прокравшаяся мысль о том, что адаптивный дизайн на то и адаптивный, чтобы правильно отображаться на любом валидном разрешении, спасла наши умы и пресекла дальнейшие исследования в этой области. Решение было принято: тестируем верстку на всех валидных разрешениях.
Валидными разрешениями были назначены все разрешения от min Viewport width = 241 px (меньше браузер не уменьшается) до max Viewport width = 1920px (верхняя граница - простым волевым усилием). У нас пока не было страниц, где высота вьюпорта для целей автоматизированного тестирования являлась определяющим параметром, поэтому на высоту мы пока не обращаем внимания.
Как же тестировать верстку на всех разрешениях?
Для начала весь диапазон валидных разрешений был разбит на диапазоны различающихся лэйаутов. Сами лэйауты «резиновые», но различное расположение блоков позволяет провести разграничение. Определить границы лэйаутов несложно – тянем за уголок браузера и смотрим, на какой граничной точке изменяются блоки страницы: их взаиморасположение, количество и/или поведение. Для упрощения принимаем во внимание только ширину вьюпорта. Получилась следующая таблица:
DESKTOP: max 1920px, min 1018px;
LAPTOP: max 1017px, min 769px;
TABLET: max 768px, min 481px;
MOBILE: max 480px, min 361px;
SMALL_MOBILE: max 360px, min 280px.
К слову сказать, SMALL_MOBILE layout мы пока решили не тестировать, так как количество пользователей, просматривающих Вашингтонпост на девайсах с таких разрешением, катастрофически мало (умозрительное заключение, и нет проблемы добавить при тестировании в дальнейшем). Осталось для тестирования 4 диапазона, имеющих разную верстку.
Ниже описан код для запуска Galen-теста для десктопных разрешений:
Скрытый текст
При запуске каждого теста Galen’у подается рандомное разрешение из диапазона для заданного лэйаута (getRandomResolution(DESKTOP)):
И, собственно, диапазон разрешений задается в таком виде:
Тестирование по рандомному выбору разрешения из валидного диапазона и тестируемой страницы из подмножества однотипных страниц, таким образом, превращается в вероятностный процесс. Чем чаще будем запускать - тем больше разных багов найдем. При единичном успешном прохождении теста мы может сказать лишь, что данная конкретная страницы на данном конкретном разрешении – валидна. Но уже после 500 успешных прогонов мы можем утверждать, что верстка по большей части жизнеспособна. Сразу оговоримся, что «500 успешных прогонов» – это умозрительная оценка, и тут нужно смотреть на контент и количество эквивалентных страниц.
Запуск на рандомном разрешении очень скоро оправдал себя и сразу выявил одну интересную багу, которую мы, скорее всего, пропустили бы при запуске тестов в фиксированном разрешении.
Рассмотрим, чем помогает нам такой подход на примере тестирования страницы рецепта.
Тест каркаса страницы рецепта запускается для диапазона разрешений (Viewport width) от 768px до 1017px. Возьмем для примера страницу:
www.washingtonpost.com/pb/recipes/maple-banana-frozen-yogurt/14143/
Тест на граничных точках Laptop layout’a (1017px и 768px) не выдавал ошибок.
Однако, после того как мы начали запускать тест на рандомном разрешении, примерно в половине случаев тесты падали и скриншоты показывали, что блоки из правой колонки уползают вниз под основной контент.
Правильный вид:
Осторожно! Большая картинка
Скрытый текст
Вёрстка сломана:
Осторожно! Большая картинка
Скрытый текст
Screenshot-based метод тестирования
Вдохновившись
статьёй , мы решили использовать screenshot-based метод тестирования. К слову сказать, для тестирования лэйаута изначально у нас ставка делалась именно на этот метод. Т.е. была идея сравнивать полноразмерные скриншоты страницы с заранее подготовленной моделью, заменив все потенциально изменяющиеся элементы на заглушки (в качестве заглушек берётся заранее выбранное произвольное изображение). К таким элементам у нас относились картинки, флеш-реклама и текст. Затея провалилась главным образом из-за того, что страницы содержали множество блоков, загружаемых динамически, в результате чего физические размеры снимаемых скриншотов и расположения блоков изменялись от запуска теста к запуску. Кроме того, с некоторых пор Chrome утратил возможность делать полноразмерные скриншоты, что также создало ряд проблем.
Screenshot-based тесты теперь у нас проверяют те отдельные элементы и блоки на странице, для которых важно отображение, и/или проверка которых функциональными или гален тестами сложна или невозможна.
Для примера:
Вот так выглядит MostRead блок на главной странице washingtonpost.com (слева) и модель с которой мы будем сравнивать скриншот этого блока (справа):
Код теста выглядит так:
Для хранения скриншотов используется следующая структура каталогов:: /models/HomePage/firefox/HomePage_thePostMost.png
Как отсюда видно, для разных браузеров снимается свой модельный скриншот необходимого блока.
Метод shootAndVerify() находит путь до модели по классу переданной страницы и имени браузера, в котором запущен тест.
Забегая вперед, скажем - работает довольно неплохо, и далее опишем некоторые детали процесса с оговоркой, что не все еще до конца отлажено.
Как оказалось, сделанный снимок необходимого блока может зависеть от множества факторов, таких как:
- версия операционной системы
- тема операционной системы
- браузер и его версия
- различные параметры сглаживания шрифтов и аппаратное ускорение.
Первая проблема была в том, что размеры сделанных скриншотов отличались в зависимости от настроек ОС и браузера. Чтобы сделать размеры блоков, а, следовательно, и скриншотов одинаковыми, нужно запускать браузер с постоянными размерами. Изменить размер окна браузера можно, используя соответствующий метод вебдрайвера: driver.manage().window().setSize(requiredSize). Но таким образом мы задаем размер окна, а не размер нужной нам видимой области - вьюпорта. Вертикальный скроллбар, к слову, тоже влияет на размер вьюпорта, и его толщина также зависит от темы windows, поэтому нужно это учитывать. Решением проблемы стал калибровочный метод, подгоняющий размер вьюпорта под заданные размеры. После запуска первого теста, разница между шириной размера окна и шириной вьюпорта сохраняется в специальный параметр и переиспользуется при последующих запусках.
Второй проблемой, с которой мы столкнулись, стало различное отображение шрифтов в браузерах из-за параметров сглаживания. Пытались решить проблему установкой различных настроек браузера, таких как:
layers.acceleration.disabled
gfx.font_rendering.cleartype_params.rendering_mode
gfx.direct2d.disabled
Но, к сожалению, это не помогло.
Кроме того, для сравнения скриншотов утилитой ImageMagick используется такой параметр, как fuzz, который задаёт максимально возможное расхождение скриншотов.
Пытались решить данную проблему, экспериментируя с данным параметром. Небольшой коэффициент fuzz не решал проблему, поскольку количество отличающихся пикселей было очень большим, из-за того, что текста много, а большой коэффициент приводил к тому, что отсутствие некоторых элементов в блоках не влияло на прохождение теста, и приводило к потенциально пропущенным багам.
Выходом стало дублирование всех настроек различных браузеров на все виртуальные машины, на которых запускались тесты, и дублирование самих настроек операционных систем.
Например, тест, который проверяет блок социальных кнопок, в котором одно из изображений не загрузилось.
По ссылкам в отчете доступны:
картинка-модель
скриншот тестируемого блока:
результат сравнения этих двух изображений:
CommandException говорит нам о том, что сравниваемые изображения отличаются на 251px:
Бывают также ситуации, когда размеры скриншотов не совпадают. В таком случае мы получим такой отчет:
Иногда, по неизвестным причинам, элементы внутри тестируемого блока немного смещены. Для таких случаев мы сравниваем не с одной моделью, а с группой моделей, подходящей по маске, т.е. у нас может быть несколько моделей блока thePostMost с такими именами HomePage_thePostMost.png, HomePage_thePostMost (1).png, и все модели считаем валидными. К счастью, количество таких вариантов конечное, обычно не больше 2.
Технические аспекты
Как уже было сказано выше, для написания и запуска тестов используется стек технологий: Java, Maven, TestNG, Selenium, Galen Framework. Кроме того, результаты прохождения тестов отправляются в graphite. Запуск тестов осуществляется непосредственно при помощи Jenkins CIS. Не будем подробно останавливаться, почему был выбран именно такой набор. Коротко опишем, как это всё взаимосвязано.
Selenium Grid сейчас развернут локально на четырех виртуальных машинах с Windows 7, где запущены ноды грида, и на линуксовой машине, на которой запущен хаб. На каждой из нод доступны по 3 инстанса firefox и chrome браузеров. Кроме того, на линуксовой машине также развернуты Jenkins и graphite. Гален тесты запускаются в общем запуске тестов благодаря интеграции с TestNG. Для этого был написан соответствующий класс, позволяющий использовать jav’овый Galen API. При реализации взаимодействия TestNG с галеном у нас возникли некоторые проблемы, которые были оперативно решены благодаря взаимодействию с разработчиком галена. Сам разработчик галена охотно идёт на сотрудничество и регулярно выпускает обновления для этого инструмента, которые расширяют его возможности и делают его ещё более удобным. Сам он планирует написание документации по интеграции галена с TestNG.
Функциональные, гален и screenshot based тесты разделены при помощи соответствующего параметра группы, приписанного к аннотации Test, и имеется возможность их отдельного запуска.
Наши умозаключения
Оба подхода – метод сравнения скриншотов и тестирование при помощи Galen Framework – применимы для тестирования верстки страниц. Они успешно взаимодополняют друг друга. Метод сравнения скриншотов больше применим, когда нужно протестировать отображение какого-либо отдельного элемента или блока, например панели “шаринга” в социальных сетях или основного меню в хедере. Блок может содержать множество иконок внутри себя, которые в свою очередь могут находиться внутри других иконок и элементов, или иметь относительное с ними позиционирование.
С помощью галена описывать все эти мелкие моменты достаточно трудоёмко, однако один скриншот на каждый браузер решает эту проблему, и сравнение скришотов исключает вариант, когда мы что-то можем упустить при описании спека. Гален, в свою очередь, прекрасно справляется с относительным расположением блоков и проверкой заголовков и фиксированного текста в них. Он имеет хорошее применение, когда нужно протестировать вёрстку на однотипных шаблонизированных страницах, не нагруженных функциональной логикой, например, какого-либо информационного портала, как в нашем случае, когда практически любая страница сайта доступна без авторизации, либо каких-либо других действий пользователя. Кроме того, гален хорошо решает задачи кроссбраузерного тестирования в условиях адаптивной вёрстки приложения.
От автора: у вас в руках файлы с версткой. Но как проверить ее качество? Какие инструменты существуют для тех, кто не разбирается в HTML и CSS? Какими полезными вещами стоит пользоваться самому верстальщику? Эта статья попробует ответить на эти вопросы.
Почему важно проверять качество верстки
Вопрос, который волнует как заказчиков, так и самых верстальщиков. Первые так могут убедиться в том, что исполнитель выполнил свою работу качественно. Верстальщику же полезно будет проверить верстку сайта перед тем, как посылать ее на одобрение клиента. Это позволит экономить время, иначе может возникнуть ситуация, когда правки придется вносить уже после сдачи проекта. Если вы сами создаете свой сайт, инструменты проверки тоже вам пригодятся.
Инструменты для проверки
Отладчик . Один из самых простых способов, как можно проверить верстку сайта – включить отладчик. Он запускается при нажатии в браузере F12. Этот инструмент помогает увидеть, как изменится вид страницы, если из нее убрать какие-то элементы или стили. Например, вы прописали какое-то новое CSS-свойство, потом прописали еще несколько. Решили посмотреть, как все это будет выглядеть в браузере.
Оказалось, что элементы отображаются не так, как планировалось. Из-за какого свойства произошла такая ошибка? Вручную это определять долго. В отладчике же вы можете быстро отключить любые стили и быстро обнаружить ошибки. Также в нем хорошо видно опечатки. Большинство опытных верстальщиков ищут ошибки именно с помощью отладчика, а не самостоятельно просматривая код.
Рис. 1. С отладчиком находить ошибки проще
W3C Валидатор . Сервис проверки кода на мелкие ошибки. W3C – это организация, которая занимается разработкой и официальной поддержкой веб-стандартов. Поскольку она устанавливает эти стандарты, на ее сайте есть специальный сервис, который может проверить любую страницу в сети на валидность (то есть на ошибки). Нужно сказать, что это достаточно строгий валидатор.
Часто им пользуются заказчики, пытающиеся так определить качество верстки. Даже в хорошо сверстанной страничке валидатор может найти более тридцати ошибок. Однако в этом нет ничего страшного. Сервис считает за ошибку даже то, что вы не поставили пробел перед значением html-атрибута. А теперь представьте, что в таком стиле вы написали весь код. У вас будут сотни ошибок, но на самом деле верстка будет выполнена правильно, просто вы нарушите стандарты, которые W3C установили на счет правильного написания кода.
Подробнее с этими правилами можно ознакомиться на сайте W3C. По сути, единственный сайт, который валидатор проверяет без ошибок, это сайт самой W3C. Поэтому не стоит исправлять все ошибки. И все-таки валидатор может указать на какие-то серьезные проблемы, поэтому проверка верстки сайта в нем желательна. validator.w3.org — валидатор.
IE Tester . Существует такая программа, которая позволяет протестировать сайт в старых версиях Internet Explorer. Многие заказчики сегодня все еще требуют поддержку этого браузера, чтобы сайт в нем отображался так же, как и в других. Возможно, сейчас уже есть онлайн-сервисы, в которых можно выполнить аналогичную проверку. В любом случае, вам достаточно вставить нужный код и программа покажет, как все это отображалось бы в IE 6, 7 и 8.
Обычно поддержка шестой версии уже никому не нужна, а восьмая может вести себя вполне адекватно если, конечно, в вашей верстке не присутствуют новые CSS-свойства. У старых версий IE есть интересная особенность – они читают закомментированный код. Поэтому в одном из комментариев можно подключить таблицу стилей, которая будет создана специально для старых версий этого браузера.
Остальные браузеры просто пропустят этот фрагмент. Такой способ можно использовать, если вам действительно очень сильно нужна поддержка IE.
Другие сервисы . В последнее время сервисов для проверки верстки становится все больше и больше. Нет смысла останавливаться на каком-то отдельном. Большинство этих сервисов работают неплохо, но все равно не проверяют все досконально.
Как проверить адаптивную верстку
Отдельно стоит разговор об адаптивной верстке. Наилучшим вашим инструментом в этом деле будет обычное окно браузера. Просто уменьшайте ширину окна и наблюдайте, как меняется дизайн. Если вы видите, что появляется горизонтальный скролл или какие-то элементы не влазят на страничку, значит, ваша верстка далека до идеала и ее нужно дорабатывать. Если вы хотите увидеть, как будет себя вести сайт на большом экране – уменьшите масштаб. Конечно, если у вас есть планшет и телефон, то можно загрузить вашу верстку на какой-нибудь бесплатный хостинг и зайти на сайт с этих устройств.
Рис. 2. Изменение ширины окна браузера – самый простой способ проверить адаптивность.
Кроссбраузерность
Чем еще проверить верстку сайта? Обязательно должна быть проверка на кроссбраузерность. Нужны открыть сайты в различных браузерах и посмотреть, как они там выглядят. Можно изменять масштаб и размер шрифта. Вы должны убедиться, что хотя бы у большинства пользователей все будет нормально. Если вы проверяете вручную, то можете также попросить знакомых проверить верстку в их браузерах, если их версии отличаются от ваших. Здесь можно дать еще один совет – не используйте слишком специфических свойств, которые поддерживаются только в каком-то одном браузере. А если уже используйте, придумывайте для них какую-то альтернативу в других браузерах. Для некоторых свойств все еще нужно использовать вендорные префиксы. Это связано с тем, что веб-стандарты постоянно развиваются и все браузеры не могут поддерживать всего. Но если уже делать проверку на кроссбраузерность, то делать ее как минимум для таких браузеров: Chrome, Mozilla, Opera, Safari, IE.
Есть очень хорошие зарубежные сервисы продвинутой кроссбраузерной проверки. Например, browserstack.com. Такая проверка может стоить вам денег. Если у вас действительно очень крупный проект и вы хотите досконально проверить его, в таком случае есть смысл пользоваться подобными сервисами.
Проверка на соответствие с макетом
Проверить верстку можно еще так: скриншот сверстанного сайта необходимо добавить к макету в фотошопе в качестве нового слоя. Установить этому слою прозрачность и посмотреть, насколько отображение элементов совпадает с макетом. Для этого можно использовать специальный плагин. Например, Pixel Perfect для Mozilla.
Дополнительные требования
Естественно, в любой нормальной верстке должна быть прописана кодировка и doctype. Также страничку можно проверить на работоспособность при выключенных картинках или при блокировании javascript-кода. Дело в том, что в настройках любого браузера пользователь может отключить эти параметры. Особенно полезно будет прописать атрибуты alt для картинок, чтобы при их исчезновении пользователь хоть как-то мог ориентироваться. На самом деле требований к верстке может быть очень много. Даже в рунете есть достаточно строгий перечень необходимых проверок. Например, с появлением HTML5 верстку можно проверять на правильную семантическую разметку. Однако все это не является критичным. Вышеописанных проверок вполне хватит, чтобы смело запустить нормальный работоспособный сайт.
В этой статье мы описали основные способы проверки верстки с помощью различных программ, сервисов и инструментов. Это поможет вам адаптировать сайт под любые условия.