Пользователь
0,0
рейтинг
25 апреля 2009 в 22:39

Разработка → «Резина» (fluid grids) перевод

image

В этом году я делал редизайн веб-сайта с большим количеством контента. Требования к дизайну были простые: клиент попросил сохранить существующий логотип компании, улучшить плотность печати и увеличить читабельность. Так что, в самом начале разработки дизайна, я потратил значительное количество времени на планирование хорошо структурированной сетки для библиотеки информационных блоков.
Последние несколько лет такой образ мышления стал более распространенным. Благодаря Марку Балтону (Mark Boulton), Кхои Винху (Khoi Vinh), и другим, мы видим возрождение интереса к типографской сетке, и того, как использовать ее в сети. И, откровенно, идея была сногсшибательным хитом: миллионы CSS фреймворков расцвели множеством дополняющих их инструментов, каждый из которых создан для того, чтобы сделать основанный на сетке дизайн еще более доступным для среднестатистического дизайнера/верстальщика. И почему бы и нет? После нескольких минут мышления в категориях сетки достоинства становятся очевидны: дизайнеры получают рациональный, структурированный фреймворк для образования структуры информации и пользователи получают хорошо структурированные, читабельные сайты.
Между тем, наш клиент выдвинул еще одно, убойное, требование: дизайн должен быть тянущимся и изменять размеры вместе с окном браузера. Обычно это заставило бы меня шумно и смущенно радоваться. «Резина» — недооцененная парадигма в веб-дизайне. Она отдает контроль над дизайном в руки пользователей и их привычек веб-серфинга. А еще ее возможности абсолютно не соответствуют фантазии веб-дизайнеров.


Минимальное разрешение экрана: маленькая невинная ложь.


Вместо того, чтобы исследовать достоинства «резины», мы полагаемся на меленькую невинную ложь: «минимальное разрешение экрана». В этих трех словах содержится могущественная магия, под покровом которой мы создаем дизайны с фиксированной шириной, один за другим, возможно лишь увеличивая ширину дизайна каждые несколько лет, когда это становится безопасным. «Минимальное разрешение экрана» позволяет ограниченному подмножеству пользователей видеть сайта таким, как предполагает бог и Photoshop. Эти пользователи всегда просматривают сайты с развернутым на весь экран окном браузера и разрешением 1024х768, и никогда не используют, скажем, OLPC laptop, или мониторы старше четырех лет отроду. Если пользователь не соответствует требованиям «минимального разрешения экрана», ну, для них есть полоса прокрутки, верно?
Конечно, когда я кодил сайт, мне было не до роскоши написания резких обличительных речей на тему недостатков дизайна с фиксированной шириной. Вместо этого я остался наедине с отрезвляющим фактом: пока мы разрабатывали достаточно сложную сетку, чтобы удовлетворить запросы контента клиента, клиент — и в дополнение ко всему пользователи — хотели «резину». Почти все основанные на сетке дизайны, которые я могу перечислить, обладали жестко заданной шириной, и я остался со сложным вопросом: как сделать «резину»?
Как оказалось, это просто вопрос контекста.

Я действительно должен быть благодарен IE?


Столкнувшись с непреодолимой проблемой, я сделал то, что у меня получается лучше всего: обошел ее. Временно отложив в сторону вопрос «как» заставить сетку вести себя как «резина», я делал то, что умел: сначала стили для цвета и фона, затем определил шрифт.
Вы можете уже знать о хорошо документированной проблеме IE с изменением размера шрифтов, если размер определен в пикселях — или, скорее, решительно отказывается это делать. Установите шрифт размером 16 пикселей Georgia и, неважно как пользователь старается увеличить или уменьшить размер текста, в IE он останется размером в 16 пикселей. IE7 и старше позволяет пользователю масштабировать всю страницу, но простое изменение размера шрифта, размер которого определен в пикселях, в IE по-прежнему табу. Так что, чтобы дать пользователям больше гибкости, мы, стандарто-мыслящие дизайнеры предпочитаем полностью обходится без пикселей, и использовать для определения размера шрифта относительные единицы, будь то ключевые слова, проценты или мои любимые, em.
Если вы когда-нибудь работали с относительными единицами измерения, такими как em, вы понимаете, что все дело в контексте: другими словами, реальный размер em вычисляется относительно размера шрифта родительского элемента. Например, скажем, мы работаем со следующим макетом:

