Доступность: изображения-карты

В HTML су­ществует два способа сделать так, чтобы части одного изображения служили ссылками на разные адреса: сервер­ные (server-side) и клиентские (client-side) изображения-карты (image maps). Первый из этих способов, предполагающий посылку серверу координат точки, в которой произошел щелчок мыши, и получение в ответ URL-адреса, на ко­торый нужно перейти, сейчас встречается уже довольно редко, и это нельзя не приветствовать: поскольку само понятие «координат» имеет смысл только в графической среде, оформленные таким образом ссылки по определе­нию недоступны никому, кроме пользователей графических броузеров.

Клиентские изображения-карты, которые хранят конфигу­рацию областей, чувствительных к щелчку мыши, и соот­ветствующие им URL прямо в HTML-файле, с этой точки зрения куда предпочтительнее: неграфический броузер мо­жет, проигнорировав само изображение, представить список его чувствительных областей в виде обычных ссылок. Для этого нужно не забыть снабдить каждый тег AREA вну­три тега MAP атрибутом alt (который, кстати, согласно стандарту является его единственным обязательным атрибу­том), чей текст и будет оформлен в виде соответствующей ссылки.

Еще предпочтительнее, однако, совсем отказаться от карт и разрезать изображение на отдельные «кнопки», не забыв прописать для каждой соответствующий alt-текст. Гра­фические броузеры позволят вам заверстать изображения вплотную без каких-либо швов или зазоров, так что дизайн страницы от этого не пострадает. Кроме гарантированной Доступности в неграфических средах, это решение позволя­ет иногда понизить для исходного изображения цветовую

глубину и, соответственно, уменьшить общий объем файлов страницы (стр. 253).

Мета-данные и поиск

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

К сожалению, все существующие поисковые системы принадлежат частным фирмам, а не общественным организациям, и конкуренция друг с другом заставляет их соблюдать секретность в своих разработках. Веб-мастерам приходится полагаться на слухи, догадки и собственные расследования, результатам которых никогда нельзя доверять на все сто процентов. Кроме того, информационные системы такого объема иногда ведут себя неожи­данно даже для их создателей.

Мертвая зона

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

Ограничения этим не исчерпываются. Существуют роботы, которым не по зубам документы с символами за пределами

Latin-1, а в некоторых случаях даже и ASCII. Другие не могут индексировать сайты с фреймами. Наконец, многие робо­ты ограничивают количество страниц, сканируемых ими в каждом домене. Например, высказывались подозрения (не подтвержденные, но и не опровергнутые руководством компании), что Alta Vista сканирует не больше 600 страниц в каждом домене верхнего уровня.

Сухой остаток. Напомню прежде всего, что создание документов, доступных для роботов, подчиняется тем же основным принципам, что и обеспечение доступности ин­формации в разных средах (стр. 34). И хотя, к сожалению, мало кто из современных роботов обращает внимание на теги структурной разметки, а некоторые не учитывают даже alt-тексты изображений, в целом автоматические сборщики информации больше всего похожи именно на пользователей текстовых или речевых броузеров.

Ограниченность роботов проявляется не только в их слепоте по отношению к графике, но и в том, что они не очень-то разумно обращаются и с текстом. Способность обобщать и классифицировать пока доступна только человеку, и чтобы обеспечить приемлемый уровень соответствия между тем, что именно хотел найти пользователь поисковой системы, и тем, какие ссылки он получил в ответ на свой запрос из базы данных, работу по «выпариванию» информационной сути страницы приходится брать на себя ее автору. С этой целью ключевые страницы сайта (как минимум, его первая страница) снабжаются аннотациями и списками ключевых слов. Для этого был приспособлен тег МЕТА (вообще предназначенный для хранения метаинформации документа, т.е. «информации об информации»):

<МЕТА name="keywords"

content="searching, search engines, keywords, HTML"> <META name="description"

content="A description of web search engines, spiders,

