Текущее состояние адаптивного вебдизайна

Текущее состояние адаптивного вебдизайна

От автора: Адаптивный вебдизайн используется уже насколько лет, а в 2012г. он был горячо обсуждаемой темой. У многих хорошо известных дизайнеров, таких как Брэд Фрост (Brad Frost) и Люк Вроблевски (Luke Wroblewski), имеется большой опыт работы с ним и они помогли нам сильно продвинуться в этой области. Но сделать нужно еще очень многое.

В этой статье мы рассмотрим, что возможно сделать сейчас, что станет возможным в будущем при помощи еще не стандартизированных свойств (таких как CSS Уровня 4 и HTML5 APIS), и что еще нуждается в улучшении. Это – неутомительная статья, и мы не станем глубоко вдаваться в каждую технику, но у вас будет достаточно ссылок и источников знаний для дальнейшего самостоятельного исследования вопроса.

Состояние изображений в адаптивном вебдизайне

С какого аспекта адаптивного вебдизайна лучше всего начать работу с изображениями? В течение некоторого времени это уже основная тема дискуссий. Еще более важной она становится по мере появления высокоплотных экранов. Под высокой плотностью я имею в виду экраны с пиксельным соотношением более 2; Apple называет их устройствами Retina, а Google – XHDPI. В адаптивном вебдизайне изображения идут с двумя большими связанными между собой проблемами: размером и производительностью.

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

Вторая проблема касается маленьких устройств: зачем мобильному устройству закачивать 750-пиксельное изображение, когда ему достаточно 300-пиксельного? И есть ли у нас способ обрезки изображений таким образом, чтобы пользователи маленьких устройств смогли увидеть на них самое важное?

РЕШЕНИЯ ИЗ ДВУХ РАЗМЕТОК: ЭЛЕМЕНТ PICTURE И АТРИБУТ SRCSET

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

<picture width="500"  height="500">     
  <source  media="(min-width: 45em)" src="large.jpg">
  <source  media="(min-width: 18em)" src="med.jpg">
  <source  src="small.jpg">
  <img  src="small.jpg" alt="">
  <p>Accessible  text</p>
</picture>

Если бы было возможно обеспечить разные источники, то вообразите себе разные обрезки изображения для того, чтобы фокус выделял для маленьких устройств только важное. На примере использования «Art Direction» от W3C показано, что можно было бы сделать.

Данное решение сейчас обсуждается сообществом адаптивных изображений W3C, но, насколько нам известно, оно пока неприменимо ни в одном браузере. Есть полифил под названием Picturefill, который делает во многом то же самое. В целях безопасности в нем применяются div и синтаксис data-attribute.

Второе предложение касательно разметки адаптивных изображений было сделано W3C Apple и называется «Атрибут srcset»; его эквивалент в CSS Уровня 4 – это image-set(). Назначение этого атрибута в том, чтобы заставить агент пользователя выбрать из набора подходящий ресурс, а не доставить весь набор полностью. Синтаксис HTML этого предложения основан на самом тэге img, а пример в спецификации выглядит так:

<img  alt="The Breakfast Combo" 
  src="banner.jpeg"
  srcset="banner-HD.jpeg  2x, banner-phone.jpeg 100w, banner-phone-HD.jpeg 100w 2x">

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

Изображение по умолчанию – это banner.jpeg.

Устройства с пиксельным соотношением более 2 должны применять banner-HD.jpeg.

Устройства с максимальным окном просмотра в 100w должны применять banner-phone.jpeg.

Устройства с максимальным окном просмотра в 100w и пиксельным соотношением более 2 должны применять banner-phone-HD.jpeg.

Первый источник — это изображение по умолчанию, если атрибут srcset не поддерживается. Суффикс 2x для banner-HD.jpeg означает, что это конкретное изображение должно применяться для устройств с пиксельным соотношением более 2. 100w для banner-phone.jpeg представляет минимальный размер окна просмотра, для которого должно использоваться это изображение. Из-за своей технической сложности этот синтаксис все еще не применяется ни в одном браузере. Синтаксис свойства CSS image-set() работает во многом так же и дает вам возможность на основе разрешения экрана загрузить отдельное фоновое изображение:

background-image: image-set(  "foo.png" 1x,
  "foo-2x.png"  2x,
  "foo-print.png"  600dpi );

Это предложение все еще является редакторским проектом W3C. Сейчас оно работает в Safari 6+ и Chrome 21+.

ФОРМАТ ИЗОБРАЖЕНИЯ, СЖАТИЕ, SVG: ИЗМЕНЕНИЕ МЕТОДОВ РАБОТЫ С ИЗОБРАЖЕНИЯМИ В СЕТИ

Как вы сами видите, попытки найти новый формат разметки изображений все еще весьма экспериментальны. Это поднимает вопрос самих форматов изображений. Можем ли мы разработать адаптивное решение путем изменения способа управления самими изображениями?

Первым шагом станет поиск альтернативных форматов изображения, имеющих лучшую степень сжатия. Google, например, разработал новый формат изображения с названием WebP, который на 26% меньше PNG и от 25 до 34% меньше JPEG. Формат поддерживается в Google Chrome, Opera, Yandex, Android и Safari и может быть активирован в Internet Explorer с помощью плагина Google Chrome Frame. Основная проблема этого формата в том, что Firefox его вводить не планирует. Зная об этом, его широкое применение пока не очень вероятно.

Другая набирающая популярность идея состоит в прогрессивных изображениях JPEG. Такие изображения, как предполагает их название, прогрессивно визуализируются. Первое изображение расплывчато, а затем по мере визуализации прогрессивно становится четче. Непрогрессивные изображения JPEG визуализируются сверху вниз. В своей статье «Прогрессивные JPEG’и: новая лучшая практика» (Progressive JPEGs: A New Best Practice) Энн Робсон (Ann Robson) аргументирует то, что прогрессивные JPEG’и дают ощущение более высокой скорости в сравнении с обычными базовыми JPEG’ами. Прогрессивный JPEG дает пользователю краткое общее впечатление об изображении до его полной загрузки. Это, однако, не решает технических проблем производительности и размера изображений, но улучшает впечатление пользователя.

Другое решение проблем производительности и размера состоит в изменении уровня сжатия изображений. Долгое время мы считали, что увеличение уровня сжатия повредит общему качеству изображения. Но Даан Джобсис (Daan Jobsis) провел интенсивное исследование этого предмета и написал об этом статью – «Революция Retina» (Retina Revolution). В своих экспериментах он испытывал разные размеры изображений и уровни сжатия и пришел к весьма интересному решению. Если поддерживать размеры изображения в два раза больше, чем отображаемые, но при этом применять больший уровень сжатия, то размер файла изображения будет меньше оригинального, но оно останется четким как на нормальном экране, так и высокоплотном. Пользуясь этой методикой, Джобсис уменьшил вес изображения до 75%.

Демонстрация сжатия изображения Дааном Джобсисом.

Из-за головной боли с адаптивными изображениями идея получения пиксельной независимости от изображений там, где это только возможно, соблазняет все большее и большее количество дизайнеров и разработчиков. Формат SVG, например, можно использовать для создания всех элементов UI вебсайта, и он будет независим от разрешения. Элементы станут отлично масштабироваться для маленьких устройств и не будут пикселизованными на высокоплотных устройствах. Иконки-шрифты – еще один становящийся популярным тренд. Они вовлекают присвоение некоторым символам шрифта глиф-иконок (как в области частного использования Unicode), предоставляя вам гибкость шрифтов. К сожалению, это решение не работает с изображениями, поэтому с нетерпением ожидаем появления жизнеспособной разметки или формата.

Проблема адаптивной разметки: реорганизуйте и работайте с контентом, не затрагивая HTML?

Дайте взглянем в лицо фактам – применяемые нами сегодня подвижные сетки, созданные из плавающих и встроенных блоков – это плохая «заплатка», нуждающаяся в лучшем решении. Сегодня работа с разметкой и полная реорганизация блоков на странице для мобильных устройств без обращения к JavaScript’у – просто кошмар. К тому же это весьма негибкое решение. Особенно это имеет значение для вебсайтов, созданных с помощью CMS; дизайнер не может менять HTML каждой страницы и каждой версии вебсайта. Так как же можно это улучшить?

ЧЕТЫРЕ РЕШЕНИЯ CSS3 ДЛЯ ПРОБЛЕМЫ ГИБКОСТИ РАЗМЕТКИ

Самое очевидное возможное решение – это модель разметки гибкого блока CSS3 (или flexbox). Она находится сейчас в статусе рекомендуемого возможного решения и поддерживается в самых основных мобильных и настольных браузерах (в IE – начиная с версии 10). Модель дает вам возможность легко реорганизовывать элементы на экране независимо от HTML. Также можно менять ориентацию блока и его перемещение, распределять пространство и выравнивать элементы в соответствии с содержимым. Ниже приведен пример разметки, которую можно реорганизовать для мобильных устройств. Синтаксис будет выглядеть так:

.parent {
  display: flex;
  flex-flow: column; /* отобразите пункты в колонках */
}

.children {
  order: 1; /* измените порядок элементов */
}

Из статьи «Объяснение разметки гибких блоков CSS3» (CSS3 Flexible Box Layout Explained) вы получите более глубокое понимание работы flexbox. Другое довольно близкое к концепции flexbox решение по реорганизации блоков на странице, но при помощи JavaScript, это Relocate.

Второй вид разметки, вполне подходящей сегодня для адаптивного дизайна – это многоколонная разметка CSS3. Модуль находится на этапе рекомендуемого возможного решения, и довольно хорошо работает в большинстве браузеров, кроме IE 9 и ниже. Основное преимущество этой модели в том, что содержимое может «перетекать» из одной колонки в другую, обеспечивая огромный выигрыш в гибкости. Говоря языком адаптивности, количество колонок можно менять в соответствии с размером окна просмотра.

Можно установить размер колонок и позволить браузеру посчитать их количество в соответствии с имеющимся в наличии местом. Также можно установить количество колонок с промежутками и правилами между ними и дать браузеру возможность посчитать ширину каждой колонки.