image
Пример простого определения размера текста с помощью пикселей.

Ничего смешного: параграфы определены как 16px Helvetica, несортированный список немного уменьшен до 14px и h1 увеличен до 24px Georgia. Сексуальненько? Нет?
И что вдвойне сексуальненько, это то, что одно простое правило позволяет нам получать все это сразу:
  1. body{
  2.     font: normal 100% Helvetica, Arial, sans-serif;
  3. }

С размером шрифта 100%, размер всех элементов на нашей странице определен относительно установленного в браузере по умолчанию размера шрифта, который в большинстве случаев 16px. Благодаря таблице стиле браузера, h1 большой, полужирный, красивый — но все еще Helvetica и слишком большой. Для того чтобы решить проблему достаточно просто с помощью font-family убрать Helvetica, но как изменить размер шрифта текста до 24px? Или точно уменьшить размер шрифта списка?
С em это сделать просто. Мы берем целевое значение font-size для каждого элемента и делим на размер шрифта (font-size) его контейнера (это и есть его контекст). В результате мы получаем желаемый размер шрифта (font-size) выраженный в относительных единицах (em). Или, короче говоря:

target ÷ context = result

Если предположить, что размер шрифта тега body по умолчанию 16px, мы можем описать этой формулой любое нужное нам значение размера шрифта (font-size). Так что, чтобы получить требуемое соответствие размера заголовка нашим вычислениям, мы делим целевое значение (24px) на размер шрифта (font-size) контейнера (16px):

24 ÷ 16 = 1.5

Заголовок в 1,5 раза больше размера шрифта body, или 1,5em, и это значение мы можем внести в таблицу стилей.
  1. h1 {
  2.     font-family: Georgia, serif;
  3.     font-size: 1.5em;        /* 24px / 16px = 1.5em */
  4. }

Что бы перевести размер списка в em эквивалент 14px, мы можем использовать ту же формулу. Предполагая, что размер шрифта (font-size) строго 16px, мы просто делим целевое значение на его контекст.

14 ÷ 16 = 0.875

И получаем значение 0.875em, которое, опять-таки, можно внести в CSS.
  1. ul {
  2.     font-size: 0.875em;      /* 14px / 16px = 0.875em */
  3. }

С этими двумя правилами страничка с примером выглядит много ближе к запланированной и будет практически идеальной после простеньких дополнений. И все это с помощью формулы target ÷ context = result.
Так что после нескольких часов проведенных за разгребанием размеров я осознал, что спотыкаюсь об ответ. Если мы можем рассматривать размер шрифта не как пиксели, а как пропорцию, вычисленную относительно контейнера, то тоже самое можно применить и к другим элементам сетки.

В конце-концев, это не «Золотой Пиксель»


Как и ранее, давайте начнем с четкой несексуальненькой простой разметки:

image
Наша базовая разметка

Конечно, наш «дизайн» довольно скромненький. Но простые стили наложены на четко определенную сетку: точнее, семь колонок по 124px каждая, разделенные 20px пробельным материалом, и все это вместе имеет ширину 988px. Но давайте забудем об этих мерзостных пикселях. Пропорции — наше все, да? Даешь «резину», детка!

image
Наша базовая разметка с наложенной поверх нее сеткой

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

image
Определяем информационные блоки.

На самом высоком уровне у нас есть заглавие вверху страницы, информационная область, которая растягивается на шесть колонок и некая зависимая от контекста информация в самой левой колонке. Из этой схемы мы можем выделить скелет разметки, который соответствует нашему информационному множеству и с точки зрения структуры и с точки зрения семантики:
  1. <div id="page">
  2.     <h1>The Ratio Revolution Will Not Be Televised</h1>
  3.  
  4.     <div class="entry">
  5.         <h2>Anyone else tired of Helvetica?</h2>
  6.  
  7.         <h3 class="info">A <a href="#">Blog</a> Entry:</h3>
  8.  
  9.         <div class="content">
  10.             <div class="main">
  11.                 <p>Main content goes here. Lorem ipsum etc., etc.</p>
  12.             </div><!-- /end .main -->
  13.  
  14.             <div class="meta">
  15.                 <p>Posted on etc., etc.</p>
  16.             </div><!-- /end .meta -->
  17.         </div><!-- /end .content -->
  18.     </div><!-- /end .entry -->
  19. </div><!-- /end #page -->

