10. Подходы к адаптивному веб-дизайну

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

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

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

• обкатка дизайна в браузере и на реальных устройствах на самых ранних стадиях;

• задание контрольных точек применительно к дизайну;

• использование принципа постепенного усложнения;

• определение матрицы браузерной поддержки;

• применение на практике принципа постепенного усложнения;

• привязка контрольных точек CSS к JavaScript;

• отказ от использования сред разработки CSS при создании конечного продукта;

• выработка наиболее практичных решений;

• написание как можно более простого кода;

• скрытие, показ и загрузка содержимого для всевозможных окон просмотра;

• возложение самых трудных задач визуального оформления на CSS;

• использование средств контроля качества кода;

• анализ и тестирование производительности веб-страниц (webpagetest.org);

• применение более скоростных и эффективных технологий;

• отслеживание появления очередных грандиозных нововведений.

Обкатка дизайна в браузере на самых ранних стадиях

Чем больше адаптивных проектов я разрабатывал, тем более важной мне представлялась обкатка дизайна в среде браузера на самых ранних стадиях. Если вы и дизайнер и разработчик в одном лице, то дело упрощается. Как только сложится более или менее конкретное визуальное представление о насущных потребностях, следует обкатать прототип в браузере и далее прорабатывать идею в среде браузера. Этот подход можно расширить за счет прогона сразу всех высококачественных полностраничных прототипов. Или же присмотреться к использованию таких средств, как Style Tiles, занимающих место между подборкой изображений и полноценным макетом. Во введении в Style Tiles (/) это средство описывается следующим образом:

«Style Tiles является дизайнерской подборкой, состоящей из шрифтов, цветовых решений и элементов интерфейса с целью передать суть визуального фирменного стиля для веб-технологий».

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

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

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

.rule {

    /* Стили для самых скромных окон просмотра */

}

 

@media (min-width: 40em) {

    .rule {

        /* Изменения для окон просмотра среднего размера */

    }

}

 

@media (min-width: 70em) {

    .rule {

        /* Изменения для более крупных окон просмотра */

    }

}

Просмотр и обкатка дизайна на реальных устройствах

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

используйте Для синхронизации работы такие средства, как BrowserSync

Одним из наиболее эффективных средств экономии времени, которым я пользуюсь в последнее время, является BrowserSync. После его настройки при сохранении работы любые изменения, вносимые, к примеру, в CSS, внедряются в браузер, не требуя при этом постоянного обновления экрана. Если это вас не сильно впечатлило, добавлю: обновляются и любые другие окна браузеров на устройствах, находящихся в той же Wi-Fi-сети. При этом при внесении каждого изменения уже не приходится брать каждое тестируемое устройство и щелкать на кнопке обновления. Данное средство синхронизирует также прокрутку и щелчки на элементах интерфейса. Настоятельно рекомендую: /.

Использование принципа постепенного усложнения

В предыдущих главах был вкратце упомянут принцип постепенного усложнения. Полагаю, об этом подходе к разработке, в котором я вижу немалую практическую пользу, нелишне будет напомнить еще раз. Основной замысел постепенного усложнения заключается в том, что весь ваш интерфейсный код (HTML, CSS, JavaScript) начинается с замысла наименьшего общего знаменателя. Затем код постепенно усложняется с расчетом на устройства и браузеры с более широкими возможностями. Если вы привыкли работать в обратном порядке, то все может показаться неким упрощением, и так оно и есть: если вы имеете оптимальные наработки, а затем на­шли способ добиться работоспособности в устройствах и браузерах с самыми скромными возможностями, то поймете, что постепенное усложнение является наиболее простым подходом.

Представьте себе маломощное устройство с весьма ограниченными возможностями: отсутствует JavaScript, не поддерживается Flexbox, нет поддержки CSS3 и CSS4. Что в подобных обстоятельствах можно сделать, чтобы обеспечить пользователю удобство восприятия содержимого?

