От оформительских трюков к стандартам

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

Мы решали одни проблемы, вместо них возникали новые. Netscape 4 игнорирует декларацию CSS {margin: 0;} ? Пригласим в тэг BODY "Четырех Всадников, Которые Никогда Не Пройдут Валидацию": LEFTMARGIN, TOPMARGIN, MARGINWIDTH, MARGINHEIGHT. IE4 не полностью поддерживает свойства границ? Сымитируем эти свойства с помощью вложенных таблиц. Вроде бы это не должно работать - но работает. Да и сайт должен был быть готов еще вчера. Что нам стоит дом построить? Нарисуем, будем жить.

Где мы были

Именно так конструировались сайты, начиная с 1995 года, и точно так же они строятся в наши дни. Это запутанное и утомительное занятие, недостаток логики в котором привел к возникновению рынка визуальных редакторов кода, наподобие Dreamweaver, GoLive и FrontPage. В то время как мы, пишущие код вручную, дико гордились собой. Гордились не качеством нашей работы, не соответствием стандарту, но неким высшим знанием того, какой нестандартный тэг или фрагмент на javascript решает ту или иную проблему отображения кода в том или ином идиотском броузере.

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

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

Куда мы идём

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

Все мы знаем, что новейшие броузеры более или менее поддерживают веб-стандарты. IE5, Netscape 6, и Opera 5 предлагают поддержку CSS, HTML, и JavaScript/ECMAScript вполне достаточную для того, чтобы мы могли позволить себе отказаться от неуклюжих и устаревших методик и освободить сеть от оков табличного HTML-дизайна.

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

Долгая дорога

Здесь, на ALA, я принял решение поддерживать стандарты (в том числе и W3C DOM), несмотря на то, что в старых броузерах такой ход неминуемо приводит к некачественному отображению. Это решение далось мне нелегко, но когда я его принял, оно воплотилось с неизбежностью падающего сейфа.

Это была долгая дорога.

Для меня это путешествие началось в 1997, когда Matt Haughey и я независимо друг друга составляли хронику ошибок реализации CSS в Internet Explorer 3. Или, может быть, в 1998, когда Glenn Davis отправил мне письмо, которое и привело к созданию объединения The Web Standards Project (WaSP).

Разговоры

Вернемся от древней истории к событиям месячной давности, когда Emily Cotler и Kelly Goto в процессе подготовки своей книги по веб-дизайну спросили меня, какое влияние оказывают стандарты CSS, HTML и XHTML на задачу обновления сайта и смены его дизайна.

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

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

Как было бы здорово...

Каждую неделю, когда я и Nick выпускали новый номер, я замечал некоторые недостатки в существующей верстке и по возможности вносил косметические изменения, улучшая оформление недельного номера, в то время как остальной сайт оставался неизменным. Если проследить историю ALA - можно увидеть, что, по мере развития, сайт становился все более и более уродливым, сложным для чтения и неудобным в использовании.

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

Как всё начиналось

Затем мне написал разработчик броузеров - разумный, хорошо понимающий в стандартах парень, чей продукт первым стал правильно поддерживать CSS-1. Он задал мне только один вопрос: почему ALA не полностью поддерживает веб-стандарты?

"Уж кто-кто, а Ваш сайт должен следовать правилам" - мягко пожурил он меня.

Несколько дней спустя B.K. DeLong из WASP реанимировал идею, которую в свое время предложила Dori Smith: я говорю об Инициативе по обновлению броузеров.

Простая идея

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

Опасный бизнес

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

Я решился.

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

В бездне

Эти двое смелых - эксперты по CSS, непосредственно участвовавшие в создании стандартов. Так как они пожелали остаться неизвестными, я назову их Анонимный Донор #1 и Анонимный Донор #2.

Позже к нашей банде авантюристов присоединился David Eisenberg из ALA. Он занимался кросс-платформенными тестами и, в соответствии с их результатами, вносил тщательно обдуманные изменения в нашу таблицу стилей.

Стандарты против стандартов

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

Буква

Веб-сайт WaSP, например, всегда соответствовал стандарту и всегда использовал CSS для контроля над типографикой. Верстка, тем не менее, была реализована с помощью HTML-таблиц, дабы сайт работал в любом визуальном броузере. Преимущества такого подхода: как я уже только что сказал, ресурс отображается в любом броузере. Недостатки:

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

2. Такой подход к верстке не имеет смысла в нетрадиционных (например, речевых) броузерах и, по мнению W3C, вреден - даже если страница проходит валидацию.

3. Страницы с такой версткой менее доступны людям и устройствам.

Дух

Резиновый завтрак

<!-- Dress left --&rt;
<table border="0" cellpadding="0"
cellspacing="0"&rt;
<!-- Your variable left margin --&rt;
<tr valign="top"&rt;
<td width="15%" bgcolor="#ffffcc"&rt;
&nbsp;</td&rt; <td width="75%" bgcolor="#ffffcc"
valign="top"&rt;
<!-- Your actual content --&rt;

Будьте добры - то же самое, но на человеческом языке. Я рыдал, как ребенок, при одной мысли о том, что можно заменить безумное количество таблиц на два-три чистых и незамысловатых DIV'а.

Обдумываем разметку

ТРЕХПАНЕЛЬНАЯ ВЕРСТКА В CSS

Я быстро решил, что в верхней оранжевой панели с названием не было и нет никакой необходимости. С настоящего момента название вполне можно поместить в панель с контентом. Откровенно говоря, создание трехпанельной верстки в CSS казалось практически неосуществимым, так как подобные возможности только планируются для CSS-3 (вообще-то трехпанельная верстка относительно просто реализуется и в CSS, как видно из примеров Porter Glendinning и вашего покорного слуги. Но в то время, когда ALA переживал первую смену дизайна, проблемы выглядела неразрешимой).

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

Смена дизайна: теперь об этом можно рассказать

.content {width: 75%; padding-left: 10%;
padding-right: 10px; padding-top: 10px;}

Этот слой занимал 75% от всей ширины страницы, плюс небольшой отступ для создания пространства между границей слоя и текстом. В то же время, слою с меню было предназначено занимать остальные 25% ширины (и 100% по высоте страницы).

.menu {position: absolute; left: 75%;
top: 0px; height: 100%; width: 25%;
margin: 0; padding-left: 15px;
padding-right: 10px; padding-top:
10px; background-color: #cc00000;
background-image:
url(backgrounds/striperight.gif);
font: 10px/14px geneva, arial,
helvetica, sans-serif; color: black; }

В IE5/Windows это работало так, как я и ожидал. Но в броузерах, которые, как я полагал, куда лучше поддерживали стандарты, нежели IE5/Win, я получил горизонтальные и вертикальные полосы прокрутки (и вы их увидите в IE5/Mac, Netscape 6, и Opera 5).

Что стряслось? 100% высоты - это 100%, не так ли? 75% плюс 25% все еще равно 100%, правда? Почему эти броузеры так странно ошибаются?

Ответ, разумеется, состоял в том, что они ни в чем не ошибались. Ошибся я, потому что неверно понимал блочную модель CSS (равно как и IE5/Win).

Блочная модель без маски

<!DOCTYPE HTML PUBLIC "-
//W3C//DTD HTML 4.01 Transitional//EN">

<!DOCTYPE HTML PUBLIC "-
//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/
1999/REC-html401-19991224/loose.dtd">

{width: 75% И ПРОШУ
НЕ ОБРАЩАТЬ ВНИМАНИЯ НА ОТСТУП}