Пользователь
0,0
рейтинг
29 июля 2011 в 22:25

Разработка → Как сделать один сайт для всех устройств (Responsive Web Design)

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

«Нужно определить, какими устройствами могут пользоваться ваши посетители, проработать и создать для этих устройств представление вашего сайта, определить устройство посредством проверки заголовков браузеров, и отправить наиболее подходящее представление

Почему это глупо


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



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств


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

Сейчас можно сделать 1 сайт с единственной версткой, который будет работать на устройствах, начиная с телефонов, заканчивая огромными телевизорами. Например, yiibu.com или alistapart.com (поуменьшайте окно браузера):





Все это называется «Responsive Web Design»


Responsive состоит из следующих техник:

Резиновый макет на основе пропорций (fluid grid)


Основная идея — формула для вычисления пропорций в процентах «target / context = result». Например, у нас есть макет psd с шириной 1000px. В нем есть два блока: один слева шириной 270px, другой справа 730px. Сверстаем мы их так:

.leftcolumn {
width: 27%; /* 270px / 1000px = 0,27 */
float: left;
}
 
.rightcolumn {
width: 73%; /* 730px / 1000px = 0,73 */
float: right;
}


Если внутри левого столбца будет еще один блок и, скажем, на макете он шириной в 170px, то для него поменяются цель и контекст, и код будет выглядеть вот так:

.leftcolumn .some-div {
width: 62,962963%; /* 170px / 270px = 0.62962963 */
float: left;
}


На хабре был перевод оригинальной статьи Ethan Marcotte «Fluid Grids».

Резиновые изображения (fluid images)


Подстраивают свои размеры под блок родителя. Основная идея в неочевидном применении свойства { max-width: 100% }. Изображение с img { max-width: 100% } никогда не вылезет из своего блока-родителя.

Если блок-родитель меньше, чем размеры img, то изображение пропорционально уменьшится. Этот принцип применим как для img, так и для embed, object, video.

Подробная оригинальная статья «Fluid Images».

Media queries


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

Например, так:

/* начало css */
 
Здесь базовые стили для глупых браузеров. Например, для телефонов не high-end уровня. Pocket Internet Explorer для Windows Mobile 6.5 здесь же :).
 
@media only screen and (min-width: 480px) {
 
Здесь стили более разумных, но все еще мобильных устройств. Android, iPhone  и так далее.
 
}
 
@media only screen and (min-width: 768px) {
 
Планшеты в режиме portrait.
 
}
 
@media only screen and (min-width: 992px) {
 
Планшеты в режиме landscape, нетбуки, ноутбуки, десктоп.
 
}
 
@media only screen and (min-width: 1382px) {
 
Десктоп с большими разрешениями, телевизоры.
 
}
 
 
/* конец css */


media queries понимают все разумные браузеры. Для ie же есть Respond.js

Mobile first


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

Так глупые браузеры без media queries получат самый простой контент (например, на мобильных телефонах). А более продвинутые поймут и отрисуют страницу, беря во внимание media queries.

Подробнее о Mobile first

Ссылки


1. Русскоязычный блог о Responsive Web Design

2. Единственная хорошая книга на эту тему — «Responsive Web Design». Написана Ethan Marcotte, который в общем и положил начало адаптивным макетам. После ее прочтения многое прояснится.