and search-friendly HTML authoring"> Важно понимать, что стандарт HTML предписывает для тега МЕТА только наличие атрибутов name и content, то­гда как интерпретация значений этих атрибутов оставлена целиком на усмотрение того, кто их читает. Поэтому раз­ные поисковые системы имеют разные требования в том, что касается максимальной длины списка ключевых слов, его синтаксиса (например, нужны ли запятые между эле­ментами списка), допустимости повторений одного слова

в разных грамматических формах. Аннотация (description) используется многими поисковыми системами при выводе результатов поиска; если она отсутствует, страница в спис­ке результатов обычно представлена первыми несколькими словами своего текста.

Кроме вставки ключевых слов и аннотаций, тег МЕТА может использовать­ся для указания автора страницы, программного обеспечения, в котором она создана, а иногда и кодировки текста. Этот тег способен выполнять некоторые функции HTTP-заголовка (стр. 33), пересылаемого вместе с до­кументом с веб-сервера на компьютер пользователя, в том числе и такую важную для практики вещь, как автоматическое перенаправление броузера с данной страницы на другой URL-адрес (сразу или же через заданное количество секунд). С помощью этого же тега можно запретить индекси­ровать данную страницу роботами (еще один пример установки семантики атрибутов по взаимному соглашению).

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

Хороший список ключевых слов не составишь за один присест — он требует от вас досконального знания своей предметной области и нужд ваших потенциальных посе­тителей. Как отец Браун, мысленно перевоплощавшийся в подозреваемых, чтобы понять, кто из них совершил пре­ступление, вы должны поставить себя на место тех, кому позарез нужен именно ваш сайт. Не старайтесь при этом слепить обобщенный образ «среднего посетителя»; наобо­рот, попытайтесь представить себе как можно более разные и даже на первый взгляд неправдоподобные сценарии поис­ка информации. В особо интересных случаях МЕТА-список становится настоящей «ментограммой» создателя страницы, несущей едва ли не больше информации, чем основной текст, и способной отфильтровать людей с близким автору мышлением среди тысяч случайных зевак.

CSS

Язык иерархических стилевых спецификаций (Cascading Style Sheets, CSS) был разработан в качестве дополнения

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

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

С распространением XML у CSS, возможно, откроется «второе дыхание» так как ничто не мешает пользоваться CSS-спецификациями для доку­ментов, размеченных в XML, а предназначенный специально для ХМL стилевой язык XSL (стр. 53) может оказаться слишком сложным для мас­сового применения.

Принципы

Система CSS предоставляет в распоряжение дизайнеров набор обобщенных свойств (параметров оформления), та­ких как имя шрифта, цвет элемента и фона под ним, ширина любого из четырех окружающих элемент полей. Написание спецификации для HTML-документа заключа­ется в присвоении значений нужным свойствам для тех или иных элементов (т.е. HTML-тегов), классов элементов (которые маркируются в HTML с помощью атрибута class у соответствующих тегов) и отдельных экземпляров тегов (идентифицируемых атрибутом id). Кроме того, можно варьировать свойства элементов, стоящих в том или ином контексте (например, увеличить расстояние между строками только для тех элементов Р, которые следуют сразу за эле­ментом H1, — что было бы аналогом одной из особенностей верстки данной книги).

Слово «cascading» в названии системы CSS напоминает о том, что на вывод каждого тега в документе могут оказывать влияние сразу несколько стилевых специфика­ций, образующих иерархическую систему. Например, поверх

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

Возможности