Синтаксис будет такой:

.container {
  column-width: 10em ; /* Браузер создаст колонки в 10em. Количество колонок будет зависеть от имеющегося места. */
}

.container {
  columns: 5; /* Браузер создаст 5 колонок. Размер колонки будет зависеть от имеющегося места. */
  column-gap: 2em;
}

Чтобы узнать об этом больше, прочтите статью Дэвида Уолша (David Walsh) «Колонки CSS» (CSS Columns). Третье свойство CSS3, которое в будущем может завоевать внимание к себе – это сеточная разметка CSS3. Она дарит дизайнерам и разработчикам гибкую сетку, с которой можно работать над созданием разных разметок. При этом элементы содержимого отображаются в колонках и рядах без определенной структуры. Сначала вы заявите сетку к контейнеру, а затем разместите в этой виртуальной сетке все дочерние элементы. Затем можно определить разные сетки маленьким устройствам или изменить в ней расположение элементов. При работе с медиазапросами, изменении ориентации и пр. это позволяет получить огромную гибкость. Синтаксис выглядит как здесь (из рабочего черновика от 2 апреля 2013г.):

.parent {
   display: grid; /* заявите сетку */
   grid-definition-columns: 1stgridsize  2ndgridsize …;
   grid-definition-rows: 1strowsize  2ndrowsize …;
}

.element {
   grid-column: 1; 
   grid-row: 1
}

.element2 {
   grid-column: 1; 
   grid-row: 3;
}

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

Главная проблема этого свойства в том, что в данный момент оно поддерживается только в IE 10. Чтобы больше узнать об этой разметке, прочтите статью Рэйчел Эндрю (Rachel Andrew) «Назначение приоритета контенту с помощью сеточной разметки CSS3» (Giving Content Priority With CSS3 Grid Layout). Кроме того, обратите внимание, что спецификация и синтаксис сеточных разметок изменились со 2 апреля 2013г. Рэйчел написала обновление синтаксиса под названием «Сеточная разметка CSS: Что изменилось?» (CSS Grid Layout: What Has Changed?).

Последняя разметка, которая могла бы пригодиться в будущем, будучи примененной в браузерах, это шаблонная разметка CSS3. Этот модуль CSS3 работает, привязывая элемент к «имени» разметки, а затем упорядочивая элементы по невидимой сетке. Эта сетка может быть фиксированной или гибкой, и может меняться в зависимости от размера окна просмотра. Синтаксис такой:

.parent {
   display: "ab"
            "cd" /* создание невидимой сетки */
}

.child1 {
   position: a;
}

.child2 {
   position: b;
}

.child3 {
   position: c;
}

.child4 {
   position: d;
}

Это визуализируется следующим образом:

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

ЕДИНИЦЫ ОКНА ПРОСМОТРА И КОНЕЦ РАЗМЕТКИ НА ОСНОВЕ ПИКСЕЛЕЙ

Длина в процентах на основе окна просмотра — vw, vh, vm, vmin и vmax — это единицы, измеряемые относительно размеров самого окна просмотра. Единица vw эквивалентна 1% ширины исходного содержащего блока. Если ширина окна просмотра равна 320, то 1 vw – это 1 × 320/100 = 3,2 px.

Единица vh работает таким же образом, но относительна высоте окна просмотра. Так что 50 vh будет равняться 50% высоты документа. Тут вы можете спросить, в чем разница с единицей измерения в процентах. Тогда как процентные единицы относительны размеру родительского элемента, единицы vh и vw будут всегда относительны размеру окна просмотра, вне зависимости от размера своих родительских элементов.

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

Единица vmin равняется самому маленькому vm или vh, а vmax равна самому большому vm или vh; вот почему эти единицы также идеально отвечают на изменение ориентации устройства. К сожалению, сейчас они не поддерживаются в браузере Android, так что с их применением в разметке придется немного подождать.

ПАРА СЛОВ ОБ АДАПТИВНОЙ ТИПОГРАФСКОЙ РАЗМЕТКЕ ТЕКСТА

Разметка вебсайта сильно зависит от содержимого. Я не могу закончить раздел статьи о возможностях адаптивной разметки, не обратившись к типографской разметке. CSS3 представляет единицу шрифта, которая может оказаться весьма удобной в адаптивной типографской разметке текста: единицу rem. Тогда как у шрифтов, измеряемых в единицах em, длина относительна их родительскому элементу, в шрифтах, измеряемых в единицах rem, она относительна размеру шрифта корневого элемента. Для адаптивной разметки вы могли бы написать CSS вроде нижеследующего, а затем изменить все размеры шрифтов путем простого изменения размера, определенного для элемента html:

html {
   font-size: 14px;
}

p {
   font-size: 1rem /* то есть 14px */
}

@media screen and (max-width:380px) {
   html {
      font-size: 12px; /* сделайте для мобильных устройств шрифт поменьше */
   }

   p {
      font-size: 1rem /* теперь он равен 12px */
   }
}