И, применив некоторые правила типографики, мы получаем прилично выглядящую точку отсчета. Однако, контейнер (#page) не содержит никаких ограничений, так что наше информационное наполнение будет сформировано таким образом, чтобы соответствовать ширине окна браузера. Давайте попробуем проконтролировать длину строк:
  1. #page {
  2.     margin: 40px auto;
  3.     padding: 0 1em;
  4.     max-width: 61.75em;      /* 988px / 16px = 61.75em */
  5. }
  6.  

Мы использовали margin и padding, чтобы внести ограничения и получить пробельный материал между информационным наполнением и границами окна. Но последняя строчка нашего правила использует разновидность нашей формулы (для расчета font-size) для определения максимальной ширины нашего дизайна. Разделив ширину макета (988px) на базовый размер шрифта (font-size) (16px) мы можем установить максимальный размер в em для определения приблизительного соответствия пиксельной ширине нашего макета, что предотвратит увеличение размера макета сверх идеальных 988px. Но так как мы используем em для определения максимального размера, то максимальная ширина (max-width) будет масштабироваться, если пользователь увеличит размер шрифта в браузере – модный маленький приемчик, который работает даже в старых версиях IE, если применить маленький CSS хак.
Теперь, когда наш дизайн соответствующим образом ограничен, давайте поработаем с каждым элементом нашего дизайна отдельно, начиная с заголовка страницы. В макете он занимает пять колонок и четыре пробельных материала, общей шириной в 700px. Так же он отделен от левой границы страницы одной парой колонка/пробельный материал, что дает милый отступ в 144px. И, если бы мы работали с дизайном фиксированной ширины, наша работа была бы достаточно прямолинейна:
  1. h1 {
  2.     margin-left: 144px;
  3.     width: 700px;
  4. }

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

Все новое — хорошо забытое старое


Так с чего начать то?

target ÷ context = result

Правильно: возвращаемся к нашей формуле расчета размера шрифта. Мы можем использовать туже пропорцию для преобразования ширины колонки в пикселях в определенные в процентах, гибкие значения. Так что мы, отталкиваясь от целевых 700px, для получения размера заголовка в процентах — но контейнер заголовка имеет размер 988px;

image
Преобразуем значение размера заголовка в пикселях в проценты.

В результате, мы просто делим 700px (наше целевое значение) на 988 (его контекст (размер контейнера заголовка)) вот таким образом:

700 ÷ 988 = 0.7085

И вот: 0.7085 превращается в 70.85%, ширину, которую можно заносить в таблицу стилей:
  1. h1 {
  2.     width: 70.85%;           /* 700px / 988px = 0.7085 */
  3. }

А можно тоже сделать с отступом в 144px? Обожаю наводящие вопросы:

144 ÷ 988 = 0.14575

И снова, мы берем 0.14575, или 14.575%, и добавляем в нашу таблицу стилей в качестве значения margin-left для заголовка:
  1. h1 {
  2.     margin-left: 14.575%;    /* 144px / 988px = 0.14575 */
  3.     width: 70.85%;           /* 700px / 988px = 0.7085 */
  4. }

И voilà. Измерив отступ заголовка и ширину относительно контейнера, мы успешно перевели пропорцию нашей сетки в проценты. Пропорции заголовка всегда останутся верными, даже если он масштабируется, чтобы соответствовать размеру окна браузера.
Мы можем применить столь же простое преобразование для определения относительных размеров блока, содержащего основное информационное наполнение, он обладает размером 844px и отступом слева 124px шириной. То есть:

844 ÷ 988 = 0.85425

И для информационной колонки:

124 ÷ 988 = 0.12551

Эти два преобразования дают нам значения в процентах, которые мы можем внести в таблицу стилей и сделать нашу разметку еще более гибкой.
  1. .entry h2,
  2. .entry .content {
  3.     float: right;
  4.     width: 85.425%;          /* 844px / 988px = 0.85425 */
  5. }
  6.  
  7. .entry .info {
  8.     float: left;
  9.     width: 12.551%;          /* 124px / 988px = 0.12551 */
  10. }
  11.  

И таким образом продвигаемся на шаг вперед в получении «резины».

Изменяем контекст


Пока что мы позиционировали основные информационные блоки, но их содержимое не трогали. Сейчас элементы наполнения блога занимают всю ширину и расположены один над другим. Но мы планировали, что основной элемент наполнения занимает только пять колонок и дополнительной информация должна быть расположенна в самой правой колонке.
Внимательные читатели заметили, что текущая ширина информационного контейнера в основном блоке такая же, как ширина заголовка (700px), И сдвиг такой же как у самой левой колонки, стили для которой мы подготовили ранее, (124px). Так что мы продолжаем работать с размерами, которые уже рассчитали, но мы не можем использовать те же формулы: изменился контекст.

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

Тогда как ранее мы вычисляли процентное отношение относительно ширины 988 px контейнера #page, сейчас мы работаем с контейнером .entry .content, который значительно меньше. В результате нам надо изменить наш контекст и использовать ширину .entry .content как точку отсчета. Так что, чтобы определить основанную на процентах ширину элемента «main copy» мы берем его ширину (700px) и делим на ширину родительского контейнера (844px)

700 ÷ 844 = 0.82938

И для нашей правой колонки, 124 пикселя шириной, мы можем использовать ту же точку отсчета.

124 ÷ 844 = 0.14692

Теперь мы можем взять результаты этих вычислений и внести их в CSS:
  1. .entry .main {
  2.     float: left;
  3.     width: 82.938%;          /* 700px / 844px = 0.82938 */
  4. }
  5.  
  6. .entry .meta {
  7.     float: right;
  8.     width: 14.692%;          /* 124px / 844px = 0.14692 */
  9. }
  10.  

Собственно, на этом работа закончена, «резина» закончена.

Заключение


Как можно предположить из отсутствия хаков в CSS, у меня было почти не было проблем с кросс-браузерностью. Очень рекомендую статейку Джона Ресига (John Resig) на тему суб-пиксельных проблем в CSS. Она объясняет как различные браузеры обрабатывают ширину указанную в процентах и механизм, с помощью которого согласовываются суб-пиксельные измерения.
Как Джон объясняет в своей статье, если современные браузеры работают с четырьмя элементами 25% ширины в контейнере шириной 50px, они не могут отрисовать элементы 12.5 пикселей шириной; вместо этого большинство браузеров округлит ширину колонки до большего или меньшего целого для наилучшего соответствия разметке. Internet Explorer, как всегда, просто округляет до большего целого, что разрывает разметку.
Если вы работаете с достаточно общими отступами в вашей сетке, это не проблема. Но если IE вызывает нежелательные разрывы в разметке, перенося колонки с шириной указанной в процентах, может помочь уменьшение на один пиксель целевой ширины. Так что, если, например, наш левый отступ слишком велик для IE, можно изменить расчет с:

124 ÷ 988 = 0.12551

на меньшую ширину 123px:

123 ÷ 988 = 0.12449

Внесите ширину 12.449% в таблицу стилей специфичную для IE и все будет в порядке.

Сетка на все случаи жизни


Все вышесказанное, конечно, просто отправная точка: есть мириады проблем, которые поджидают верстальщика, работающего с «резиной», большинство из которых возникает при работе с информационным наполнением фиксированной ширины (Изображения, Flash и тому подобное) в контексте «резины». Я экспериментировал с возможными решениями в моем блоге, но идеальных решений пока нет.
И, наконец, я не говорю, что верстка это просто, не важно, фиксированная разметка или «резина». Но осмотрев то, чего мы достигли за последние несколько лет — отказ от таблиц, возведение в наших компаниях и общей профессиональной области стандартов до уровня святыни, добиваемся лучших стандартизации браузеров и мне бы хотелось чтобы мы применили часть нашей находчивости, чтобы разорвать зависимость от «минимального разрешения экрана». В конце концов, привычки веб-серфинга наших пользователей не так предсказуемы, как мы можем предположить. Я надеюсь возможности «резины» зажгли ваше воображение, я с радостью посмотрю на ваше применение этой техники. Так же как и наши пользователи.

Дополнительная литература


