Фрэйн . - HTML5 и CSS3. Разработка сайтов для любых браузеров и устройств. 2-е изд.

• Название: HTML5 и CSS3. Разработка сайтов для любых браузеров и устройств. 2-е изд.
• Автор: Фрэйн .
• Издательство: Издательский дом "Питер"
• Жанр: Прочая старинная литература
• Год: 2016
• ISBN: 978-5-496-02271-2

---

.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. К нашему общему удовольствию, теперь оно вернулось в стандарты: http://dev.w3.org/csswg/css-ui-4/#appearance-switching.

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

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

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

    <span aria-label="site navigation">☰</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, который можно найти по адресу https://www.uda­city.com/course/browser-rendering-optimization--ud860.