Языковой барьер

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

Как и следует ожидать, попытка сверстать такую же точно обычно не приводит к успеху. Ни за 10 минут, ни за час. Что дает повод консерваторам учинять шумные показательные торжества.

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

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

И подобно тому, как одну и ту же мысль можно сформулировать многими различными способами, существует великое разнообразие вариантов представления одного и того же контента. Что великолепно демонстрируется, например, создателями сайта CSS Zen Garden.

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

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

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

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

А если все-таки посмотреть на проблему с другой стороны? Выскажу крамольную мысль. Как мне кажется, считать или не считать отмеченное явление недостатком блочной модели — вопрос далеко не столь определенный и однозначный. Я уже неоднократно приводил в пример главную страницу сайта W3C, где используется верстка в три колонки. Заметьте, никаких попыток уравнять высоту колонок там не прослеживается. Полагаю, что с точки зрения логики и здравого смысла вполне естественно, когда размер того или иного блока определяется количеством контента в нем. Мы просто слишком долго мыслили категориями colspan/rowspan, но эта привычка во многом порочна. Веб-страница — ведь это не журнальная полоса, где объем каждой колонки строго фиксирован. Тогда зачем, спрашивается, искусственно усложнять действительность?..

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

Но позвольте! Какой смысл в обсуждении экстремальных случаев: мол, а что будет, если сжать окно браузера до 200 пикселей в ширину? А если еще и шрифт при этом увеличить до 100 пикселей? Так ли уж важно все это для страницы, рассчитанной на минимальный комфортный размер окна, скажем, 800×600 пикселей? Боюсь, что ни табличный, ни блочный макет, предназначенный для отображения на больших экранах настольных компьютеров или ноутбуков, не будет выглядеть гармонично и сбалансированно в таких вот стесненных условиях. Для маленьких экранов мобильных устройств — карманных компьютеров или смартфонов — обычно предусматривается обособленная версия оформления.

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

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

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

Резюмируя вышесказанное. Не подумайте, что я настаиваю на том, будто бы блочная модель CSS2 совсем лишена недостатков. В таком случае просто никто не занимался бы разработкой CSS3. :-)