Как вы мо
Перевод: Этан Маркотте (Ethan Marcotte)
Антон @SilentImp
карма
134,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • –2
    Ничего нового, но как напоминание вполне себе.
    • +6
      Знаете, возможно, это покажется вам странным, но я очень рад, что все, что тут написано, вам не в новинку.
  • +6
    По-моему, какая-то несексуальная вода, читается сложно.
    • +1
      Старался перевести как можно лучше. Но… может быть тут моя вина. Извините, если что не так.
      В принципе — ничего сложно. Собственно, все сводится к пониманию того, что такое em. Зато с примерами и по полочкам.
      • +1
        Дело не в переводе… Пугают формулы… наверное…
        Но на сколько я знаю, у буржуев сайты модно делать фиксированной шириной.
        А у нас заказчики любят заказывать на весь экран. При чём никто из них не может обычно предоставить контент приличный… И получаются пара строк вверху экрана на всю ширину… И картинка подвешенная в пустоте…
        • +1
          Что в очередной раз доказывает, что max width имеет право на жизнь.
          В относительных ли она единицах или нет.
  • +4
    А как по мне, так образцовая статья! Замечательно все расписано, последовательно и хорошо, с примерами, с пояснениями, просто замечательно!
    В избранное, однозначно.
  • НЛО прилетело и опубликовало эту надпись здесь
    • –1
      Ну, по сравнению с ieee'шными статейками, например — все просто, понятно и без утайки.
      Расписали хоть какой то момент толково — и то хорошо.
    • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    но написать что-то ведь надо, иначе как напомнить о себе?
    А могли бы и поблагодарить за грамотную статью, которых на русском языке вы вряд ли видели…
    • 0
      englishextra, кажется, имел ввиду не переводчика, а автора.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    нечитабельно %(
    увы всем
    статья хорошая, но в этом переводе на русском читается трудно, жаль
    • 0
      Ну… как смог. В следующий раз будет лучше.
  • 0
    А не подскажите, как это на сайте автора, лого сжимается при уменьшении окна?

    За перевод спасибо, я многое узнал.
    • +1
      Логотип это тег:
      Unstoppable Robot Ninja
      На нем стиль:
      max-width:100%;
      При уменьшении размера контейнера уменьшается ширина изображения.
      Кажется так.
      • 0
        Тег img порезало…
        <img alt="Unstoppable Robot Ninja" src="/-/img/logo.png"/>
      • 0
        Спасибо, теперь догнал, получается, что ресайз изображения происходит за счет браузера отталкиваясь от max-width:100%? Хм… здорово.

        Решил изучить верстку его блога, и никак не догоню зачем нужна такая вложенность в шапке, вернее понимать понимаю, но зачем так мусорить:

        -cite
        ---strong
        ------b
        ---------img
    • +1
      У непобедимого робота-ниндзя есть статейка на эту тему:
      unstoppablerobotninja.com/entry/fluid-images/
      • 0
        Еще раз спасибо, я пока с английским не дружу, поэтому не увидел
  • 0
    На самом деле статья действительно «переизложенная» на мой взгляд. Я её тоже хотел было перевести, но что-то не сложилось (и слава богу, а то бы вдвоём перевели :) ). Если к статье применить мудрое правило «выброси половину слов» — информационная ценность совершенно не изменится. Не знаю как у буржуев, но у нас многие привыкли суть улавливать на лету, читая по диагонали даже иноязычные тексты, не то что наши родные. Поэтому чем больше воды — тем более усложняется восприятие.

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

    Спасибо за труд, с интересом перечитал еще раз ;)

    • 0
      Пожалуйста. Рад, что он может быть полезен.

      Правда считаю, что перевод должен быть близок к тексту, по возможности.
      Иначе это уже не перевод, а реферат.
      Естественно, рефераты имеют право на жизнь и, иногда, намного полезнее переводов.
      Но все-таки это — перевод.

      А что касается того, что у нас все схватывают на лету — это очень индивидуально.
      Мне, иногда, очень не хватает статей, в которых все разложено по полочкам и проиллюстрировано пошагово комментированными примерами.
      • 0
        К сожалению, лентяям не нравится читать много непонятного текста. Им нравится бездумно копировать код и не вникать «для чего и почему надо сделать именно так и никак иначе». Мне понравилась статья. Спасибо за немалый труд!
  • 0
    Хорошая статья, но читал фрагментами. Сократить бы, как уже выше говорилось)
  • +3
    pxtoem.com/
    Лентяям.
  • 0
    не по теме: прочитав только над хабракатом — глаза заболели от ряби. к чему столько ссылок? вот к чему, ответьте?
    • 0
      Это перевод. Ссылки были там, где их использовал автор.
      Он, похоже, хотел проииллюстрировать фреймворки и инструментарий работы с ними, потому что фреймворки, по его мнению, облегчают работу с сеткой (я не люблю CSS фреймворки и не согласен), упомянул людей, которые обладают значением в области использования типографской сетки в вебе, да пару тематических статеек привел.
      Не особенно лишняя информация. Мне пройтись по этим ссылкам было интересно.
      • +1
        Мне в этом смысле стало интересно зачем вы HTML-разметку нашпиговали ссылками, а особенно — зачем ссылки в закрытывающих тэгах? Этих ссылок уж точно нет в оригинале, предполагается, что читатели хотя бы начального уровня, а не нулевого :)
        • –1
          Эм, единственные ссылки, которых нету в оригинальном тексте:
          1. ссылка на мой профиль, в соответствующем разделе.
          2. ссылки которые добавил «code hightlighter». Правда в данном случае я выбрал его не совсем удачно — что то он толком ничего не подсвечивает. Может перебрать статью и код обработать другим hightlighter'ом? Как вы думаете?

          /me в задумчивости.
          • 0
            Думаю не стоит — код в статье достаточно прост и понятен и без подсветки.
            А чем пользовались для подсветки кода, интересно? Он что — сам ссылки расставляет на справочник по тэгам?
            (кстати на хабре вроде как принято ставить ссылку на то, чем раскрашивали, да и автору использованного сервиса таким образом стоит сказать спасибо, если конечно это не ваша собственная разработка)
            • 0
              Попробовал quickhighlighter.com/
              Хабр его стили порезал.
              В html'ке он смотрелся нормально.
              Да, он сам расставляет ссылки.
              Я к этому непричастен.

              По поводу ссылок — не знал. Исправлюсь.
  • 0
    O CSS — почему бы не делать отступы, в нём согласно включаемости элементов в самом документе? Так будет понятно без просмотра остального кода, для чего куда float происходит.
    • –1
      Честно говоря, не очень понял, о чем вы… Наверное спать пора.
      • 0
        Это я смотря на последний исходный код подумал, что в CSS только один отступ используется (для параметров), а если использовать отступы кода как в самом HTML, то будет видно, что в каком контейнере находится, ведь отсчёт размеров ведётся как раз относительный.
        • 0
          Эм… так это ведь правила. У них нет вложенности.
          • +1
            Да, но в обычных правилах (сайта, заведения и т.п.) при сложной структуре делают нумерацию не одноуровневым списком, а с подпунктами. Так и тут через только лишь отступы можно показать, из каких предыдущих правил наследуются параметры, а с какими пересекаются.
            • –1
              А где можно увидеть пример такого чуда?
              Поделитесь, пожалуйста.
              Я, просто, пока не очень понимаю, как это должно выглядеть.
      • 0
        Да тоже вот спать собирался, но тег за тег, и так всю статью с примерами дочитал и засмотрел, затянуло =)
  • –2
    не, это фиговая резина ;-) при низких разрешениях ширины колонок должны исходить не из эталонных соотношений, а от объёма контента. именно так ведут себя таблицы — изменяют ширины колонок, чтобы контент не обрезался.
    • –1
      Гм. min width, max width дейсствительно бы не помешали.
      Что касается фразы «что бы контент не обрезался»— было бы здорово, если бы вы ее прокомментировали.
      Что значит «обрезался» и как это определить из CSS?
      • –1
        Тоесть надо, что бы нарушалось соотношение ширины колонок в зависимости от того есть ли там информационное наполнение? А как же типографская сетка? Она улучшает читабельность…
        • 0
          если там длинное слово или большая картинка, то сетка идёт лесом =)
          тут есть три стратегии: обрезать всё, что не влезает в колонку, допускать вылезание контента в соседнюю колонку и увеличивать ширину колонки.
          • +1
            1. Или снова вспомнить про «маленькую ложь» и все таки определить минимальную и, возможно, максимальную ширину.
            2. Картинки тоже можно масштабировать. Смотри статейки на сайте робота-ниндзя :)
            3. Что за слово такое, которое может разбить сетку!?

            В статье рассмотрен тривиальный случай, в котором, просто показан и расписан «от» и «до» принцип работы с относительными единицами измерения. В послесловии написано, что масса проблем не освещена. И приведены материалы для дополнительного чтения.
            • 0
              1. тогда смысл статьи теряется. не правда ли? %-)
              2. без привлечения яваскрипта — нельзя. попробуй пропиши картинке ширину и высоту, а потом задай wax-width. это касательно контентных картинок. ещё есть кнопки там всякие, селекты и прочие контролы, которые тоже не умеют масштабироваться, да и в общем-то не должны…
              3. ru.wikipedia.org/wiki/%D0%A1%D0%B0%D0%BC%D0%BE%D0%B5_%D0%B4%D0%BB%D0%B8%D0%BD%D0%BD%D0%BE%D0%B5_%D1%81%D0%BB%D0%BE%D0%B2%D0%BE_%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%BE%D0%B3%D0%BE_%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0

              убейте меня. я не хочу редактировать вёрстку, где всё задано в относительных единицах. это ж убиться можно — вручную пересчитывать все эти формулы и постоянно огребать проблемы при перетасовке элементов.
              • 0
                1. Не правда. «Резина» остается. Но всегда надо исходить из здравого смысла.
                2. Почитай статью, о которой говорил. И сам сайт посмотри.
                3. Не хочешь — не редактируй. Но ты забоишься о том, что бы не переработать, не дай бог, а не о том, что бы верстка была хорошей.
                • 0
                  >попробуй пропиши картинке ширину и высоту, а потом задай wax-width.
                  Хоть убейте, не могу понять зачем кому то может понадобится определять размер картинки, представленной тегом img, в абсолютных величинах.

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

                  И, кстати, использование js не является смертным грехом.
                  Особенно если нормально реализована «graceful degradation» странички.
                  • 0
                    мдя, нахватался умных слов, а азов не знаешь… габариты обектов нужно указывать, чтобы контент не скакал по мере загрузки страницы.
                    • 0
                      Спасибо за ликбез.
                      Про скачущий контент я никогда не думал.
                      Но даже если так: габариты объекта, который должен изменять размер, не обязательно должны быть указаны в абсолютных единицах.
                      • 0
                        а в каких же ещё? XD
                        а в каких же ещё? XD
                        • 0
                          Проценты, em, pt.
                          • +1
                            я тебе щас врежу бля!
                            em — при изменении размера шрифта картинка тоже начнёт деформироваться.
                            pt — те же пиксели, но другой формы.
                            • +1
                              хера о_0 шо это было?

                              % — не помогут для задания высоты картинки.
                            • +1
                              tenshi не нервничай.
                              Как только освобожусь — поэксперементирую.
                              И либо соглашусь либо нет.
                              А то что то потеряна конструктивная искра.

                              Про pt — никогда их не испльзовал, если честно. Посмотрел в спецификации. Ты прав, а я — нет.
                              • 0
                                я не нервничаю =) незнаю откуда та строчка взялась XD
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • 0
                              неа, пункты зависят от расстояния до глаз.
  • 0
    ALA пишут хорошие вещи, теперь не могу определиться, на каком языке читать было проще и интереснее, автору перевода большое спасибо
    • +2
      Спасибо за добрые слова.
      Очень рад, что перевод понравился.
  • +1
    Отличная статья. Спасибо за перевод.
  • +1
    Кто то минусовал все без исключения.
    Что бы это могло значить?
    • +2
      1) Не обращайте внимания на такие вещи, идиотов на хабре полно, просто в силу IT-направленности ресурса, процент идиотизма немного ниже, чем везде.

      2) Забейте на комментарии типа «Боян», «Это мы уже видели» и прочее гумно — да, они это видели, ну и что? Это считанные единицы, которые все знают, и все умеют. Подумайте об остальных 99% верстальщиков, особенно начинающих, которых уже сейчас можно пойти и потыкать мордой в вашу статью, чтобы хоть немного повысили свой уровень, без тупых оправданий «я низнаю онглиске!»
  • +1
    Для начинающих — самое то. Одно время долго не мог вкурить как высчитывать em
  • 0
    Больно уж режет глаз:
    Что бы -> Чтобы
    • 0
      Спасибо. Поправил.
  • +1
    Куда-то часть материала пропала, в конце в районе дополнительной литературы.

    А статья вполне себе жизнеспособна и читабельна, не верьте завистникам :) Удачи
    • +1
      Сейчас поправлю.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Использую Fluid 960 Grid System. В целом впечатления хорошие.
  • 0
    всё бы хорошо, по сталкивалась с тем, что опера округляет проценты, то биш берёт только целую часть. потому предполагаю, что сетка может поехать, если все ширины указывать в процентах
    • 0
      хм, хотя туплю, если всё-всё будет резиновое, то и нормально получится)))

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