Важнее всего создать на HTML5 выразительную разметку с точным описанием всего этого содержимого. Если создаются чисто текстовые или иные сайты, основанные на содержимом, то эта задача считается наиболее простой. В таком случае следует сконцентрироваться на правильном использовании элементов main, header, footer, article, section и aside. Это не только поможет отделить друг от друга различные разделы кода, но и обеспечит вашим пользователям повышенную доступность информации без каких-либо дополнительных затрат с вашей стороны.

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

примечание

Для дальнейшего изучения данной темы и получения полезных практических примеров я рекомендую следующие статьи: / и /. Они могут дать глубокое понимание того, как довольно сложные взаимодействия могут быть обработаны конструкциями, созданными на основе HTML и CSS.

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

А теперь поговорим о браузерах.

Определение матрицы браузерной поддержки

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

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

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

Функциональное, но не эстетическое единообразие

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

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

Выбор поддерживаемых браузеров

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

Если дело касается существующего сайта, посмотрите на статистику его посещений в Google Analytics или подобных системах. Получив представление, можно будет сделать ряд прикидок. Например, если стоимость поддержки браузера X ниже расчетных затрат на его поддержку, то нужно поддерживать браузер X!

Кроме того, если, по статистике, теми или иными браузерами пользуются менее 10 % пользователей, следует просмотреть статистику за предыдущие периоды и выявить тенденцию. Как объем использования менялся за последние 3, 6 и 12 месяцев? Если он составляет 6 % и его значение за последние 12 месяцев уменьшилось в два раза, то это более чем убедительный довод для принятия решения по исключению этого браузера из числа тех, к которым должны применяться конкретные усовершенствования.

Если дело касается нового проекта, статистика для которого еще не наработана, то я обычно придерживаюсь политики «двух предыдущих». Это текущая версия плюс две предыдущие версии каждого браузера. Например, если текущей является версия Internet Explorer 12, рассматривайте применение усовершенствований для этой версии, а также для IE10 и IE11 — двух ее предшественников. Проще, конечно, выбирать из самых популярных браузеров, подвергаемых постоянным обновлениям и имеющим короткий цикл выпуска следующей версии (к примеру, Firefox и Chrome).

Создание нескольких уровней пользовательского восприятия

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

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

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

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

Привязка контрольных точек CSS к JavaScript

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

Предположим, что нам нужно вызвать конкретную функцию JavaScript при достижении конкретной контрольной точки в CSS (хочу напомнить, что понятие контрольной точки используется для определения точки, в которой адаптивный дизайн должен претерпеть существенные изменения). Предположим, что контрольной точкой считается 47,5 rem (при основном размере шрифта 16 пикселов это будет эквивалентно 760 пикселам) и нам нужно при этом размере всего лишь запустить функцию. Очевидным решением будут простой замер ширины экрана и вызов функции, если значение совпадает с тем значением, которое решено было принять за вашу контрольную точку CSS.

JavaScript всегда будет возвращать значение ширины в пикселах, а не в rem, что является первым осложнением. Но даже если контрольные точки в CSS заданы в пикселах, это все равно будет означать, что у нас имеются два места, в которые нужно вносить обновления и изменения этих значений при изменении размеров окна просмотра.

К счастью, есть более подходящий способ. Впервые я ознакомился с этой технологией на сайте Джереми Кейта (Jeremy Keith) /.

Полный код можно найти в файле каталога example_10-01. Но основной замысел состоит в том, что в CSS вставляется нечто такое, что может быть легко считано и правильно воспринято кодом JavaScript.

Рассмотрим этот прием в CSS:

@media (min-width: 20rem) {

    body::after {

        content: "Splus";

        font-size: 0;

    }

}

@media (min-width: 47.5rem) {

    body::after {

        content: "Mplus";

        font-size: 0;

    }

}

