При верстке макета всегда всплывает множество интересных и потенциально проблемных моментов, которые казались дизайнеру элементарными, но на самом деле таили за собой опасное. Все это можно было бы предотвратить, если бы клиент не строил из себя архитектора всей системы, а дизайнер относился к сайтам не как к журналу, а как к сайтам, продумывая взаимодействие с пользователем, создавая грамотную архитектуру, которая логически непротиворечива и действительно дружелюбна к пользователю. Нужен кто-то, кто обладает определенной IT-культурой, в то же время является и дизайнером, и верстальщиком, и немного программистом, даже архитектором БД. Наверное, это тот, которого все называют UI/UX-дизайнером. Такого человека сложно найти, стоит он дорого и путь к такому званию долгий. Поэтому в типичном случае все происходит проще и вместо инженерного подхода наблюдается некоторая разновидность подхода эволюционного. К сожалению, этого бывает достаточно, это даже можно поддерживать, но только если вы не перфекционист.
К черту лирику, этот пост о верстке. К вам может прийти макет, в котором есть, например, меню. Дизайнер решил, что название элемента-кнопки всегда состоит из двух строчек и что элементов всегда 4. Как туда добавлять новый элемент? Уменьшать размер шрифта в навигации? Уменьшить блок сбоку? А если новое имя из одной строчки, что портит все впечатление о сайте? Отлично, в ТЗ может быть описано место, куда вам следует разместить ссылку на раздел, в котором содержится какой-то элемент. Дизайнер оставил под нее место, туда ни в коем случае не влазит больше одного слова, но элемент может быть в нескольких разделах. Я видел, как кто-то написал на JS целый модуль, чтобы он с некоторым интервалом подменял там разделы… Это все мелкие проблемы, они легко решаются без участия дизайнера.
Сетка
В этот момент всегда страшно, что предлагает дизайнер, а у него обычно множество идей на этот счет, особенно в эпоху резиновой адаптивности. Часто дизайнер неявно предполагает, что макет всегда будет иметь такой же размер, как он видит в редакторе. Он, например, может не учесть, что нижняя часть сайта будет практически не видна из-за огромного заголовка, а клиент потом может сказать, что следует уменьшить размер всего сайта, чтобы посетителю сразу было видно что-то пониже. Иногда может быть такое, что макет рассчитывался как резиновый изначально, но при этом в понятие резины вошел также и размер текста, о чем не было нигде сказано. Очень часто не имеется мобильной версии, но при этом хочется, чтобы все отображалось также и работало быстро.
Фиксированная сетка
Идеальный вариант с точки зрения верстальщика. Все просто, никаких относительных размеров. Популярнейший пример такого сайта — ВКонтакте. Можно даже выбрать разрешение под статистически частое для данного сайта. Но есть тотальная проблема — большие разрешения, где очевидна потеря пространства и непреодолимое желание увеличить масштаб. Практически всегда клиент скажет, что это неприятно, а дизайнер практически всегда сделает такую шапку, рядом с которой ну точно нельзя оставлять боковых полос. И все бы ничего, но в контенте ниже тоже нежелательно.
Резиновая сетка
По умолчанию под этим обычно понимают блоки с относительными размерами. Все отлично, но растягивать беспредельно нельзя, так как однажды текст станет нечитаемым и мелким, а расстояния, например, между главной частью и сайдбаром порвут все впечатления раз и навсегда. Поэтому чаще всего резина допускается в некоторых пределах, вне которых сетка ведет себя как фиксированная.
Адаптивная сетка
Это целый набор техник, но упрощенно и с точки зрения сетки — это резина + медиа-запросы. Это просто отлично, но требует больших усилий и самое главное: дизайнеру придется отказаться видеть макет только в размере своего монитора. Это приведет фактически к тому, что будет несколько макетов под несколько разрешений. Возможно, с незначительными изменениями, но часто незначительными не обойтись, если хочется действительно качественно. Это требует анализа архитектуры, юзабилити. Но это был бы идеальный вариант. Часто я слышу, что данный проект не настолько масштабен и дорог, а поэтому это будет оверкилл. Хотя вся проблема в том, что изначальный этап, о котором было сказано выше, не был пройден правильно, а я чувствую его ошибки не только в верстке, а везде вообще.
Подобные сайты, чьи сетки описаны выше, можно встретить повсеместно. Но я никогда не видел сайтов, которые «тотально резиновые».
Тотально резиновая сетка
В какой-то момент я понял, что в текущих условиях глупо пытаться решать все эти проблемы, особенно, если и клиент в них не очень заинтересован. Нужен проект соответствующего масштаба, модный стартап или что-то в этом роде. Но для интернет-каталога или интернет-магазина средней и малой величины настоящая адаптивная верстка, офигенный UI-дизайн — редкость. Хотя хочется такие сайты делать компактно и красиво, чтобы от них не веяло недобросовестным сайтом на какой-то там популярной CMS. Пару раз я действительно потратил много личного времени на правильную адаптивную архитектуру и понял, что я не дизайнер и без его помощи невозможно. Но под рукой никогда не было такого дизайнера, а если и был, то ленивый и занятой (привет).
И тут родилась идея про тотально резиновую верстку. Я не искал плотно на эту тему, но и не встречал, чтобы она была распространена. Не видел ни одного сайта такого. Есть статья, которая описывает подобный подход, но для других задач. Или же я просто невнимательный и редко читаю css-tricks (кстати, крутой пример адаптивного дизайна). Идея заключается в том, чтобы не идти против дизайнера и позволить всем сайтам отображаться так, как их видит дизайнер. Для этого нужно сделать резиновым абсолютно все и в том числе текст.
Суть:
- Абсолютно все размеры чего только можно указываются в rem.
- Размер шрифта body/html должен быть подобран с определенным коэффициентом.
Как уже стало понятно, этот коэффициент — это отношение текущей ширины окна к ширине макета. Это можно сделать, например, с jQuery как-то так:
window.font_size = $(window).width()/$('html').attr('orig-width')*$('html').attr('orig-font-size');
$('html, body').css('font-size', window.font_size);
Здесь orig-width — это ширина макета, orig-font-size — это оригинальный размер шрифта, который использовался в стилях как тот, относительно которого высчитываются rem.
Я использую less и в нем конструкцию вида:
@rounding: 4;
@font-size: 14px;
.p(@name, @size) {
@{name}: unit(round(@size/@font-size, @rounding), rem);
}
Именно этот @font-size и равен orig-font-size. Теперь размеры можно делать такое:
.some-class {
.p(width, 200px);
}
И не переживать при этом, что что-то будет не так.
Кто-то заметил, а зачем тут JS, когда существуют единицы в css типа vw? Да, изначальный размер можно указать и так, это будет работать, но меня смущает поддержка этих единиц.
Минусы
- Использование масштабирования.
- Вычисление чисел с плавающей запятой.
На мой взгляд, оба минуса не являются критически важными и могут быть решены.
Масштабирование работает, но если, допустим, отмасштабировать в 110% и снова открыть страницу, она подстроится под новое разрешение. При этом сайт всегда будет стараться выглядеть одинаково, а масштабирование всегда будет работать в пределах одной «сессии». Я думаю, это не баг, а фича. Мой субъективный умственный эксперимент говорит, что если кто-то пользуется масштабированием, он уже готов к такому поведению и через несколько заходов на сайт его осознает и примет. А если нет, то это еще один повод делать сайты правильно, не пропуская этап, о котором написано в самом начале этого топика. Решить эту проблему для некоторых браузеров можно, отлавливая масштабирование на уровне JS. Это сделать непросто, но можно. Я не пробовал, т.к. этот путь кажется адским костылем, нет единого стандарта на этот счет.
Что касается чисел с плавающей запятой, то вы уже заметили в примере выше округление размеров до 4-ех знаков. Как все знают, это ограничение, наложенное «свыше». Округление в моем случае исправило некоторые баги, субъективно их стало меньше. Кроме этого, субпиксельный рендеринг выполняется везде по-разному и представляет определенную проблему. Выглядит это как однопиксельный пробел. Допустим, где-то между картинкой и блоком может образоваться расстояние в 1 пиксель, причем не на всех разрешениях и не во всех браузерах. Решить это частично можно, генерируя стили под каждое разрешение, что позволит управлять округлением вручную. Но далеко не всякий дизайн чувствителен к такому.
Эпилог
Это сэкономило мне кучу времени и позволило практически не углубляться в вопросы правильного отображения макета на разных устройствах. Для многих сайтов, думаю, это решение проблемы.
Может показаться, что я негативно отношусь к дизайнерам, но это не так. Главное только понимать, что создается не открытка, а целая инфраструктура.
Автор: DmitryPhilimonov