За исключением IE 8 и Opera mini, поддержка rem довольно широка. Чтобы больше узнать о единицах rem, прочтите статью Мэтью Леттини (Matthew Lettini) «В защиту единиц rem» (In Defense of Rem Units).

Наилучший способ адаптивно работать с прочим сложным контентом

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

КАК СПРАВИТЬСЯ С ФОРМАМИ НА АДАПТИВНОМ ВЕБСАЙТЕ

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

Новичкам Люк Вроблевски (Luke Wroblewski) советует избегать текстового input-а, а вместо него там, где можно, положиться на чекбоксы, радиокнопки и выпадающие меню выбора. Таким образом, пользователю придется вводить как можно меньше информации. Другая подсказка состоит в том, чтобы не заставлять пользователя нажимать кнопку «Отправить» до получения отклика об отправляемом ими контенте. Проверка ошибок «на лету» в мобильных устройствах, где большинство форм длиннее высоты экрана, особенно важна. Если пользователь сделал ошибку при печатании в форме и для того, чтобы понять это, ему приходится отправить форму, то имеется возможность, что он даже не заметит, где напечатал неправильно.
В будущем новые input-ы и атрибуты HTML5 станут нам отличными помощниками в создании гораздо лучших форм, не требуя (большого) применения JavaScript’а. Например, вы могли бы использовать атрибут required для получения «на лету» отклика об определенном поле. К сожалению, прямо сейчас его поддержка на мобильных устройствах слаба. Атрибут autocomplete также мог бы помочь сделать формы более адаптивными.

Мобильный телефон – это личная вещь, поэтому можно заключить, что такие данные, как имя и почтовый адрес, окажутся постоянными. С помощью атрибута HTML5 autocomplete можно предварительно заполнить такие поля, чтобы пользователю не приходилось печатать эту информацию снова и снова. В ближайшем будущем также можно будет использовать целый список новых input-ов HTML5, чтобы сделать формы более адаптивными.

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

Как могу я выбрать дату, когда мой палец касается трех дат одновременно?

Многообещающее решение лежит в input type=»date» нового HTML5, который устанавливает строку в формате даты. HTML5 input type=»datetime» устанавливает строку в формате даты и времени. Большим преимуществом этого метода является то, что мы даем возможность браузеру решать, какой пользовательский интерфейс применить. Таким образом, тот автоматически оптимизирован для мобильных телефонов. Вот как выглядит input type=»date» на десктопе, на телефоне с Android’ом и «таблетке» (с браузером Chrome), и на iPhone’е и iPad’е.

Визуализация input type=»date» на различных мобильных устройствах.

Обратите внимание, что скриншоты сделаны в моем браузере и на телефоне с Android’ом, поэтому язык автоматически адаптирован к языку системы (французскому). Используя «родные» компоненты, вам больше не придется адаптировать язык к разным версиям вебсайта.

В данное время поддержка input type=»date» на настольных компьютерах отсутствует, за исключением Opera и Chrome. «Родные» браузеры Android’а его вообще не поддерживают, но Chrome для Android’а, а также Safari для iOS – поддерживают. Для возможности использовать это решение в адаптивных вебсайтах все еще многое нужно сделать. Тем временем, вы можете применить для изначально неподдерживающих мобильных браузеров такой полифил, как Mobiscroll.

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

РАБОТА С ТАБЛИЦАМИ В АДАПТИВНОМ ВЕБСАЙТЕ

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

Никто еще не отыскал идеального способа представления таблиц, но некоторые предложения были внесены. Один из подходов состоит в том, чтобы скрыть то, что можно счесть «менее важными» колонками, и обеспечить пользователя чекбоксами, чтобы тот мог выбрать, какие колонки ему просмотреть. На настольном компьютере все колонки будут показываться, тогда как на мобильном устройстве количество отображаемых колонок будет зависеть от размера экрана. В одной из своих статей Filament Group объясняет этот подход и демонстрирует его. Это решение также применяется в переключателе колонок таблицы на jQuery Mobile.

Примеры адаптивных таблиц.

Второй подход обыгрывает идею прокручиваемой таблицы. Вы можете «закрепить» слева отдельную колонку фиксированного размера, а затем на меньшую часть таблицы справа оставить полосу прокрутки. Эту идею в своей статье внедряет Дэвид Бушелл (David Bushell), применяя CSS для отображения всего содержимого в thead в левой стороне таблицы, оставляя пользователю возможность прокручивать контент справа. Zurb для своего плагина использует ту же мысль, но по-другому. В данном случае заголовки остаются вверху таблицы, а таблица дублируется с помощью JavaScript так, чтобы слева показывалась только первая колонка, а все остальные показывались справа с применением полосы прокрутки.

Два примера прокручиваемых адаптивных таблиц

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

Третий подход состоит в переформатировании большой таблицы и разделения колонок так, чтобы они по существу смотрелись как пункты списка с заголовками. Эта техника применяется в “режиме переформатирования” (reflow mode) в jQuery Mobile и объясняется Крисом Койером (Chris Coyier) в статье «Адаптивные таблицы данных» (Responsive Data Tables).

Адаптивное переформатирование таблицы

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

Внедрение стороннего контента: проблема адаптивного интракадра

Многие вебсайты состоят из внедренного стороннего содержимого: видео на YouTube’е или Vimeo, презентации на SlideShare, приложения Facebook’а, фиды на Twitter’е, карты Google Maps и так далее. Многое из этого стороннего контента заставляет вас при вставке применять iframe. Но посмотрите правде в глаза: с iframe в адаптивном дизайне ужасно тяжело работать. Огромная проблема состоит в том, что iframe насильно внедряют фиксированную ширину и высоту прямо в ваш код HTML. Можно принудительно выставить на интракадр ширину в 100%, но вы затем потеряете пропорции вставленного контента. Для внедрения видеоролика или слайдшоу и сохранения при этом исходного соотношения вам придется отыскать обходной путь.

ОБХОДНОЙ МАНЕВР ПРИ ПОМОЩИ HTML И CSS

Тьерри Кобленц (Thierry Koblentz) написал отличную статью с названием «Создание встроенных пропорций видео» (Creating Intrinsic Ratios for Video), где предложил способ вставки адаптивного видео путем применения соотношения в 16:9. Это решение можно распространить на другие виды iframe-ового содержимого, такого как презентации SlideShare и карты Google Maps. Кобленц оборачивает iframe в контейнер с классом, к которому можно обратиться в CSS. Этот контейнер делает возможным подвижное изменение размеров iframe, даже если у того фиксированные пиксельные значения в HTML. Адаптированный Андерсом М. Андерсеном (Anders M. Andersen) код выглядит так:

.embed-container  {
   position: relative;
   padding-bottom: 56.25%; /* соотношение 16:9 */
   padding-top: 30px; /* обходной путь для IE 6 */
   height: 0;
   overflow: hidden;
}

.embed-container iframe,
.embed-container object,
.embed-container embed {
   position: absolute;
   top: 0;
   left: 0;
   width: 100%;
   height: 100%;
}

Это работает с любыми iframe-ами. Единственная потенциальная проблема состоит в том, что вам придется обернуть их все на своем вебсайте в элемент div class=»embed-container». Тогда как этот метод хорош для разработчиков, полностью контролирующих свой код, или тех клиентов, которых достаточно устраивает HTML, он не сработает с теми из клиентов, у кого отсутствуют технические навыки. Вы, конечно, могли бы применить JavaScript для определения элементов iframe и автоматически вставлять их в этот класс. Но вы же видите, что это всего лишь общий обходной маневр, а не идеальное решение.

Работа с адаптивным видео в будущем

HTML5 открывает для видео целый мир возможностей — особенно с помощью элемента video. Отличная новость – поддержка этого элемента на мобильных устройствах удивительно хороша! За исключением Opera Mini, его поддерживают большинство основных браузеров. Элемент video, кроме того, довольно гибок. Представить адаптивное видео очень просто:

video {
   max-width: 100%;
   height: auto;
}

Вы, возможно, поинтересуетесь: «В чем тогда проблема?» Проблема в том, что хотя элемент video могут поддерживать YouTube или Vimeo, вам все еще приходится вставлять видеоролики с помощью уродливого метода iframe. И это печально, друзья мои. Пока YouTube и Vimeo не смогут обеспечить способа внедрения видеороликов в вебсайты с помощью тэга HTML5 video, нам придется искать обходные лазейки, чтобы заставить работать вставку видео на адаптивных вебсайтах. Крис Койер (Chris Coyier) создал такую вещь, как плагин jQuery под названием FitVids.js. В нем применяется первая из упомянутых техник: создание упаковщика вокруг iframe с целью сохранения пропорций.

ВСТАВКА КАРТ GOOGLE MAPS

Если вы внедряете на своем вебсайте карту Google Map, вышеописанная методика с контейнером и CSS будет работать нормально. Но, повторюсь снова, это будет всего лишь маленький ловкий трюк. Кроме того, карта станет пропорционально менять размеры и может оказаться настолько крошечной, что потеряет область фокусирования, которую вы хотели показать пользователю. На странице Google Maps для мобильных устройств говорится, что для вставки в мобильный сайт можно использовать программный интерфейс со статичными картам. Применение статичных карт в самом деле сняло бы проблему iframe. Брэд Фрост (Brad Frost) написал об этом хорошую статью и создал демо-пример адаптивных карт, в котором используется та же техника. JavaScript определяет размер экрана, а затем для мобильных телефонов iframe заменяется на статичную карту. Можно сказать, снова приходится прибегать к трюку, чтобы справиться с проблемой iframe в отсутствии «родного» решения (например, от Google).

НАМ ТРЕБУЮТСЯ ЛУЧШИЕ ПРОГРАММНЫЕ ИНТЕРФЕЙСЫ

А теперь сложный вопрос: Есть ли лучший выход? Самая огромная проблема с использованием iframe для адаптивного внедрения стороннего контента – это недостаток контроля над сгенерированным кодом. Разработчики и дизайнеры сильно зависят от третьей стороны и, в итоге, сгенерированного ею HTML. Количество вебсайтов, обеспечивающих контентом другие сайты, растет быстрыми темпами. Для вставки этого содержимого нам понадобятся гораздо лучшие решения, чем iframe.

Взгляните истине в глаза: внедрение iframe Facebook’а – это настоящая головная боль. Недостаток контроля над CSS может сделать работу неряшливой и даже разрушить иногда весь дизайн. Сеть – очень открытое пространство, так что, может быть, уже пора подумать о более открытых программных интерфейсах! В будущем нам понадобятся лучше и проще применимые API, чтобы любой мог легко вставить контент, не полагаясь при этом на ненадежные фиксированные iframe. Пока эти огромные третьи сайты-источники не решат создать такие интерфейсы, мы продолжим вязнуть в неуклюжих iframe’ах и прибегать к уловкам, чтобы заставить их работать.

Адаптивная навигация: обзор текущих решений

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

Самой ранней и простой попыткой справиться стало преобразование навигации в выпадающее меню на маленьких экранах. К сожалению, оно не идеально. Во-первых, такое решение ужасно осложняется при многоуровневой навигации. Также может вызвать проблемы доступности. Я советую вам прочесть «Прекратите неправильно применять меню на select» (Stop Misusing Select Menus), чтобы узнать обо всех проблемах, создаваемых такой методикой.

Некоторые, включая Брэда Фроста (Brad Frost) и Люка Вроблевски (Luke Wroblewski), пытались решить этот вопрос. Брэд Фрост объединил несколько своих методов на вебсайте This Is Responsive.

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

Примеры выдвижной навигации

Проблема этого метода состоит в том, что навигация остается сверху экрана. В своей статье «Адаптивная навигация: оптимизация для сенсорных устройств» (Responsive Navigation: Optimizing for Touch Across Devices) Люк Вроблевски показывает, до каких областей в разных видах устройств можно легко дотронуться. До верха слева на мобильном устройстве добраться сложнее всего.

Области экрана мобильного телефона и «таблетки», до которых легко добраться, согласно Люку Вроблевски.

На основе этого Джейсон Уивер (Jason Weaver) создал несколько демо-примеров с навигацией внизу. Одно из решений – это якоря в футере с навигацией для маленьких экранов, расположенной внизу страницы, и отсылающая туда пользователя ссылка «Меню». Здесь применена система ссылок-якорей HTML.

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

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

Просмотрите «Нам нужна стандартная иконка показа навигации для адаптивного вебдизайна» (We Need a Standard ‘Show Navigation’ Icon for Responsive Web Design), чтобы увидеть применение этих иконок в настоящих вебсайтах

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

Мобильное своеобразие: «Пользователь применяет мобильное устройство? Если да, что оно может делать?

Мобильные устройства и «таблетки» — это целый новый мир, сильно удаленный от настольных компьютеров, со своими собственными правилами, поведением и способностями. Нам нужно адаптировать свой дизайн к новому спектру возможностей.

ОПРЕДЕЛЕНИЕ ВОЗМОЖНОСТИ СЕНСОРНОГО УПРАВЛЕНИЯ С ПОМОЩЬЮ «РОДНОГО» JAVASCRIPT’А

Не считая размера экрана, спорю, что если бы вы спросили, в чем основное различие между десктопом и мобильным устройством (включая «таблетки»), то большинство сказали бы, что это сенсорные возможности. На мобильном телефоне нет мышки (я не шучу!) и, за исключением некоторых редких гибридных устройств, к которым можно подключить мышь, на «таблетке» ничего не поделаешь с событиями проведения мышью. Это означает, что в зависимости от браузера, псевдокласс CSS :hover может не действовать. Некоторые браузеры мудро обеспечивают «родную» альтернативу события проведения мышью, переводя ее в событие касания. К сожалению, не все браузеры настолько гибкие. Хорошо создать такой дизайн, который не зависел бы от скрытых элементов, проявляющихся при событиях :hover.

Одним из решений может оказаться захват событий касания touch. Рабочая группа W3C начала трудиться над спецификацией события touch. В будущем мы сможем захватывать события, такие как touchstart, touchmove и toucheend. Мы будем способны работать с ними напрямую в JavaScript’е, не требуя таких сторонних каркасов, как Hammer.js или jGestures. Но одно дело JavaScript — а что насчет CSS?

МЕДИАЗАПРОС CSS УРОВНЯ 4 “POINTER”

CSS Уровня 4 определяет новый медиазапрос под названием pointer, который можно применять для выяснения наличия и точности такого указующего устройства, как мышь. Этот медиазапрос принимает одно из трех значений:

none. Устройство не имеет никаких указующих приспособлений.

coarse. Устройство обладает указующим приспособлением с ограниченной точностью; например, мобильный телефон или «таблетка» с сенсорными возможностями, где «указателем» служит палец.

fine. Устройство обладает точным указующим приспособлением, таким как мышь, сенсорная площадка или стило.

С помощью этого медиазапроса для сенсорных устройств можно увеличить кнопки и ссылки:

@media  (pointer:coarse) {
   input[type="submit"],
       a.button {
       min-width: 30px;
       min-height: 40px;
       background: transparent;
   }
 }