От версии системы CSS очень сильно зависит, чего с ее помощью можно добиться. Первая версия спецификации (CSS level 1 или попросту CSS1), ставшая официальным стандартом в конце 1996 года, по сути, лишь предлагала CSS-запись для тех параметров форматирования, которые и без того уже, будь то «законно» или «незаконно», бы­ли доступны HTML-документам в тогдашних графических броузерах. Свойства CSS1 включали в себя выбор шриф­та, параметры форматирования текста, установку фонового цвета или изображения, ширину полей и еще несколько второстепенных параметров, в большинстве своем аналогич­ных атрибутам тех или иных тегов. Управлять положением элемента на странице можно было, лишь изменяя величину его полей и тем самым отодвигая его от границ предшеству­ющего элемента или элемента-родителя.

<

Стандарт CSS2, законченный к январю 1998 года, суще­ственно расширил возможности стилевых спецификаций сразу по нескольким направлениям. Прежде всего, его создатели вспомнили, что если содержимое у документа всегда одно и то же, то разнообразных представлений у него может быть сколько угодно, в том числе и в разных средах. В этой версии было введено понятие «типа среды» (media type), в зависимости от которого выбирается соответству­ющий набор свойств для тегов документа (пока, кроме графического, определен только один тип среды — звуковой,

свойства которого позволяют регулировать громкость, темп произнесения текста и тембр голоса).

Для графических дизайнеров в этой версии также есть немало интересного. Из главных нововведений отметим ме­ханизм подбора шрифтов, позволяющий не только выбирать один из установленных в системе шрифтов, но и подшивать к документу передаваемый вместе с ним по сети шрифт и даже синтезировать шрифт по его описанию (стр. 221). Очень важна также возможность абсолютного позициони­рования любого элемента относительно элемента-родителя или границ окна, в том числе с наложением элемен­тов друг на друга и даже с возможностью «оживлять» их JavaScript-сценариями (стр. 64). Наконец, в этой вер­сии впервые появились средства генерации содержимого, без которых невозможно создать сколько-нибудь сложные системы разметки. Самым частым примером такого генери­руемого содержимого является автоматическая нумерация заголовков, поддержка которой введена в CSS2.

Любые технологии форматирования текста, предназначенные для Интерне­та, вынуждены учитывать ограниченную пропускную способность каналов связи (стр. 177) и тот факт, что пользователям вряд ли понравится ждать загрузки документа целиком, не имея возможности начать его чтение. Все реализации HTML и CSS выводят текст на экран по мере его поступле­ния из сети и, следовательно, не могут вернуться назад и перерисовать то, что уже выведено. Это на первый взгляд несущественное ограничение делает невозможным не только многие специальные эффекты, в которых содержимое или форматирование одной части документа зависит от дру­гой, но и просто достаточно качественную верстку текста. К примеру, система T_EX, прежде чем сверстать абзац текста, прочитывает его до конца и пробует разные варианты разбиения его на строки, минимизируя общее количество слишком тесных или слишком растянутых строк, переносов, висячих строк и прочих отклонений от идеала. Понятно, что ничего похо­жего нельзя ожидать от броузера, который выводит каждую строку текста, как только получает достаточно материала для ее заполнения (если только текст не заключен в таблицу, стр. 235).

Модульный HTML

Нельзя сказать, чтобы доступная на сегодня веб-дизайнерам технология текстовой разметки — HTML с не­большой (из-за проблем совместимости) примесью CSS — была начисто лишена способности к разделению аспектов содержания и представления (стр. 21). Опыт, врожден­ная аккуратность и ответственное отношение к материалу, с которым приходится работать, позволяет отдельным ди­зайнерам практиковать в HTML стиль, вполне отвечающий требованиям идеологии SGML (или, что сейчас более актуально, XML).

Конечно, многим дизайнерам с преимущественно визу­альным мышлением совсем не просто перестроиться на «ортогональный стиль» разметки. Так же как нельзя уви­деть бестелесную душу, вам, возможно, трудно вообразить себе, как будет выглядеть документ, размеченный толь­ко логически, равно как и представить себе идеальную ортогональность — независимость такого «дистиллирован­ного» содержимого от хранящегося отдельно оформления. Если даже примитивные «именованные стили» в текстовых процессорах считаются прерогативой «профессиональных пользователей», что уж говорить о более последовательных системах ортогональной разметки. Я думаю, что если бы умение воспринимать и создавать аспекты информации по отдельности было врожденным и не требовало обуче­ния, язык SGML уже давно стал бы основным средством хранения и распространения текстов.

