Практическое обеспечение уровней пользовательского восприятия. В настоящее время самую действенную помощь в улучшении и разветвлении уровней пользовательского восприятия на основе возможностей устройств оказывает средство 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) http://adactio.com/journal/5429/.
Полный код можно найти в файле каталога 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 (http://getbootstrap.com/) и Foundation (http://foundation.zurb.com/). Несмотря на то что это весьма интересные проекты, в особенности для обучения созданию адаптивных визуальных шаблонов, я полагаю, что в конечном продукте их использования нужно избегать.
Я обсуждал эту тему со многими разработчиками, начинавшими проекты с использованием одной из таких сред, а затем вносившими в код изменения, отвечающие насущным потребностям. Этот подход может принести большую выгоду в плане быстрого создания прототипов (например, для демонстрации клиентам ряда приемов взаимодействия с продуктом), но я полагаю, что в проектах, которые предназначены для производственной деятельности, их использование неприемлемо.
Во-первых, с технической точки зрения вполне возможно, что, положившись с самого начала на одну из таких сред, вы получите в результате проект, объем кода которого будет значительно превышать реальные потребности самого проекта. Во-вторых, с точки зрения эстетики из-за высокой популярности таких сред вполне возможно, что ваш проект в итоге будет очень похож на бесчисленное множество других подобных проектов.
И наконец, если просто переносить код в свой проект и подстраивать его под свои нужды, вы вряд ли будете в полной мере понимать, что делается «под капотом». Осмыслить код, помещаемый в свой проект, можно, только очертив круг проблем и добившись их решения.
Выработка наиболее практичных решений
Когда дело доходит до разработки веб-интерфейса, меня особенно настораживает оторванный от жизни идеализм. Хотя нужно неизменно стремиться делать все как полагается, побеждать все-таки должен именно практицизм. Хочу привести пример, окончательный код которого находится в файле каталога example_10-02. Предположим, что имеется кнопка, требующая стилевого оформления и открывающая меню, которое выходит за пределы общего холста. Естественным желанием может стать использование примерно такой разметки:
<button class="menu-toggle js-activate-off-canvas-menu">
<span aria-label="site navigation">☰</span> menu
</button>
Простенько и со вкусом. Мы имеем дело с кнопкой, поэтому и воспользовались элементом button. В отношении данной кнопки мы применили два HTML-класса, один из которых станет привязкой для придания ей стиля с помощью CSS (menu-toggle), а второй — привязкой к коду JavaScript (js-activate-off-canvas-menu). Кроме того, мы воспользовались атрибутом aria-label (более подробно стандарт ARIA рассмотрен в главе 4), чтобы довести до модуля чтения с экрана значение символа, находящегося внутри span-контейнера. В данном примере используется HTML-код ☰, представляющий собой символ Юникода под названием «триграмма для небес». Он применяется здесь по той простой причине, что похож на значок гамбургера, часто используемый как символ меню.
совет
Если вам нужен полезный совет по поводу места и способа использования атрибута aria-label, я настоятельно рекомендую следующую статью на сайте разработчиков Opera, написанную Хейдоном Пикерингом (Heydon Pickering): https://dev.opera.com/articles/ux-accessibility-aria-label/.
Похоже, пока дела идут как нельзя лучше. Осмысленность, весьма доступная разметка и классы для разделения сфер интересов. Великолепно. Добавим стилевое оформление:
.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;