Медиазапрос pointer не поддерживается и пока предлагается только как вариант. Тем не менее, у него огромный потенциал, потому что так мы сможем определять сенсорные устройства посредством CSS, без необходимости сторонней библиотеки типа Modernizr.

МЕДИАЗАПРОС CSS УРОВНЯ 4 “HOVER”

Спецификация CSS Уровня 4 предлагает новый медиазапрос hover, который определяет, может ли основная указующая система устройства поддерживать состояние проведения hover. Он возвращает булево: 1 если устройство поддерживает hover, 0 – если нет. Обратите внимание, что он не имеет ничего общего с псевдоклассом :hover. Применяя медиазапрос hover, можно добиться от интерфейса, чтобы тот скрывал определенные свойства для тех устройств, которые не поддерживают состояния проведения. Код будет выглядеть примерно так:

@media  (hover) {
   .hovercontent { display: none; } /* Скройте контент для устройств, которые имеют возможность поддерживать hover. */

   .hovercontent:hover { display: block; }    
 }

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

МЕДИАЗАПРОС CSS УРОВНЯ 4 LUMINOSITY

Еще одна возможность мобильных устройств – сенсор освещения. Спецификация CSS Уровня 4 обладает медиазапросом luminosity, который дает нам доступ к сенсорам освещения устройства прямиком в CSS. Вот как это описывается в спецификации:

«Медиасвойство “luminosity” применяется для запроса о внешнем освещении, при котором используется устройство, что дает возможность автору соответственно приспособить стиль документа».

В будущем мы сможем создавать вебсайты, реагирующие на внешнее освещение. Это сильно улучшит впечатление пользователей. Можно будет определять, например, исключительно яркую окружающую среду с помощью значения washed, соответственно адаптируя контрастность вебсайта. Значение dim применяется для неяркого окружения, такого как темное время суток. Значение normal применимо, когда уровень освещенности не требует регулирования. Код будет примерно таким:

@media  (luminosity: washed) {
   p { background: white; color: black; font-size: 2em; }
 }

Видите сами, что CSS Уровня 4 обещает множество новых интересностей. Если желаете знать, что у него в запасе, и не только связанное с мобильным вебом, то прочтите «Взглянем украдкой в будущее: селекторы Уровня 4» (Sneak Peek Into the Future: Selectors, Level 4)

ОПРЕДЕЛЕНИЕ ДРУГИХ МОБИЛЬНЫХ ВОЗМОЖНОСТЕЙ ПРИ ПОМОЩИ API И JAVASCRIPT’А

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

Другой API, который будет особенно полезен некоторым мобильным пользователям – это геолокация. Хорошая новость – он уже хорошо поддерживается. Этот интерфейс дает возможность определять местоположение пользователя при помощи GPS и обозначать его сигналами сети, такими как IP-адрес, RFID, Wi-Fi и адреса Bluetooth MAC. Его можно применять на некоторых адаптивных вебсайтах для обеспечения пользователей контекстной информацией. Большая сеть ресторанного питания могла бы улучшить впечатление мобильных пользователей, показывая местонахождение ресторанов в их регионе. Возможности просто безграничные.

В W3C также предложили черновик вибрирующего API. С его помощью браузер может обеспечить пользователю тактильный отклик в виде вибрации. Это, однако, уже более специфическая область веб-приложений и мобильных игр в браузере.

Еще один бурно обсуждаемый интерфейс – это сетевой информационный API. Возможность измерения пропускной способности пользователя и ее соответствующей оптимизации соблазнила многих разработчиков. Мы смогли бы передавать высококачественные изображения пользователям с хорошей пропускной способностью, и низкокачественные – с невысокой. При помощи атрибута bandwidth сетевого программного интерфейса можно было бы оценить в мегабайтах в секунду пропускную способность закачки файлов пользователя. Второй атрибут, metered, булев, которые говорит нам о том, имеется ли у пользователя ограничения связи (как с карты предоплаты). В данное время эти два атрибута доступны только через JavaScript.

К несчастью, измерить пользовательское соединение технически сложно, да и само оно способно неожиданно меняться. Пользователь может въехать в туннель и соединение прервется, или резко упадет его скорость. Так что волшебный медиазапрос, измеряющий пропускную способность, в данное время выглядит гипотетическим. Йов Вайсс (Yoav Weiss) написал хорошую статью о тех проблемах, которые создаст подобный медиазапрос, и об измерении пропускной способности – «Запросы пропускной способности? Нам не нужно!» (Bandwidth Media Queries? We Don’t Need ’Em!)

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

Пересмотр способа, которым мы и пользователи обращаемся с контентом

С точки зрения технической перспективы, при работе с контентом возникает много вопросов. Метод mobile-first уже некоторое время побыл частью процессов разработки и дизайна. Мы можем, например, передавать на мобильные устройства минимум необходимых данных, а затем использовать JavaScript и AJAX для условной загрузки содержимого и изображений для десктопов и «таблеток». Но чтобы сделать это, нам также придется пересмотреть методику работы с контентом и быть способными задавать ему приоритеты для генерации достаточно гибкого и адаптивного контента. Хорошим примером этого служит описанное выше решение адаптивной карты: мы загружаем изображение для мобильного устройства и настоящую карту для десктопа. Чем адаптивнее вебсайт, тем сложнее становится работа с его содержимым. Отформатировать адаптивный контент вам поможет гибкий код.