Режем по живому

Даже если не учитывать несовершенство HTML, в котором логический и визуальный аспекты оказались смешанными по причинам скорее историческим, соблюдение ортогональности — как и любая реализация некоей абстрактной идеи на практике — сталкивается и с вполне объективными трудностями. Бывают случаи, в которых раздели­тельная линия между содержанием и оформлением может быть проведена по-разному; более того, иногда неудачное рассечение на аспекты докумен­та, изначально (в сознании его автора) целостного, приводит к частичной потере информации и к невозможности в дальнейшем удовлетворительно состыковать получившиеся половинки.

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

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

Однако вернемся к 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 [email protected].

<!-- 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 и влечет за собой неприятные последствия. Если семантику тега невозможно определить формально, то нет ничего удивительного в том, что эффект лаже простейших тегов иногда сильно различается у разных броузеров. Абстрактный вопрос «что делает

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

Уровни соответствия

Если в SGML каждый до­кумент обязан иметь свое DTD, а у HTML есть одно DTD на всех, то XML представляет собой компромисс: документ может иметь (или ссылаться на) DTD, а может и обходиться без DTD. В последнем случае каждый новый тег и атрибут определяются самим фактом своего употре­бления. Таким образом, для XML-документов существует два уровня соответствия стандарту: документы, не имею­щие DTD, но удовлетворяющие всем другим требованиям синтаксиса XML, называют правильно структурированными (well-formed), чтобы отличить их от документов валидных (valid), имеющих в своем составе DTD (или ссылку на внешнее DTD).

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

<ПРЕДЛОЖЕНИЕ>

<ПОДЛЕЖАЩЕЕ>

<СУЩЕСТВИТЕЛЬНОЕ> мама </СУЩЕСТВИТЕЛЫЮЕ>

</ПОДЛЕЖАЩЕЕ>

<СКАЗУЕМОЕ тип="простое"> <ГЛАГОЛ> мыла </ГЛАГОЛ>

</СКАЗУЕМОЕ>

<ДОПОЛНЕНИЕ тип="прямое">

<СУЩЕСТВИТЕЛЬНОЕ> раму </СУЩЕСТВИТЕЛЬНОЕ>

</ДОПОЛНЕНИЕ> </ПРЕДЛОЖЕНИЕ>

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

 

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

Конверсия

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

• все значения атрибутов должны быть взяты в кавычки;

• регистр букв в открывающих и закрывающих тегах должен совпадать (в отличие от HTML, язык XML чувствителен к регистру);

• все элементы должны иметь открывающий и закры­вающий тег. Это относится не только к элементам с факультативными тегами (такими как упоминавшийся выше элемент HTML), но и к пустым элементам, которые в HTML имеют только открывающий тег. Например, тег IMG придется записывать так: <IMG alt="" src="e.gif"></IMG> XML также допускает особую сокращенную запись для пустых элементов: <IMG alt="" src="e.gif"/>

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

Надстройки

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

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

XLL

Почти одновременно с самим XML Консорци­умом W3 был стандартизован XLL (extensible Linking Language, «Расширяемый язык ссылок») — механизм созда­ния гипертекстовых ссылок в XML-документах. Этот аспект языка значительно усовершенствован в сравнении с HTML. Вот основные черты гипертекстовой модели XML:

• XML-ссылки реализованы не на уровне тегов (как в случае тега А языка HTML), а с помощью зарезер­вированных имен атрибутов. Это позволяет с легкостью превратить в гипертекстовую ссылку любой элемент до­кумента, просто расширив его список атрибутов.

• Для XML-ссылки можно указать, будет ли она обы