@media (min-width: 62.5rem) {

    body::after {

        content: "Lplus";

        font-size: 0;

    }

}

В каждой контрольной точке, которую мы хотим связать с JavaScript, используется псевдоэлемент after (можно использовать и before, так как подойдет любой из них) и указывается содержимое этого псевдоэлемента, чтобы дать имя нашей контрольной точке. В предыдущем примере я использовал Splus для экранов не меньше меньших, Mplus — для экранов не меньше средних и Lplus — для экранов не меньше больших. Здесь можно использовать любые значимые для вас имена и изменять значения там, где в этом усматривается смысл (использовать другие показатели ориентации, высоты, ширины и т. д.).

совет

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

При использовании этих настроек CSS мы можем просмотреть DOM-дерево и увидеть псевдоэлемент ::after.

 

Затем в нашем коде JavaScript это значение можно будет прочитать. Сначала мы присвоим значение переменной:

var size = window.getComputedStyle(document.body,':after').

getPropertyValue('content');

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

;(function alertSize() {

    if (size.indexOf("Splus") !=-1) {

        alert('I will run functions for small screens');

    }

    if (size.indexOf("Mplus") !=-1) {

        alert('At medium sizes, a different function could run');

    }

    if (size.indexOf("Lplus") !=-1) {

        alert('Large screen here, different functions if needed');

    }

})();

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

Отказ от использования сред разработки CSS при создании конечного продукта

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

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

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

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

Выработка наиболее практичных решений

Когда дело доходит до разработки веб-интерфейса, меня особенно настораживает оторванный от жизни идеализм. Хотя нужно неизменно стремиться делать все как полагается, побеждать все-таки должен именно практицизм. Хочу привести пример, окончательный код которого находится в файле каталога example_10-02. Предположим, что имеется кнопка, требующая стилевого оформления и открывающая меню, которое выходит за пределы общего холста. Естественным желанием может стать использование примерно такой разметки:

<button class="menu-toggle js-activate-off-canvas-menu">

    <span aria-label="site navigation">&#9776;</span> menu

</button>

Простенько и со вкусом. Мы имеем дело с кнопкой, поэтому и воспользовались элементом button. В отношении данной кнопки мы применили два HTML-класса, один из которых станет привязкой для придания ей стиля с помощью CSS (menu-toggle), а второй — привязкой к коду JavaScript (js-activate-off-canvas-menu). Кроме того, мы воспользовались атрибутом aria-label (более подробно стандарт ARIA рассмотрен в главе 4), чтобы довести до модуля чтения с экрана значение символа, находящегося внутри span-контейнера. В данном примере используется HTML-код &#9776;, представляющий собой символ Юникода под названием «триграмма для небес». Он применяется здесь по той простой причине, что похож на значок гамбургера, часто используемый как символ меню.

совет

Если вам нужен полезный совет по поводу места и способа использования атрибута aria-label, я настоятельно рекомендую следующую статью на сайте разработчиков Opera, написанную Хейдоном Пикерингом (Heydon Pickering): /.

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

.menu-toggle {

    appearance: none;

    display: inline-flex;

    padding: 0 10px;

    font-size: 17px;

    align-items: center;

    justify-content: center;

    border-radius: 8px;

    border: 1px solid #ebebeb;

    min-height: 44px;

    text-decoration: none;

    color: #777;

}

[aria-label="site navigation"] {

    margin-right: 1ch;

    font-size: 24px;

}

Откроем это в Firefox и увидим там следующее.

 

Получилось не совсем то, на что мы надеялись. В данном случае браузер решил, что мы зашли слишком далеко: Firefox просто не разрешил нам использовать элемент button в качестве Flex-контейнера. Для разработчика это вполне реальная конфликтная ситуация. И что мы сделали неправильно: выбрали не тот элемент или не то эстетическое оформление? В идеале нам хотелось получить меню в виде значка гамбургера слева и слова menu справа.

совет