responsive web design book
Mike @Hellcunt
карма
44,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (75)

  • +6
    >>Во-первых, никто не сможет предугадать какими устройствами будут пользоваться ваши посетители
    браузерную войну пережили, пережевем и мобильную))
    • 0
      *переживем
      • 0
        пережуём )
    • 0
      Думаю, мобильная война не завершится никогда. Реалии таковы, что через несколько лет посетителей с мобильных девайсов будет больше, чем с класического десктопа. И спектр этих устройств будет огромен.
      • –2
        по когнитивному диссонансу они не смогут долго быть в конфликте, и кое-как стабилизуруются. 3-4 типа девайсов завоюют 80% рынка, и под них будут затачивать апликации.
        • +15
          Вы не поняли. Уже можно выходить в интернет с электронной книжки, навигатора в машине, домашнего кинотеатра и беговой дорожки:



          Не будет никаких конкретных устройств под которые будут затачиваться веб-приложения. Будет бесчисленное количество девайсов с доступом в интернет. Нужно будет думать и делать универсальные сайты. Это как раз то, о чем эта статья.
          • –5
            резина не панацея от всех бед. вы даже не сможете протестить верстку на всем спектре девайсов, которые по вашему мнению обретут популярность… какие-то габариты приживутся, какие-то нет…
            • –1
              Да, вы и не будите ничего тестить, если вы не мутите какой-то экстравагантный сверхнеюзабельный дизайн и функционал.
            • 0
              Вам тут не обоснованно "-" ставят… скорее всего профаны которые к разработке подобного не имеют отношения…
          • 0
            Вы не правы. Будут разные типы параметров рендера. А вот вы пишите статью, а сами на живом проекте хоть раз meida queries применяли? Я да. На живом проекте это не работает. опредление юзер агента на сервере да, работает.

            По пововду типов рендера, я имею ввиду что это либо стандартизируют либо нет.

            Медикуери, я использую например когда у меня есть iPhone и iPadб А вот они это или Десктом с Хромом определяется на сервер, то есть есть 2 типа рендера, это Десктопы и Мобилы(именно Эпл)
            • 0
              > Вы не правы. Будут разные типы параметров рендера.
              > По пововду типов рендера, я имею ввиду что это либо стандартизируют либо нет.

              О чем вы?

              > А вот вы пишите статью, а сами на живом проекте хоть раз meida queries применяли?

              Уже несколько месяцев, сделано порядка 5 проектов. Это работает.

              > На живом проекте это не работает. опредление юзер агента на сервере да, работает.

              Почему у вас не работает?

              > Медикуери, я использую например когда у меня есть iPhone и iPadб А вот они это или Десктом с Хромом определяется на сервер, то есть есть 2 типа рендера, это Десктопы и Мобилы(именно Эпл)

              О чем вы вообще говорите.
  • –9
    «посредством» пишется слитно — поправьте, а то смешно смотрится, особенно когда «средством» выделено курсивом.
  • +12
    — «В резинку» верстается легко только очень простые макеты. Чуть больше сложностей и появляются блоки фиксированной ширины. Верстка меню, смешанных зависимых блоков упирается в требования фиксированной ширины или высоты. И на изображения max-width или max-height тоже плохо влияют, особенно если требуется сохранять scale. В общем не все так гладко.
    — если есть иллюстрации то сразу появляются проблемы. Если лого и можно разрулить чере background-image, то иллюстрации к статье приходиться либо убирать либо масштабировать в шаблонизаторе. Это убивает идею на корню.

    В общем радужный тон примерно такой-же как и в случае html5, css3 и прочих радостей — как только сталкиваешься с реальными требованиями заказчика, то появляются костыли. А они сразу убивают любую выгоду от кросс-… девайс верстки и получается что выгоднее держать несколько макетов в которых все прозрачно, чем один, но с кучей скрытых хаков и костылей.
    • 0
      Да еще забыл что все эти многочисленные условия делают нормальный css просто огромным, что очень печалит клиента, когда он наблюдает несколько секунд загрузки стилей.
      • 0
        С другой стороны цсс можно пожать гзипом. А то что все стили лежат в одном файле дает только преимущества — уменьшение обращений к серверу. это есть гуд, учитывая что на мобильных устройствах количество таких обращений ограничено
        • 0
          стили и должны быть в одном файле и пожаты, когда можно. К стилю верстки это не имеет отношения никакого
      • 0
        Огромным не получается. CSS на выходе по количеству строк примерно такой же. Дополнительных строк мало. Тут дело в очередности подачи стилей и media queries.
        • +1
          таким же по количеству строк он не может быть. все что меняется — привносить обьем css. И чем заковырестей верстка — тем больше приходиться менять. в 1.5-2 раза больше — это норма, но бывает что c 20-30к может подняться до 100к а то и больше.
          • 0
            20-30 тысяч строк css? %) На хабре будет меньше.

            Таким же, конечно, не будет, но у меня на выходе css получается примерно таким же. Где-то плюс 200-300 строчек. На мой взгляд, это пренебрежимо мало.
            • 0
              kbytes :) строк там — пара тысяч плюс минус
            • –1
              Вероятнее всего вы не умеете верстать. Покажите ваш css и вам это докажу.
              • +1
                Вот мой CSS — pastie.org/2292387

                Доказывайте :)
                • 0
                  Скажите, а такая запись не избыточна ли?
                  div.aside div.news p.date span.month-year {..}
                  • 0
                    «Преждевременная оптимизация — корень всех бед» :)

                    Проект не планировался как highload, это разметка интернет-магазина средней величины. Мы очень плотно поддерживаем этот интернет магазин, часто нужно залезать в css.

                    Поэтому я предпочел наглядность кода. Все равно gzip-размер вполне приемлим.
                    • 0
                      собственно, спрашиваю.
                      я стараюсь избегать таких конструкций, потому что в процессе разработки теги могут заменяться на другие, например p на div, span на strong и тп — по разным соображениям и не всегда, но такое бывает. и тогда требуются лишние телодвижения, чтобы переделать стили.

                      или же дата будет появляется не только в блоке div.news, но и например в гипотетическом div.comment, тогда избыточное наследование вставит палки в колеса
                      • +2
                        Да, бывает такое, на этот случай у меня в редакторе есть функция замены :)
                • 0
                  Здесь я погорячился, думал ваш css состоит из 20 — 30 тысяч строк, а там во много раз меньше. Сорри
              • 0
                * reset.css, print.css и helper.css (с часто используемыми классами для image replacement, clearfix и так далее) в этом проекте подключались отдельно.
    • 0
      > «В резинку» верстается легко только очень простые макеты. Чуть больше сложностей и появляются блоки фиксированной ширины.

      Практикую responsive не очень долго, но мне такие не встречались. Можете привести пример?

      > И на изображения max-width или max-height тоже плохо влияют.

      Что понимается под плохо?

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

      Иллюстрации в статье резинятся с помощью img { max-width: 100% }, об этом есть в статье.

      > В общем радужный тон примерно такой-же как и в случае html5, css3 и прочих радостей — как только сталкиваешься с реальными требованиями заказчика, то появляются костыли.

      Уже больше года использую html5/css3. Все можно решить. Я бы даже сказал не использовать html5/css3 не имеет смысла.
      • 0
        Я собственно приводил примеры когда с резинкой проблемы.
        изображения с max-width или max-height когда упираются в это ограничение начинают корежить соотношение сторон.
        иллюстрации разные бывают — мне пришлось на одном сайте 4 разных размера поддерживать, потому что клиенту было важно иметь качество отображения и отсутствие искажений.
        я тоже больше года пихаю везде doctype html, но полноценную html5 верстку пришлось отменить. css3 тоже не получается использовать в полную, а где получается — там сразу хаки вылазят.
        • 0
          Добавлю, что для мобильных устройств max-width или max-height — так себе решение. Потому что скорость мобильных соединений пока что так себе, плюс у некоторых считается траффик. И открывая на своем телефончике сайт, следует учитывать, что провайдеру будет пофик на то, что у тебя стоит max-width:100px, в то время, когда картинка на самом деле шириной в 1000px и загрузится в свой полный вес
          • 0
            Существует решение этой проблемы github.com/scottjehl/Responsive-Images
            • 0
              спасибо за ссылку, попробую
              хорошее решение, но следует учитывать, что не все мобильные браузеры поддерживают js, или поддерживают криво
              • 0
                javascript нужен только для подачи изображений с большим разрешением. По дефолту подается небольшое изображение. То есть js на мобильных не важен.
            • 0
              Вот они костыли во всей красе!
              • 0
                Ну не костыли, а «progressive enhancement». Теперь ясно, почему у вас с css3 не складывается :)
              • 0
                Сейчас мы живем в период перехода с одних стандартов на другие, каждый браузер поддерживает ту или иную технологию по-своему, поэтому без таких штук все сложней и сложней обходится :)
                Например, вот набор библиотек, которые позволяют эмулировать разные вкусные, но не кроссбраузерные штуки
                github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
                приходится пользоваться ими все чаще
                • +1
                  Да мы всю жизнь живем в период перехода с одних стандартов на другие. И вряд ли этот процесс в обозримом будущем завершится.
    • 0
      Еще стоит упомянуть плавающие блоки (товары к примеру), которые могут иметь разную высоту (из-за переносов текста / заголовка):

      • +2
        • 0
          А если хочется, чтобы высота блоков в одной линии была одинакова? То есть, чтобы высота автоматически растягивалась с учетом самого высокого блока, как у ячеек в таблице?
          • 0
            Вы наверное не очень внимательно посмотрели статью, на которую вам дали ссылку.
            • 0
              Я полностью прочитал статью и сделал тест. Все, как в статье описано, отлично работает. Даже в ИЕ6. Но как сделать одинаковой высоту блоков я не увидел. Возможно это где-то зарыто в комментариях?
              • 0
                Возможно я не совсем понял ваш вопрос. Для каких целей вам это нужно?
                • 0
                  По описанной технологии получается следующий косяк:

                  То есть нижние границы блоков не совпадают. На практике это может привести к появлению довольно забавных лестниц.
                  • 0
                    Не смотря на неодинаковую высоту, лестниц не будет. Эта техника как раз для решения проблем с лестницами :)
                    • 0
                      Я о лестнице в нижней части блоков. Если один блок высотой 100px, второй 120px, третий 90px… вы получите именно ту самую лестницу. Заметна она только при условии, что блок имеет выделенную границу. Если все сделано на одном фоне, то проблемы «как бы» нет.
                      • 0
                        Да, решение этой проблемы уже зависит от конкретных условий.
  • +2
    такой подход можно использовать для простых сайтов — контентных, визиток, блогов и тп. Даже не можно, а нужно.
    Но если есть более-менее сложный функционал и динамика, и требуется поддержка мобильных устройств, то резиновости и media queries не хватит
    • 0
      > Но если есть более-менее сложный функционал и динамика, и требуется поддержка мобильных устройств, то резиновости и media queries не хватит

      Почему?
      • +2
        Потому что существует ряд принципиальных вещей, которые отличаются на десктопе/тв и на мобильных устройствах — от дизайна и юзабилити до технических моментов.
        Если, к примеру, на сайте, который состоит из трех колонок и наполнен в основном текстом и картинками, будет достаточно выстроить эти колонки в один столбик, пожав пропорционально шрифт и изображения, то на каком-нибудь портале или сайте с хитрой функциональностью c кучей js это будет уже потрудней. И начнут вылазить костыли — то флешку нужно срочно переделывать на альтернативу из js/css3, то оказывается, что на мобильных девайсах position:fixed почти нигде не работает и тривиальная задача прибить футер к низу экрана становится реальной проблемой, которую без прикрутки iscroll особо не сделаешь. Если есть карусель на сайте, то ей тоже придется уделить кучу внимания, параллельно добавив тач-ивенты
        ну и так далее
        • 0
          Дизайн и юзабилити меняется так же адаптивно. Насчет технических моментов согласен, есть ряд сайтов, для которых responsive неприменим.
  • 0
    А как на alistapart.com сделано, что блоки при определенной ширине браузера исчезают?
    • 0
      там ничего не исчезает, а меняется. навигация перескакивает то наверх, то в сайдбар, то в основную
      как — вроде же в статье написали :)
      • 0
        Значит, я не понял, как…
  • 0
    В свое время привык к cssgrid.net. И резиновый фреймворк (достаточно убрать max-width), и мобильность, описанная в статье.
    • 0
      Проблема в том, что не все дизайнеры пользуются именно такой модульной сеткой, которая нужна для верстки с помощью cssgrid.net
  • 0
    Статья излишне восторженная.
    Во-первых проблемы будут со сложными макетами.
    Во-вторых автор забывает о мобильных броузерах с ограниченной поддержкой CSS, которые отнюдь не на ура, воспримут подобную верстку.
    В-третьих вышеуказанные сайты на мобильные броузерах с разрешением 320х240 и меньше, даже если отобразятся, то с огромной полосой прокрутки. Что никак не юзабельно.
    • +1
      > Во-первых проблемы будут со сложными макетами.

      Все можно решить.

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

      Решение проблемы — Mobile first. Сначала отдается простейшая разметка. Потом с помощью свойств, которые простые браузеры не видет, отдается остальная верстка. Мобильные браузеры не видят то, чего не могут переварить. Об этом есть в статье.

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

      Это проблема конкретно указанных сайтов. Я своими руками сделал несколько макетов в недавнем времени, где прокрутки на мобильных нет.
  • –1
    Помните игру, уместившуюся внутри фавикона?
    habrahabr.ru/blogs/subconsciousness/29316/

    Так вот, хороший мультиплатформенный сайт должен оставаться юзабельным, даже если кто-то откроет его из «браузера», расположившегося, как эта игрушка, в значке 16х16. Не говоря уже о больших и тяжеловесных иконках для всяких там Android, iOS, Windows 8 и т. д. с разрешением в космические сотни пикселей:)
  • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
  • +3
    Кстати, если активно пользуетесь media queries, рекомендую такую технику

    Во время перестройки блоков на разных экранах применяется css transitions, и объекты плавно летят на свои места или обретают новый размер :)
    Выглядит эффектнее стандартных резких перестроек дизайна и добавляет пару плюсов в карму, когда клиент замечает фичу :)
    • 0
      Спасибо :) Только для себя лениво использовать эту технику, потому что, уверен, помимо меня уменьшать-увеличивать окно браузера вряд ли кто-то будет :)
      • +1
        Ну там особо и напрягаться не надо — просто иметь заранее заготовленные три строчки цсс-кода и вставлять их периодически то там то сям, а потом во время презентации проекта козырнуть перед клиентом :)
  • 0
    Интересные у парня часы на картинке. Никто не подскажет: что это за девайс?
  • 0
    К сожалению вы не очень внимательно прочли мою статью на которую вы ссылаетесь.

    Проблема, которую я описывал, звучит не только как разные размеры в пикселях экранов. Она намного глубже. Это и различные физические размеры и разрешения дисплеев, сравните планшет 10'' 800х600 точек и коммуникатор 3'' 640х480. на втором устройстве даже 13px шрифт вы не прочтете, больно мелко будет. Также разные принципы управления на этих устройствах. Сравните точь- и мультиточ-скрины, а также управляемые пультом телевизоры, и добавьте электронные книги, тогда, возможно, вы поймете суть проблемы.

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

      Я все понимаю :) Смотрите — habrahabr.ru/blogs/webdev/125247/?reply_to=4123988#comment_4121005

      Сравните планшет 10'' 800х600 точек и коммуникатор 3'' 640х480. на втором устройстве даже 13px шрифт вы не прочтете, больно мелко будет.

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

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

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

      Электронные книги. У меня Kindle. Разработанный мною responsive-сайт работает на нем отлично. Единственная разница — сайт черно-белый.
      • 0
        у меня на Nook половина сайтов не работает толком — проблемы с формами и JS — такие уж особенности браузера
      • 0
        А можно посмотреть? :)
        • 0
          Отправил в личку.
  • 0
    Идеалисты. Вы выкидываете понятие таргетинг из проблемы. Представьте, чтоЮ, скажем, БМВ хочет создать автомобиль который охватовал бы все ниши: чтобы был спортивный и яркий, но представительный, чтобы с места разгонялся до 100 км/ч, но был экономный, чтобы вместительный, но маленький…

    Добавление каждого сектора продаж увеличивает цену проекта (сайта) геометрически. Если заказ пришел, от конторы «Рога и копыта» которая продает веники, на сайт-визитку, то ей важен только браузерный рынок. Компания покрупней захочет еще поддержку мобильников. Совсем титаны заходят поддерживать все. Но крупные компании и понимают издержки подобной поддержки и готовы платить большие суммы. И вот тут уже вам просто выбор инструмента дают, как вы хотите это делать: держать три-четыре версии сайта, или делать одну, но для всех.

    У меня такое впечатление что большинство комментирующих поделились на два лагеря:
    1) «О боже, какая потрясающая техника, я смогу увеличить кол-во посетителей, и это ничего не будет мне стоить»

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

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

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

      С приходом планшетов границы еще более размыты. Пора делать сайты в принципе работающие на всем спектре разрешений.

      Если это не интересует заказчика, это проблемы заказчика. Всегда найдутся более дальновидные руководители, чей бизнес и выживет в конкурентной борьбе.
  • 0
    адаптивный дизайн — это замечательно, конечно. вот только не понял если я хочу поставить на background тега body какую-то картинку как мне это сделать-то так чтобы она так же хорошо выглядела при любом разрешении? надо использовать векторную графику я так понимаю? или есть какой-то еще выход?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.