Один из предложенных способов – создание адаптивных блоков путем разметки блоков со множеством span-ов с классами, а затем отображение определенных из них в соответствии с размером экрана. Можно обрезать части блоков для маленьких устройств с помощью медиазапросов. В действии эту методику можно увидеть в блоге Signal vs. Noise и статье Френки Роберто (Frankie Roberto) «Адаптивный текст» (Responsive Text). Даже если можно употребить такой способ для улучшения небольших частей вебсайта, таких как слоган нижнего колонтитула, трудно представить себе его применение ко всему тексту вебсайта.

Это поднимает в адаптивном вебдизайне вопрос, который в будущем станет еще более критичным: важность метаданных и семантической структуры содержимого. Как уже было сказано, контент наших сайтов берется не только у собственных авторов. Если мы хотим автоматически повторно использовать содержимое с других вебсайтов, то оно должно быть хорошо структурировано и подготовлено к этому. Новые тэги HTML5, такие как article и section – отличное начало для получения семантического значения. Нужно так обдумать и структурировать контент, чтобы отдельный элемент (скажем, пост блога) можно было заново использовать и отображать в разных устройствах и в разных форматах.

Сложной проблемой станут метаданные, легко понимаемые всеми людьми, принимающими участие в цепочке создания содержимого вебсайта. Нам придется объяснить им, как использовать метаданные для назначения приоритетов и привыкнуть к подбору контента программным путем, будучи при этом платформо-независимыми. Будет сложно помочь им начать думать понятиями повторно применимых блоков, а не больших кусков текста, копируемого и вставляемого из Microsoft Word в их систему управления контентом WYSIWYG. Нам придется помочь им понять, что содержимое и структура – это две отдельные и независимые вещи, в точности как дизайнерам пришлось осознать, что контент (HTML) и его представление (CSS) лучше всего держать по отдельности.

Мы больше не можем позволить себе писать содержимое, ориентированное только на одну платформу. Кто знает, на каких устройствах будет опубликован наш контент через шесть месяцев или год? Нужно подготовить свои вебсайты к неизвестности. Но чтобы сделать это, нам также нужны лучшие издательские инструменты. Карен МакГрейн (Karen McGrane) провела беседу о «Нашей адаптации к адаптивному контенту» (Adapting Ourselves to Adaptive Content), приведя реальные примеры из издательской индустрии. Она говорит о процессе создания повторно используемого содержимого и представляет идею: «Создав однажды, публикуй везде». Нужно построить лучшие CMS, такие, где можно использовать и генерировать метаданные для расположения контента в приоритетном порядке. Следует объяснить, как работает эта система и как думать на языке модульных объектов повторно используемого содержимого вместо страниц WYSIWYG. Как говорит МакГрейн:

«Вы может написать три разных версии этого заголовка; вы можете написать два разных кратких содержания и прикрепить к ним пару по-разному обрезанных изображений, а потом вы можете оказаться не тем человеком, что принимает решение, какое изображение или заголовок будет отображаться на этой конкретной платформе. Это решение будет приниматься метаданными. Оно будет приниматься по правилам бизнеса. […] Метаданные – вот новое художественное направление».

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

Заключение

Это длинная статья, но она затрагивает тему лишь поверхностно. Сейчас большинство читателей Smashing Magazine понимают, что адаптивный вебдизайн – это гораздо большее, чем просто подбросить на страницу пригоршню медиазапросов, выбрать правильные контрольные точки и увеличить размер изображений вдвое для этих классных телефонов с высокоплотными экранами. Сами видите, путь труден и тернист, и мы по нему еще не прошли. Остается множество нерешенных вопросов, а идеального адаптивного решения пока не существует. Некоторые технические решения, возможно, будут открыты в будущем при помощи некоторых новых представленных здесь технологий, а также W3C, WHATWG и таких организаций, как Filament Group.

Важнее то, что мы, вебдизайнеры и разработчики, можем отыскать даже еще лучшие решения. Такие люди, как Люк Вроблевски и Брэд Фрост, и все упомянутые в этой статье замечательные женщины и мужчины, экспериментируют с большим количеством разных методик. Успех или неудача, самое важное – поделиться тем, что мы — как дизайнеры, разработчики, контент-стратеги и члены сообщества дизайна — делаем в попытке решить некоторые проблемы адаптивного веба. Кроме того, мы все плывем в одной лодке, пытаясь сделать Сеть еще более приятным местечком, верно?

Автор: Stephanie Walter

Источник: http://mobile.smashingmagazine.com/

Редакция: Команда webformyself.

Практика HTML5 и CSS3 с нуля до результата!

Получите бесплатный пошаговый видеокурс по основам адаптивной верстки с полного нуля на HTML5 и CSS3

Получить

Метки:

Комментарии Вконтакте:

Комментарии Facebook:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Я не робот.

Spam Protection by WP-SpamFree