Мобайл ферст. От Mobile First к Mobile Native: о чём важно помнить разработчикам, которые ориентируются только на смартфоны. Что такое адаптивная вёрстка

Железо

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

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

Подход «Mobile First»

Термин “mobile first” последнее время довольно популярен. Он означает, что нужно начать с создания макета для мобильного телефона, но оптимизированного сразу и под экраны с большим разрешением. Таким образом, ваш макет для мобильных телефонов становится главным и основным, и это позволяет не делать других отдельных макетов. Вот так просто!

Используя гибкие, но простые макеты изначально, вы можете обеспечить лучшую поддержку различных браузеров, как с большим так и с маленьким полем отображения- которые не способны отображать полностью отзывчивые макеты. Поэтому если говорить о макетах, то термин “Mobile first” на самом деле значит “прогрессивные улучшения.”
- Итан Маркотт (Ethan Marcotte)

Min-width Медиа Запросы

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

/* Маленькие экраны(по умолчанию) */ html { font-size; 100%; } /* Средние экраны (640px) */ @media (min-width: 40rem) { html { font-size: 112%; } } /* Большие экраны (1024px) */ @media (min-width: 64rem) { html { font-size: 120%; } }

1. Не все браузеры созданы одинаково

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

2. Добавляйте Viewport Мета Тег

Разместите его в блоке вашего HTML. Он включит медиа запросы в макетах для различных девайсов.

Блочная Модель CSS

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



Очищаемая зона вокруг контента.

Рамка (Border)
Рамка находящаяся вокруг padding.


Очищаемая зона вокруг рамки.
3. Используйте box-sizing: border-box

Напишите этот код вначале вашего CSS файла. * — выберет все элементы на вашей странице.

*, *:before, *:after { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; }

Выбор за Вами .clearfix:before, .clearfix:after { content: " "; display: table; } .clearfix:after { clear: both; } .clearfix { *zoom: 1; }

Flow Opposite

Добавляйте класс .flow-opposite к колонкам которые должны отображаться на мобильных устройствах первыми, но быть справа на больших экранах.

@media (min-width: 40rem) { .column.flow-opposite { float: right; } }

Практикуйтесь и совершенствуйте свои навыки

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

Кстати, примером самого успешного отзывчивого дизайна может служить фреймворк

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

Мобильная навигация

Абсолютно приемлемый отзывчивый дизайн, но при стандартных размерах мобильного просмотра (320 x 480 пикселей) все, что вы действительно видите, - это меню навигации. Наверняка, только открыв главную страницу, я хотел бы увидеть что-то другое, нежели это. London & Partners не единственные, у кого есть эта проблема, подобная практика наблюдается во многих отзывчивых дизайнах по всему Интернету.

Итак, какие же есть решения?

Мы уже знаем о нескольких способах обойти это, например, опираясь на jQuery, которая помогает нам разобраться с этим. Возьмите объяснение раскрывающегося меню Chris Coyier Five Simple Steps ("Пять простых шагов") .



Большой экран, маленький экран.

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

Кроме того, вы можете скрыть свою навигацию, но переходить в режим просмотра при нажатии кнопки «меню». Вы можете увидеть этот эффект в действии в последнем Bootstrap Twitter.


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


Чистое решение CSS

Мы будем использовать технику, которую обсуждал Luke, и которая предусматривает использование CSS и подход Mobile First. Какой смысл мы вкладываем в понятие "подход Mobile First"? Проще говоря, мы собираемся разработать прямой мобильный макет, а затем постепенно улучшать дизайн для больших экранов. Мы будем использовать медиа-запросы, которые обнаруживают постоянно увеличивающиеся размеры экрана, постепенно добавляя стиль и функции.

Это означает, что при просмотре дизайна с помощью мобильного устройства будет загружен только самый минимум CSS и ресурсов. Это также означает, что более старые версии IE (которые не распознают медиа-запросы) будут представлены на мобильной версии сайта. Посмотрите Leaving Old Internet Explorer Behind от Joni Korpi о дополнительной информацией об этом.

1.Разметка

Я объясню идеи, лежащие в основе этого решения, по мере нашего продвижения вперед, поэтому пока давайте набросаем некоторую разметку, начав с документа blanco HTML5.

Mobile First Responsive Navigation

Сделав это, добавим некоторую структуру страницы. Непосредственно необходимые моменты и всё для целей нашей демонстрации. Я использовал наполнитель текста Monty Python от Holy Grail (спасибо Chris Valleskey), который является хорошим способом вызвать улыбку на вашем лице в процессе работы:)

Nav Blue. No, yel…

Shut up! Will you shut up?! But you are dressed as one… Camelot! You don"t vote for kings.

We want a shrubbery!!

Look, my liege! Shut up! But you are dressed as one…

  • The nose?
  • Shh! Knights, I bid you welcome to your new home. Let us ride to Camelot!
  • Look, my liege!
Help, help, I"m being repressed!

Why? Listen. Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. Be quiet! A newt?!--end wrapper-->

2.Разметка навигации

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

Да, вы всё увидели верно - мы добавили её в строке 68 после последней статьи. Не забывайте, что сейчас мы разрабатываем для мобильных устройств, позже мы рассмотрим версию desktop. Мы разместили навигацию в нижней части нашей страницы, что кажеться довольно странным. Теперь мы собираемся разместить ссылку в верхней части нашей страницы, чтобы пользователи могли найти навигацию, если пожелают.

Nav Menu

3.Сброс CSS

В зависимости от того, как вы обычно начинаете веб-проекты, этот шаг может отличаться от вашего обычного рабочего процесса. Я всегда придерживался мнения, что перезагрузка Eric Meyer - это прочная основа для начала работы, тем более что недавно он откорректировал её . Мы добавим его правила сброса в таблицу стилей, чтобы начать наш css:

/* http://meyerweb.com/eric/tools/css/reset/ v2.0b1 | 201101 NOTE: WORK IN PROGRESS USE WITH CAUTION AND TEST WITH ABANDON */ html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, figcaption, figure, footer, header, hgroup, menu, nav, section, summary, time, mark, audio, video { margin: 0; padding: 0; border: 0; outline: 0; font-size: 100%; font: inherit; vertical-align: baseline; } /* HTML5 display-role reset for older browsers */ article, aside, details, figcaption, figure, footer, header, hgroup, menu, nav, section { display: block; } body { line-height: 1; } ol, ul { list-style: none; } blockquote, q { quotes: none; } blockquote:before, blockquote:after, q:before, q:after { content: ""; content: none; } /* remember to highlight inserts somehow! */ ins { text-decoration: none; } del { text-decoration: line-through; } table { border-collapse: collapse; border-spacing: 0; }

4.Основные стили

На данный момент наша страница выглядит довольно скучно.


Потому давайте улучшим ситуацию, добавив простой стилизации.

/*begin our styles*/ body { font: 16px/1.4em "PT Sans", sans-serif;; color: #1c1c1c; } p, ul { margin: 0 0 1.5em; } ul { list-style: disc; padding: 0 0 0 20px; } a { color: #1D745A; } h1 { } h2 { font-family: "PT Serif", serif; font-size: 32px; line-height: 1.4em; margin: 0 0 .4em; font-weight: bold; } /*layout*/ .wrapper { } article { border-bottom: 1px solid #d8d8d8; padding: 10px 20px 0 20px; margin: 10px 0; } /*header*/ header { background: #1c1c1c; padding: 15px 20px; } /*shorter clearfix http://nicolasgallagher.com/micro-clearfix-hack/*/ header:before, header:after { content:""; display:table; } header:after { clear:both; } /* For IE 6/7 (trigger hasLayout) */ header { zoom:1; } h1.logo a { color: #d8d8d8; text-decoration: none; font-weight: bold; text-transform: uppercase; font-size: 20px; line-height: 22px; float: left; letter-spacing: 0.2em; } a.to_nav { float: right; color: #fff; background: #4e4e4e; text-decoration: none; padding: 0 10px; font-size: 12px; font-weight: bold; line-height: 22px; height: 22px; text-transform: uppercase; letter-spacing: 0.1em; -webkit-border-radius: 2px; -moz-border-radius: 2px; border-radius: 2px; } a.to_nav:hover, a.to_nav:focus { color: #1c1c1c; background: #ccc; }

Это все основные моменты (шрифты, line-heights, цвета и т.д.), но что действительно важно, так это то, что я нарисовал кнопку «меню» справа, внутри , именно там, где вы и ожидаете её увидеть.


Если вы наведете на него курсор, вы увидите состояние зависания - конечно, это не обязательно для устройств с сенсорным экраном, но подобный характер действия будет перенесен на несовместимые версии Internet Explorer. То, что мы определили в качестве преимущества для мобильных пользователей, это состояние:focus . Это то же самое, что и состояние:hover , но оно будет предлагать важную обратную связь для устройств с сенсорным экраном. Наши пользователи узнают , что они достигли успеха, коснувшись кнопки меню.

В любом случае, щелкните по нему, и вы попадете в навигацию - супер.


Теперь давайте немного займемся стилизацией меню.

5.Навигационные стили

На самом деле мы будем стилизировать нашу основную навигацию по примеру показаного выше London & Partners, за исключением того, что это будет явно внизу страницы.

/*navigation*/ #primary_nav ul { list-style: none; background: #1c1c1c; padding: 5px 0; } #primary_nav li a { display: block; padding: 0 20px; color: #fff; text-decoration: none; font-weight: bold; text-transform: uppercase; letter-spacing: 0.1em; letter-spacing: 0.1em; line-height: 2em; height: 2em; border-bottom: 1px solid #383838; } #primary_nav li:last-child a { border-bottom: none; } #primary_nav li a:hover, #primary_nav li a:focus { color: #1c1c1c; background: #ccc; } /*footer*/ footer { font-family: "PT Serif", serif; font-style: italic; text-align: center; font-size: 14px; }

Намного лучше. Мы сделали ссылки меню приятными и большими (подробнее читайте в блоге Luke Wroblewski Touch Target Sizes) и еще раз определили состояние:focus для отзывов пользователей.


6.Делаемся большими

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

Но в какой момент он становится таковым? Есть много способов, как подойти к медиа-запросам, но мы будем работать на основе того, что мобильный viewport - 320 x 480 пикселей. Он имеет ширину 320 пикселей при просмотре в ориентации "portrait", 480 пикселей в ширину при просмотре в "landscape", поэтому будет оправдано, если мы установим наш первый медиа-запрос, чтобы он определял любой экран, больше 480 пикселей.

Однако следующий шаг - это, вероятно, планшет. IPad имеет разрешение 980px x 768px, поэтому можно смело предположить, что для нашего мобильного макета подходит всё, что меньше 768px. Все, что больше 768px, может работать с макетом навигации для компьютеров, "desktop" версия.

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

/*media queries*/ @media only screen and (min-width: 768px) { }

Этот медиа-запрос будет запускать все стили, которые в нем содержаться, если наименьшее значение viewport 768 пикселей. Обратите внимание на включение единственного ключевого слова, которое гарантирует, что Internet Explorer 8 не запутается и попробует обработать запрос. Для более детальной информации см. .

Давайте начнем нашу работу с того, что заставим кнопку "меню" исчезнуть:

@media only screen and (min-width: 768px) { a.to_nav { display: none; } }

Когда браузер будет немного шире, кнопка меню больше не будет отображаться.

7.Перемещение навигации

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

@media only screen and (min-width: 768px) { a.to_nav { display: none; } .wrapper { position: relative; width: 768px; margin: auto; } #primary_nav { position: absolute; top: 5px; right: 10px; background: none; } #primary_nav li { display: inline; } #primary_nav li a { float: left; border: none; padding: 0 10px; -webkit-border-radius: 2px; -moz-border-radius: 2px; border-radius: 2px; } }

Для того, чтобы это было возможно, мы сначала должны правильно разместить его parent (.wrapper). Мы можем либо сделать это здесь, в медиа-запросе, либо определить это в начале нашей таблицы стилей.

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


8. И последнее...

Если вы были внимательными, вы заметили, что у нас все еще есть ссылка «наверх» в навигации - теперь нам она не нужна, верно?

Мы можем удалить ее несколькими способами, но чтобы четко представлять что происходит, давайте сначала добавим класс к элементу списка:

  • Top

    • И тогда мы можем избавиться от него в нашем медиа-запросе:

    #primary_nav li.top { display: none; }

    Вывод

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

    Дополнительные ресурсы

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

    • Luke Wroblewski"s
    • Chris Coyier"s

    Инвестор и партнёр венчурного фонда Andreessen Horowitz Бенедикт Эванс написал материал о том, почему всё больше разработчиков переходят с парадигмы Mobile First к парадигме Mobile Native, в чём между ними разница и о чём важно помнить создателям мобильных приложений..

    «Несколько лет назад ИТ-компании перешли к стратегии Mobile First. До этого в организациях были отдельные департаменты разработки под мобильные платформы и работники, которые занимались развитием мобильного направления. Теперь новая функциональность сразу появляется на смартфонах, а на ПК иногда и не переносится», - пишет Эванс.

    По словам инвестора, в 2016 году всё больше компаний приходят к парадигме Mobile Native. «Это эволюция принципа Mobile First. Что будет, если попросту забыть о ПК и дешёвых мобильных телефонах? Если полностью сосредоточиться на 2,5 млрд смартфонов и полностью опустить рынок low-end-устройств. Сможете ли вы построить большую компанию?».

    По мнению Эванса, выбирающим стратегию Mobile Native разработчикам следует в первую очередь обдумать несколько основных моментов:

    «Я бы хотел обратить внимание на последний пункт - стоит задумать, сколько различных технологий задействовано в таких приложения, и почему появление подобных сервисов было невозможно на ПК», - замечает Эванс.

    Поразительно, насколько смартфоны одновременно сложнее и проще в использовании, чем ПК - и особенно это касается мобильного интернета.

    Инвестор говорит, что с мобильным телефоном пользователи могут делать множество вещей, которые им не позволяла делать система, включавшая в себя сам компьютер, клавиатуру и мышь. Это открывает новые возможности как для самих владельцев смартфонов, так и для разработчиков. «Уже выросло целое поколение, которое готово к парадигме Mobile Native. А приложения, которые в 2007 году вызвали бы восторг, сейчас кажутся совсем простыми».

    «Разработчики наконец могут отказаться от парадигмы Mobile First и применить свои навыки для того, чтобы максимально охватить возможности двух миллиардов смартфонов на планете. Это напоминает мне переход к Web 2.0 около девяти лет назад. Тогда все разработчики заявили: "А знаете, нам совсем не обязательно думать о Lynx, CGI-скриптах и диалап-соединении. Мы прошли ту точку, когда использование тега IMG казалось спорным решением, и можем думать о том, как создавать интерфейсы и предоставлять пользователям новые услуги"», - заключает Эванс.

    Дата публикации: 2013-03-29

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

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

    Постановка целей

    Первым предпринятым шагом в нашем проекте стало создание списка преимуществ и препятствий на пути примененного нами адаптивного подхода. Наш список выглядел так:

    ПРЕИМУЩЕСТВА

    1. Построение, поддержка и продвижение одного вебсайта.

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

    3. Перспектива на будущее, так как разметка будет изменяться в зависимости от размера экрана, а не только размера современных популярных устройств.

    ПРЕПЯТСТВИЯ

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

    2. Из-за «безразмерной» разметки мы неспособны изменить исходный порядок такой разметки (или полностью исключить из нее неважные элементы) в зависимости от устройства или размера экрана.

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

    Начиная с содержимого

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

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

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

    К тому же, мы сели и поговорили с некоторыми своими текущими клиентами, представляющими большую часть аудитории нашего вебсайта, и задали им несколько вопросов, в числе которых: «За каким контентом вы заходите на наш вебсайт, сидя за монитором десктопа?» и: «А как насчет «таблетки» или телефона?». Интервью, конечно, были более детальными, но вы и так видите, что нас интересовало. И опять было обнаружено, что искомый контент был одним и тем же, вне зависимости от применяемого устройства.

    Данные диктуют направление

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

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

    Создание дизайна крайних точек

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

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

    Mobile First

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

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

    Изображение, довольно большое, предназначалось стать частью дизайна только на больших экранах (от 660 px и больше). Так как наш CSS начинается с дизайна для мобильных устройств, эта большая графика никогда не отправляется на малоэкранные устройства, потому что медиазапрос, загружающий данное изображение, активируется только большими экранами. Медиазапрос, применяющий фон к элементу html, выглядит так:

    @media only screen and (min-width: 660px) { html { background: url(/images/bg-watercolor.jpg) no-repeat fixed center top; } }

    @ media only screen and (min - width : 660px ) {

    html {

    background : url (/ images / bg - watercolor . jpg ) no - repeat fixed center top ;

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

    Создание ради дизайна, а не устройств

    Начав применять адаптивный дизайн в своих веб-проектах, мы сосредоточились на известных устройствах и размерах экранов, и наши медиазапросы часто отражали именно их (iPhon’ы, iPad’ы – как в книжной, так и альбомной ориентации – лэптопы, широкоэкранные десктопы и т.д.). Со временем обнаружилось, что это не самый лучший подход, потому что адресован только тем устройствам и размерам экранов, которые популярны сегодня, а не тем, которые могли бы появиться в будущем. Одна из мощных перспективных сторон адаптивного веб-дизайна – его направленность в будущее. Поэтому для полной реализации этой сильной стороны мы отошли от построения ради устройств вместо того, чтобы позволить дизайну самому диктовать контрольные точки медиазапросов.

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

    Чтобы разобраться с этим методом, мы создали графику и установили ее в качестве фона десктопа. Вертикальные линии показывали ширину в 320 px (наш самый маленький размер), потом расставлялись на каждой сотне пикселей начиная с 400, и применялись в качестве направляющих по мере масштабирования окна браузера для определения того, где дизайн начинал «ломаться», а затем мы использовали эти примерные значения в пикселях в окончательных медиазапросах, которые и добавили в CSS.

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

    Одна из областей нашего вебсайта, где очевидно увеличение медиазапросов – навигация.

    Адаптивная навигация

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

    1. Основная навигация;

    2. То, что мы называем «вспомогательной навигацией», которая ссылается на различные порталы и сервисы, используемые нашими клиентами;

    3. Навигация нижнего колонтитула;

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

    Так как наш CSS — mobile-first, одной из первых забот стала установка навигации для малоэкранной разметки. Этот означает отключение отображения всех разделов навигации, кроме основной навигации.

    #helpNav, .subNav, footer nav { display: none; }

    #helpNav, .subNav, footer nav {

    display : none ;

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

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

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

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

    Вот CSS нашей вспомогательной навигации:

    #helpNav { display: block; position: absolute; top: 1px; right: 0px; width: 100%; text-align: right; } #helpNav ul { padding-left: 10px; } #helpNav li { display: inline; padding-right: 6px; padding-left: 6px; background-color: #2f6a98; } #helpNav a { font-size: 12px; padding: 0 6px; color: #FFF; border-radius: 20px; } #helpNav a:hover { background-color: #f66606; }

    #helpNav {

    display : block ;

    position : absolute ;

    top : 1px ;

    right : 0px ;

    width : 100 % ;

    text - align : right ;

    #helpNav ul {

    padding - left : 10px ;

    #helpNav li {

    display : inline ;

    padding - right : 6px ;

    padding - left : 6px ;

    background - color : #2f6a98;

    #helpNav a {

    font - size : 12px ;

    padding : 0 6px ;

    color : #FFF;

    border - radius : 20px ;

    #helpNav a:hover {

    И области навигации подстраниц:

    SubNav { display: block; width: 25%; float: left; } .subNav h4 { padding-bottom: 8px } .subNav ul { list-style: disc; color: #c65204; padding: 0 0 20px 20px; } .subNav li { padding-bottom: 14px; } .subNav a { color: #186483; font-size: 21px; font-family: "RokkittRegular", Times, "Times New Roman", serif; line-height: 1; }

    SubNav {

    display : block ;

    width : 25 % ;

    float : left ;

    SubNav h4 {

    padding - bottom : 8px

    SubNav ul {

    list - style : disc ;

    color : #c65204;

    padding : 0 0 20px 20px ;

    SubNav li {

    padding - bottom : 14px ;

    SubNav a {

    color : #186483;

    font - size : 21px ;

    line - height : 1 ;

    Наконец, навигация нижнего колонтитула:

    footer nav { display: block; margin-top: 40px; } footer nav ul { list-style: none; } footer nav li { padding-bottom: 24px; width: 19%; padding: 0 5% 20px 0; float: left; } .innerNav li { width: 100%; float: none; padding-bottom: 4px; } footer nav a { color: #575454; font-size: 12px; } .innerNav a { font-weight: normal; }

    footer nav {

    display : block ;

    margin - top : 40px ;

    footer nav ul {

    list - style : none ;

    footer nav li {

    padding - bottom : 24px ;

    width : 19 % ;

    padding : 0 5 % 20px 0 ;

    float : left ;

    InnerNav li {

    width : 100 % ;

    float : none ;

    padding - bottom : 4px ;

    footer nav a {

    color : #575454;

    font - size : 12px ;

    InnerNav a {

    font - weight : normal ;

    Пиксели или емы

    Вы заметите, что для своих медиазапросов мы применяли значения в пикселях. Применение пиксельных медиазапросов – с этого мы, подобно прочим разработчикам внешнего интерфейса, начали выполнение адаптивного дизайна, и утвердили эту практику как часть своего рабочего процесса. Однако, в духе «построения лучшего адаптивного вебсайта», я укажу статью о размерных медиазапросах, применяющих em’ы, представленную нашему вниманию во время редактирования этого раздела. По сути дела, чтобы улучшить внешний вид сайта при увеличении zoom in, очень сильно рекомендуется конвертировать px-медиазапросы в em-медиазапросы путем деления всех пиксельных значений на размер шрифта body.

    Эта чудесная статья подвигла нас пересмотреть свои взгляды на медиазапросы на основе пикселей, и это еще один пример того, как мы продолжали оттачивать адаптивный метод. Тогда как мы не применяли em’ы в своих медиазапросах в этом отдельном проекте, сейчас мы с ними экспериментируем, и этот подход стоит упоминания здесь.

    Основная навигация

    Наша основная навигация представлена на широких экранах, как горизонтальный ряд, проходящий через весь верх разметки. На маленьких экранах структура основной навигации меняется так, что вверху каждой страницы появляется большая кнопка «Меню», которая ссылается на навигацию внизу страницы. Чтобы добиться этого, мы добавили в заголовок ссылку с ID menuLink и класс oftabButtonr, что уже почти является началом разметки. Затем поместили раздел с ID mainNav в самый конец разметки. Внутри этого раздела находится наша основная навигация, которая представляет собой просто неупорядоченный список с несколькими прочими неупорядоченными списками для меню разделов субстраниц внутри. У нас также имеется привязка-«якорь» с ID toTop, которая действует как ссылка наверх страницы.

    В продолжение принципа mobile-first мы определили стили ссылке меню вверху малоэкранной разметки, чтобы та смотрелась как кнопка.

    #menuLink a { float: right; margin: -56px 8px 0 0; } .tabButton a { color: #FFF; font-family: "RokkittRegular", Times, "Times New Roman", serif; font-size: 20px; background-color: #45829b; padding: 10px 12px; border-radius: 10px; } .tabButton a:hover { background-color: #f66606; }

    #menuLink a {

    float : right ;

    margin : - 56px 8px 0 0 ;

    TabButton a {

    color : #FFF;

    font - family : "RokkittRegular" , Times , "Times New Roman" , serif ;

    font - size : 20px ;

    background - color : #45829b;

    padding : 10px 12px ;

    border - radius : 10px ;

    TabButton a : hover {

    background - color : #f66606;

    Меню нашей основной навигации установлено на малоэкранное отображение:

    #mainNav { margin-top: 30px; width: 100%; } #mainNav #toTop a { float: right; margin: 0 8px 0 0; font-size: 20px; } #mainNav nav { padding-top: 80px; } #mainNav ul { list-style: none; } #mainNav li { background: #45829b; border-bottom: 1px solid #abc7d2; padding: 4px 10px 4px 15px; } #mainNav li:hover { background-color: #f66606; } #mainNav a { font-size: 24px; color: #FFF; font-family: "RokkittRegular", Times, "Times New Roman", serif; }

    #mainNav {

    margin - top : 30px ;

    width : 100 % ;

    #mainNav #toTop a {

    float : right ;

    margin : 0 8px 0 0 ;

    font - size : 20px ;

    #mainNav nav {

    padding - top : 80px ;

    #mainNav ul {

    list - style : none ;

    #mainNav li {

    background : #45829b;

    border - bottom : 1px solid #abc7d2;

    padding : 4px 10px 4px 15px ;

    #mainNav li:hover {

    background - color : #f66606;

    #mainNav a {

    font - size : 24px ;

    color : #FFF;

    font - family : "RokkittRegular" , Times , "Times New Roman" , serif ;

    Наши подменю, которые не отображаются в исходном положении, теперь можно показывать, как того требует страница. У каждого из этих подменю есть уникальный ID, такой как servicesTab, и у каждого раздела вебсайта есть класс, примененный к тэгу body. Класс раздела “Company” – companyPage. Мы применяем этот класс для назначения стилей всему разделу вебсайта. Для включения подменю мы используем класс разделов подменю, как оно требуется, когда раздел активирован.

    CompanyPage #companyTab ul, .newsPage #newsTab ul, .contactPage #contactTab ul, .servicesPage #servicesTab ul { display: block; }

    CompanyPage #companyTab ul,

    NewsPage #newsTab ul,

    ContactPage #contactTab ul,

    ServicesPage #servicesTab ul {

    display : block ;

    Увеличиваемся

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

    #menuLink a, #toTop a { display: none; }

    #menuLink a, #toTop a {

    display : none ;

    #mainNav { position: absolute; top: 92px; margin: 18px 2% 0 2%; width: 96%; text-align: center; } #mainNav nav { padding: 5px 0; border-top: 1px solid #bacfd7; border-bottom: 1px solid #bacfd7; } #mainNav li { background: none; display: inline; border-bottom: 0; border-right: 1px solid #bebebe; padding: 0 6px 0 8px; margin: 4px 0; } #mainNav a { font-size: 16px; color: #45829b; } #mainNav a:hover { color: #f66606; }

    #mainNav {

    position : absolute ;

    top : 92px ;

    margin : 18px 2 % 0 2 % ;

    width : 96 % ;

    text - align : center ;

    }

    #mainNav nav {

    padding : 5px 0 ;

    border - top : 1px solid #bacfd7;

    border - bottom : 1px solid #bacfd7;

    }

    #mainNav li {

    background : none ;

    display : inline ;

    border - bottom : 0 ;

    size : 16px ;

    color : #45829b;

    }

    #mainNav a:hover {

    color : #f66606;

    }

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

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

    Получаем помощь от CMS

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

    Одна из наибольших помех адаптивному подходу состоит в том, что вы не можете предоставить различную разметку или различный исходный код в различные устройства. Это препятствие мы и хотели победить с помощью нашей CMS. В течение экспериментирования и исследований мы наткнулись на статью с названием Настоящая адаптивность с помощью ExpressionEngine (Going Truly Adaptive With ExpressionEngine). Применив подробно описанную в этой статье методику, нам удалось использовать скрипт определения устройств, чтобы установить переменную в мобильной или полноразмерной системе. Затем мы смогли загружать разметку на свой сайт в зависимости от того, которая из этих переменных нам встретилась.

    Продвинувшись вперед и применив определение устройства, мы смогли проделать другие очень маленькие изменения для дальнейшего улучшения впечатления от применения мобильных устройств. Для нас это было вроде прогрессивного улучшения, где мы создали качественное решение, а затем попытались продвинуть его вперед, чтобы донести слегка оптимизированный опыт. Обязательно прочтите такое же мнение Криса Койера (Chris Coyier) о комбинировании RWD и мобильных шаблонов , где он спорит по поводу смешивания и сочетания в своей мобильной стратегии различных техник.

    Начинаем с маленького

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

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

    Синтаксис довольно прост. Единожды установив переменные - а вышеупомянутая статья объясняет, как легко это сделать, добавив в системный файл config.php маленький скрипт - вы можете применять эти переменные как оператор if.

    img src = "{teaser-image}" alt = "{title}" / > { / if } { if global : site_version == "mobile" } { title } { / if }

    Это – синтаксис ExpressionEngine, но вы сможете прочесть его и легко увидите, что происходит. Если встречается переменная full, то мы доставляем из вступления статьи в базе данных teaser-image. Если вместо этого встречается переменная mobile, то доставляем название статьи title.

    Тот же подход применяется к разделам домашней страницы “News” и “Blog”, доставляя три коротких тизера, если встречается переменная full, и только один, если mobile. Этот синтаксис выглядит так:{ exp : channel : entries channel = "news" { if global : site_version == "full" } limit = "3" { / if } { if global : site_version == "mobile" } limit = "1" { / if } }

    Здесь видно, что мы получаем доступ к каналу ExpressionEngine с названием news. Свою переменную мы применяем для определения того, сколько текущих элементов будут отображаться из этого канала, использовав параметр limit.

    Продвигаемся еще на шаг

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

    Для каждой статьи мы создаем два набора изображений: один полноразмерный шириной 650px, и второй – почти вполовину этого размера. Затем применяем в своей статье переменные (но сначала нужно разрешить в шаблоне своей страницы код ExpressionEngine), и добавляем разметку для обоих наборов изображений - но только один из них доставляется в браузер. Мобильные устройства получают маленькие изображения, а все остальные – полноразмерные.
    Тот же подход применяется к большой рекламной области домашней страницы. Эти вращающиеся баннеры и изображения рекламируют важные вещи, такие как грядущие события, новые услуги, объявления, лучше, чем остальные области домашней страницы. Рекламный щит – другой приятный во всех отношениях элемент, который предназначен только для больших дисплеев. Снова применяем переменные для донесения раздела основного рекламного щита, а также запускающего его JavaScript’а, до подходящего устройства - что дает нам возможность эффективно рассылать разную разметку на разные устройства и устраняя еще одну помеху, обозначенную нами в начале проекта.

    С помощью подхода mobile-first и нашего CMS мы способны доставить нашу домашнюю страницу до пользователей настольных компьютеров в 738.3 KB и существенно уменьшить ее всего до 174.4 KB для мобильных пользователей.

    Планы альтернативных вариантов

    Одним из вопросов, которые всегда тревожили меня по поводу подхода mobile-only и определения устройства: «Что происходит, если определение не срабатывает? Доставляется ли до мобильного устройства «нормальная» версия вебсайта, показывая этим недействительность вашего тщательно созданного мобильного дизайна? Эта возможность – одна из основных причин того, почему я избежал решения mobile-only, применяемого в прошлом для определения устройства.

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

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

    Прогресс, не идеал

    Несколько лет назад один клиент сказал мне кое-что, о чем я помню до сих пор. Говоря о своем вебсайте, он сказал:

    «Не беспокойтесь о том, чтобы сделать мой вебсайт идеальным. Просто работайте над его улучшением. Его постоянное улучшение будет движением в правильном направлении ».

    Эта идея годами вдохновляла меня и напоминала о том, что нельзя отвергать лучшее только потому, что оно неидеально.

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

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

    Как вы считаете?

    Как вы строите адаптивные вебсайты? Вы применяете определение характеристики или определение устройств? Когда вы рекомендовали бы применять то или иное? Мы ждем ваших комментариев!

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

    Поисковые системы используют ряд критериев для оценки адаптивности сайта при просмотре на мобильных устройствах. Google старается упростить пользование Интернетом для владельцев смартфонов и планшетов, отмечая в мобильной выдаче адаптированные под мобильные устройства сайты специальной пометкой mobile-friendly . В Яндексе также работает алгоритм, который отдает предпочтение сайтам с мобильной/адаптивной версией для пользователей в мобильном поиске.

    Проверить отображение страницы на мобильных устройствах можно на сервисах и .


    Рис. 1. Мобильная выдача Яндекса и Google с пометкой о дружелюбности сайта к мобильным устройствам Что такое адаптивная вёрстка

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

    Основные приёмы создания адаптивного сайта приведены в статье . Для отзывчивого дизайна ширина основного контейнера сайта задаётся в % , при этом она может быть равна как 100% ширины окна браузера, так и меньше. Ширина столбцов сетки также задаётся в % . В адаптивном дизайне ширина основного контейнера и столбцов сетки фиксируется с помощью значений в px .

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

    Вёрстка главной страницы

    Страница состоит из трёх основных блоков: верхний колонтитул (шапка), контейнер-обёртка для основного содержимого и сайдбара, и нижний колонтитул (футер). В качестве переломных точек дизайна возьмём 768px и 480px .

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


    Рис. 2. Пример адаптивной верстки 1. Метатеги и раздел

    1) Добавим в раздел необходимые файлы — ссылку на используемые шрифты, библиотеку jQuery, а также плагин prefixfree (чтобы не писать для свойств браузерные префиксы):

    Адаптивная вёрстка сайта

    2. Шапка страницы

    В шапке страницы поместим следующие элементы-контейнеры:
    логотип

    Понравилась статья? Поделиться с друзьями:
    Вам также может быть интересно
    Как восстановить
    Как восстановить "Мои...
    Гранулема зуба — воспаление тканей возле зубного корня. Лечение проводит стоматолог, дополнительно применяют отвар
    Конвертирование файла HTML do JPG
    Конвертирование файла HTML...
    Гранулема зуба — воспаление тканей возле зубного корня. Лечение проводит стоматолог, дополнительно применяют отвар
    Первый взгляд на Sony Xperia XZ1 Compact: Компактный флагман вернулся
    Первый взгляд на Sony...
    Гранулема зуба — воспаление тканей возле зубного корня. Лечение проводит стоматолог, дополнительно применяют отвар
    Lenovo S660 - Технические характеристики
    Lenovo S660 - Технические...
    Гранулема зуба — воспаление тканей возле зубного корня. Лечение проводит стоматолог, дополнительно применяют отвар
    Нестандартный вывод дополнительных полей в К2
    Нестандартный вывод...
    Гранулема зуба — воспаление тканей возле зубного корня. Лечение проводит стоматолог, дополнительно применяют отвар
    Решение ошибки «Установка Windows на данный диск невозможна…
    Решение ошибки «Установка...
    Гранулема зуба — воспаление тканей возле зубного корня. Лечение проводит стоматолог, дополнительно применяют отвар