Сборно-панельный сайт

Однако вернемся к HTML. Поскольку в случае этого языка одна и та же технология ответственна за оба аспекта разметки, необходи­мо придерживаться определенных правил, которые позволят

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

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

• Экземпляры одного блока должны быть абсолютно иден­тичны, за исключением вставок изменяемого содержи­мого (например, текста заголовка в блоке заголовка).

• Общее количество разновидностей блоков должно быть минимальным, и после того как дизайн сайта устоялся, новые блоки могут вводиться в виде исключения — только когда на сайте появляется принципиально новое содержимое, не лезущее в старые «болванки».

• За пределами блоков не должно оставаться никаких «висячих» тегов, за исключением самых необходимых средств оформления текста (тег Р и логические теги типа ЕМ и STRONG).

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

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

Рис. 1

«Модульная» стра­ница на сайте www.oi.com

Наоборот, редактирование «плана представления» после то­го, как сайт создан и запущен, в идеале должно быть событием исключительным, осуществляющимся только под контролем дизайнера. (Например, если вдруг выяснилось, что какой-то заголовок ведет себя неправильно, когда его текст превышает по длине некую заранее планировавшу­юся величину, может понадобиться изменить устройство заголовочного блока.) Это можно делать только глобаль­ным поиском и заменой во всех файлах сайта — ведь если вы поправите вручную одну из копий блока, ее уже не найдет следующий автоматический поиск, и рассинхронизация поползет по сайту, как раковая опухоль. Программа, которой вы пользуетесь для редактирования HTML-кода, должна уметь искать и заменять многостроч­ные блоки текста и пользоваться регулярными выражениями (regular expressions) в тех случаях, когда блок содержит встав­ки, изменяющиеся от одной копии блока к другой. Обе эти возможности поддерживает, например, редактор HomeSite (www.aliaire.com).

Например

Описанные выше принципы были взяты за основу в дизайне сайта www.oi.com (рис. 1). Этот корпоративный сайт по объему и ча­стоте обновления своего материала близок к контент-сайтам (стр. 182), и возможность свободно редактировать содержимое, оставляя нетронутым дизайн, для него особенно важна. Вот, к примеру, как выглядит блок, со­здающий стандартный внутритекстовый заголовок:

<!-- trained heading -->

<table border=0 cellpadding=0 cellspacing=0><tr>

<td bgcolor=ffaf60><img alt="" src="e.gif" width=15 height=4></td>

<td bgcolor=ffaf60><img alt="" src="e.gif" width=350 height=4></td>

<td bgcolor=d8d8d8 align=right valign=top rowspan=2>

<img width=16 height=26 alt="" src="zak-gob.gif "></td>

</tr><tr>

<td bgcolor=d8d8d8><img alt="" src="e.gif" width=15 height=22></td>

<td bgcolor=d8d8d8 valign=bottom><small>THE COAD METHOD</small></td>

</tr></table>

В начале блока ставится комментарий-идентификатор, а в предпоследней его строке мы видим единственный фрагмент, изменяющийся от одного заголовка к другому, — его текст (в данном случае «THE COAD METHOD»). Между собой блоки удобно разделять пустыми строками. Вся страница, показанная на рис. 1, состоит из следующих блоков (приведены только строки с комментариями):

<!-- top navigation -->

<!-- solid heading -->

<!-- open text block -->

Peter Coad is perhaps... Reach him at pc@oi.com.

<!-- close text block -->

<!-- framed heading -->

<!-- open text block -->

The Coad Method focuses on... frequent, tangible, working results. <!-- close text block --> <!-- decorated close -->

Модульный HTML — не только имитация имеющегося в других языках программирования структурного подхода и не только единственная реальная возможность приспосо­бить этот язык к созданию объемных и часто обновляемых сайтов. Это еще и необходимый промежуточный этап бу­дущей миграции к языку XML (о котором мы будем говорить чуть ниже): тем же самым глобальным поис­ком вы в любой момент можете заменить «псевдотеги» структурных блоков HTML на настоящие структурные те­ги XML, разработав для них соответствующие стилевые спецификации. Такая конверсия гораздо полнее отвечает целям и духу XML, чем приходящий в голову первым буквальный, «тег в тег» перевод HTML в формально кор­ректный, но совершенно бессмысленный XML (стр. 51), — ведь большинству визуально-ориентированных тегов HTML в структурном языке XML нет и не может быть никаких соответствий.

XML

Как мы только что видели, модульный подход позволяет достичь в HTML определенной ортогональности структуры и представления. Конечно, гораздо удобнее было бы хранить повторяющиеся блоки визуального кода в отдельном, общем для всего сайта «стилевике», а документы размечать только ссылками на тот или иной блок — то есть, по сути, тегами логической разметки, говорящими лишь о том, что стоит в данном месте документа, а не о том, как оно выглядит.

Именно такое естественное, а не насильственно наса­ждаемое разделение аспектов содержания и представления предлагает язык XML (extensible Markup Language, «Расши­ряемый язык разметки») — компактное упрощенное под­множество языка SGML, разработанное Консорциумом W3 в расчете на постепенное вытеснение из Интернета языка HTML. Этот «HTML будущего», как его нередко называ­ют, уже активно осваивается ведущими производителями