В предыдущем коде можно заметить применение свойства appearance. Оно используется для удаления исходного стилевого оформления, задаваемого браузерами для элементов формы, и имеет весьма давнюю историю. Одно время оно входило в спецификацию W3C, затем было оттуда убрано, оставаясь в версиях с использованием префиксов производителей в браузерах на основе Mozilla и WebKit. К нашему общему удовольствию, теперь оно вернулось в стандарты: .

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

Рассмотрим разметку, с которой я начну работать. Обратите внимание на добавление тегу ARIA-роли, указывающей, что он для вспомогательной технологии расширения сферы доступности сайта играет роль кнопки, а не ссылки, как было бы по умолчанию:

<a class="menu-toggle js-activate-off-canvas-menu" role="button">

    <span aria-label="site navigation">&#9776;</span> menu

</a>

Пусть это и не самое лучшее, но зато вполне выверенное с практической точки зрения решение. Вот как выглядят эти два элемента (элемент button слева и тег a справа) в Firefox (версии 39.0a2, кому интересно) рядом друг с другом.

 

Разумеется, для данного упрощенного примера мы можем изменить отображение, перейдя от технологии flex к блочной технологии, и, экспериментируя с отступами, добиться эстетически приемлемой картины. Или же можем сохранить элемент button и вложить в него другой семантически незначимый элемент (span), из которого сделать Flex-контейнер. Но, какому бы подходу ни было отдано предпочтение, у каждого из них есть свои достоинства и недостатки.

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

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

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

.list-item:nth-child(5) {

    /* Стили */

}

При наличии доступа к разметке сделайте все проще, добавив к элементу HTML-класс:

<li class="list-item specific-class">Item</li>

После чего придайте ему стиль с помощью этого простого класса:

.specific-class {

    /* Стили */

}

Такой код не только будет проще восприниматься, но и позволит без каких-либо усилий с вашей стороны получить более широкую поддержку, поскольку устаревшие версии Internet Explorer не поддерживают селекторы nth-child.

Скрытие, показ и загрузка содержимого для всевозможных окон просмотра

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

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

Кроме того, это означает, что при увеличении полезной площади экрана мы не должны считать себя вынужденными добавлять что-либо просто для заполнения пространства (к примеру, виджеты, рекламные объявления или ссылки). Если пользователь может обходиться без этих дополнений на экранах меньших размеров, он прекрасно обойдется без них и на более крупных экранах. Отображение дополнительного содержимого в более крупных окнах просмотра также означает, что содержимое либо имелось в окнах просмотра меньших размеров и просто находилось в скрытом состоянии (обычно с использованием display: none; в CSS), либо было загружено при конкретном размере окна просмотра с помощью JavaScript. Короче говоря, либо содержимое было загружено, но оставалось невидимым, либо его видимость считалась излишней.

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

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

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

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

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

совет

Чтобы добиться наивысшей производительности, при переключении классов в HTML добавляйте класс как можно ближе к тому элементу, к которому нужно применить эффект. Например, если нужно, чтобы блок появлялся поверх другого элемента, добавьте класс к самому ближнему общему родительскому элементу. Тогда ради достижения оптимальной производительности можно будет обеспечить внесение изменений только в данный конкретный раздел страницы и не заставлять браузер снова прорисовывать ее более крупные части. У Пола Льюиса (Paul Lewis) есть отличный бесплатный курс по повышению производительности под названием Browser Rendering Optimization, который можно найти по адресу .

Средства контроля качества кода

В общем-то, при написании кода HTML и CSS прощаются многие огрехи. Можно просчитаться с количеством вложенных элементов, забыть поставить кавычки или слеш в самозакрывающемся теге и при этом даже не всегда заметить какие-либо проблемы. Несмотря на это, мне чуть ли не еженедельно приходится сталкиваться с собственными просчетами в разметке. Иногда это ляпы вроде опечаток. А иногда школярские ошибки типа вложения div в span (разметка, при которой элемент блочного уровня div попадает в линейный элемент span, приводит к непредсказуемым результатам). К счастью, нам в помощь разработаны специальные инструментальные средства. В худшем случае, если возникли проблемы, обратитесь по адресу / и вставьте на этот сайт свою разметку. В результате будут помечены все ошибки и получены номера их строк, что существенно облегчит их устранение.

 

А еще лучше установить и настроить средства контроля качества вашего кода HTML, CSS и JavaScript. Или же выбрать текстовый редактор с определенным уровнем встроенной проверки правильности кода. Тогда по мере набора будут сразу же обозначаться проблемные области кода. Посмотрите на пример простой ошибки в написании кода CSS, которая сразу же была замечена редактором кода от компании Microsoft.

 

Я специально набрал widtth вместо width. Редактор это заметил и указал на ошибку, предлагая при этом ряд вполне разумных альтернатив. По возможности нужно пользоваться именно такими инструментальными средствами. Лучше потратить время на их подбор, чем на выискивание простых синтаксических ошибок в своем коде.

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

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

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

1. Сведение к минимуму количества ресурсов (например, не загружайте 15 файлов JavaScript, если объединяете их в одно целое).

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

3. Отсрочка загрузки второстепенных ресурсов (если можно отложить загрузку CSS и JavaScript до вывода страницы на экран, это может существенно улучшить восприятие скорости загрузки страницы).

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

Имеются также весьма эффективные средства для определения уровня производительности и ее оптимизации. Лично я предпочитаю пользоваться сайтом /.

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

На следующей странице показано, как выглядит раскадровка загрузки главной страницы сайта BBC.

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

 

В преддверии великих перемен

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

Например, за три года до выхода данного издания книги адаптивных изображений (получаемых с помощью атрибута srcset и элемента picture, подробно рассмотренных в главе 3) не было и в помине. Тогда, чтобы получить более подходящие для окон просмотра различных размеров изображения, нам приходилось пользоваться хитроумными обходными средствами от сторонних разработчиков. Теперь же, когда эти насущные потребности нашли свое отражение в стандартах W3C, мы можем с удовольствием пользоваться стандартными средствами.

Аналогично этому не так давно Flexbox еще только мерещился тем, кто создавал спецификацию. И даже по мере развития спецификации ее реализация давалась с большим трудом до тех пор, пока Андрей Ситник (Andrey Sitnik) и такие же умные, как он, ребята из Evil Martians (/) не создали Autoprefixer, после чего мы смогли с относительной простотой воспользоваться кросс-браузерным кодом.

В будущем нам предстоит осваивать еще более захватывающие возможности. К примеру, в главе 4 уже упоминалось средство Service Workers (/), предоставляющее один из лучших способов создания приложения на основе веб-технологий, способных работать в автономном режиме.

Есть также Web Components — коллекция стандартов, составленная из Shadow DOM (/), Custom Elements (/) и HTML Imports (/), которая позволяет создавать полностью предсказуемые и многократно используемые компоненты.

На подходе и другие более совершенные средства вроде CSS Level 4 Selectors (/) и CSS Level 4 Media Queries, частично рассмотренные в главе 2.

И наконец, на горизонте забрезжили еще более грандиозные перемены, связанные с появлением протокола HTTP2. Он обещает все, что сейчас считается передовыми наработками, просто выбросить на свалку. Чтобы получить о нем более глубокое представление, предлагаю прочитать заметки Дэниела Стенберга (Daniel Stenberg) о том, что такое HTTP2, свободно распространяемые в PDF-формате. Или же в качестве краткого обзора прочтите великолепную статью Мэтта Уилко­кса (Matt Wilcox) HTTP2 for front-end web developers ().

Резюме

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

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

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

А пока желаю вам удачи на вашем нелегком, но увлекательном пути разработки адаптивного веб-дизайна.

До новых встреч.