программ, причем не только броузеров — вероятно, под­держка XML через какое-то время появится в большинстве текстовых процессоров, баз данных, систем подготовки документации, а некоторые предрекают встраивание этого языка даже на уровне операционных систем.

Итак, язык XML впервые открывает перед многомиллионной интернетов­ской аудиторией дверь в мир настоящей структурной разметки и подлинной ортогональности аспектов содержания и представления. В конечном итоге эта новая технология должна резко увеличить производительность тру­да авторов, сняв необходимость утомительного, зачастую ручного перевода информации из одного визуально-ориентированного формата в другой. Од­нако не обойтись на этом пути и без трудностей «перепривыкания» и ломки сложившихся стереотипов. Перейти с HTML на XML — это совсем не то же самое, что обновить версию вашего любимого текстового процессора. Может показаться, что идеология ортогональности языка SGML, прекрасно работающая для устоявшихся типов документов с годами отлаживавшимися DTD, не справляется со слишком разнообразным и зачастую нелогичным содержимым современного Интернета. Вспомним, однако, что только про­тиворечие может быть двигателем прогресса, — нам предстоит еще увидеть, как развиваются, взаимообогащаясь и изменяясь под действием друг друга, Интернет и XML...

Синтаксис

Внешне XML-документ очень похож на HTML: те же угловые скобки, открывающие и закрывающие теги, атри­буты и подстановки. Но если в HTML все допустимые теги жестко заданы стандартом, то XML-документ может поль­зоваться любыми тегами, пусть даже изобретаемыми на ходу автором документа. Это объясняется разным статусом этих языков: если HTML есть одно из приложений SGML, его от­прыск и порождение, то XML — это подмножество SGML, его «младший брат», обладающий лишь чуть меньшими возможностями и точно так же пригодный для создания фиксированных систем разметки документов. Такие систе­мы на основе XML действительно создаются в последнее время во множестве — от сложного языка MathML для разметки математических текстов до простеньких наборов из пары десятков тегов для хранения кулинарных рецептов или текстов церковных проповедей.

DTD

Вся специфика HTML как одного из приложе­ний SGML выражена в особой формальной конструкции, называемой определением типа документа (Document Type Definition, DTD). В идеале DTD — высший авторитет во всем, что касается синтаксиса той или иной версии HTML. Им, к примеру, пользуются HTML-валидаторы — интерпре­таторы SGML, проверяющие соответствие HTML-докумен­та некоторому DTD. Поскольку DTD для каждой версии HTML зафиксировано в официальной спецификации языка,

в самом документе приводить его не нужно, — однако любой HTML-документ обязан ссылаться на свое DTD с помощью тега!DOCTYPE (стр. 29).

Хотя синтаксис DTD мы в этой книге рассматривать не будем, полезно знать, какая именно информация может храниться в определении типа документа:

• полный список допустимых элементов с указанием на обязательность для каждого из них открывающего и закрывающего тегов;

• полный список атрибутов для каждого элемента, с информацией об их обязательности/факультативности и значениями по умолчанию;

• иерархическая структура документа в виде информации о том, какие другие элементы, в каком порядке и в каких сочетаниях (друг с другом и/или с обычным текстом) могут встречаться внутри каждого из элементов.

Например, в DTD для HTML 4.0 указано, что у элемента HTML можно опускать как открывающий, так и закрыва­ющий теги (границы элемента устанавливаются интерпре­татором по контексту), а его содержимое должно состоять из элементов HEAD и BODY, идущих именно в таком по­рядке. Элемент OL (нумерованный список) обязан иметь как открывающий, так и закрывающий теги, а содержимое его должно состоять из одного или нескольких следую­щих друг за другом элементов LI. DTD в языке XML на этом уровне рассмотрения имеет только одно существенное отличие от DTD в SGML (и HTML): все элементы XML-до-кумента без исключения обязаны иметь и открывающий, и закрывающий тег.

Важно понимать, что ни в SGML, ни в XML DTD не имеет никаких средств для задания семантики тегов, — иными словами, DTD не дает ответа на вопрос, что означает каждый тег. В каком-то смысле идеология SGML следует Людвигу Витгенштейну, которому принадлежит высказы­вание: «The meaning of a word is its use» («Значение слова — это то, как оно употребляется»). Тот факт, к примеру, что тег I включает курсив­ное начертание, формально средствами SGML не выразим, — он лишь подразумевается авторами языка HTML и указывается в комментариях или в сопроводительной документации к HTML DTD.

Именно поэтому путь, избранный в HTML, — жесткое закрепление за каждым из тегов (набор которых ограничен) некоторой «рекомендуемой» роли и параметров форматирования — несмотря на свою простоту, плохо укладывается в рамки идеологии SGML и влечет за собой неприятные последствия. Если семантику тега невозможно определить формально, то нет ничего удивительного в том, что эффект лаже простейших тегов иногда сильно различается у разных броузеров. Абстрактный вопрос «что делает

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

Не нашли, что искали? Воспользуйтесь поиском: