WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     || 2 | 3 | 4 | 5 |   ...   | 6 |
-- [ Страница 1 ] --

Веб-дизайн Автор: Дмитрий Кирсанов Техминимум.

КОДИРОВКИ ТЕКСТА | ASCII | Однобайтовые кодировки | Так и срослось | Семейство 8859 | Двухбайтовые коди ровки | ISO 10646 и UTF-8 | HTML | История | В начале был SGML | Прикладная философия | Золотой век | HTML плюс | Идолы рынка | Бяки и буки | Те же и Microsoft | Три, четыре... | Синтаксис | Подстановки | Минимальный документ | Текстовая разметка | Ссылки и привязки | Формы | Изображения и объекты | Таблицы | Фреймы | Национальные особенности | Согласование кодировок | Среды и доступность | Доступность: таблицы | Как писать alt-тексты | Доступность: изображения-карты | Мета-данные и поиск | Мертвая зона | Сухой остаток | CSS | Принципы | Возможности | Модульный HTML | Режем по живому | Сборно-панельный сайт | Например | XML | Синтаксис | DTD | Уровни соответствия | Конверсия | Надстройки | XLL | XSL ГРАФИКА | Вектор | Вектор в Интернете | 3D | Растр | На все четыре стороны | Цвета | Палитры | Системы представления цвета | ПРОГРАММИРОВАНИЕ | JavaScript | Динамический HTML | Модульные технологии | Динамические страницы | Основы дизайна.

Как учиться дизайну (75) Дизайн и «чужое творчество» (76) Материалы и инструменты (77) ПРОСТРАНСТВЕННЫЕ ОТНОШЕНИЯ | Размер | Относительность размера | Форма и размер | Искусство выравнивания текста | Цвет и размер | Текстура и размер | Пропорции | Золото и пластмасса | Пропорций простота | Микро пропорции | Размещение | Одноуровневые элементы | Разноуровневые элементы | Плотность | Пол и характер | Плотность текста | В нужное время и в нужном месте | ФОРМА | Прямые | Дизайн Пизанской башни | Прямоугольники | Круги и закругления | Кривые Безье | Бесформенность | ЦВЕТ | Как устроен цвет | Прогулка по цветовому кругу | Ну и что? | Главные цвета | Восприятие цвета | Сочетаемость цветов | Текст и фон | ТЕКСТУРЫ | Плоский цвет | Геометрические текстуры | Пиксельные текстуры | Фотографические текстуры | Материальные текстуры | ШРИФТ И ТЕКСТ | Элементы шрифта | Гарнитура, начертание, шрифт | Systema naturae | Виды начертании | Шрифты и время | Классическая антиква | Переходные шрифты | Новая антиква | Кларендон | Новые рубленые | Маятник гуманизма | Подбор шрифтов | Единство противоположностей | Слишком декоративные шрифты | Развивая тему | Шрифты и названия | Параметры набора | Кегль | Прописные и строчные | Интервалы | Выравнивание и отступы | Размещение | Чья случайность лучше? | Цвет | Текст как текстура | ЕДИНСТВО | Content is king | Академический стиль | В полный рост | БАЛАНС | Центр масс системы | Правило рычага | КОНТРАСТ | Контраст — это продолжение единства другими средствами | Одномерный контраст | Многомерный контраст | Аспекты контраста | ДИНАМИКА | Динамика явная | Ветер по Гауссу | Динамика совсем явная | Динамика неявная | НЬЮАНСИРОВКА Дизайн веб-сайтов.

Преграды и препоны | От общего к частному | ТИПЫ САЙТОВ | Первый шаг | В мире.org | Скорей любите нас | Бесплатный сыр | УСТРОЙСТВО САЙТА | Неупорядоченный континуум | Топология сайта | Распределение материала | Фреймы и окна | Первая страница | Всплеск и вскрик | ФОРМАТ СТРАНИЦЫ | The frame of reference | За метки о полях | Во первых строках | У голубого экрана | Если тебе дадут линованную бумагу — пиши поперек | Ступеньки ригидности | ЗАГЛАВИЯ И ЗАГОЛОВКИ | Заглавие | Заголовки: логика | Заголовки: дизайн | Разделители | Баннеры | НАВИГАЦИЯ Общий обзор | Семантика | Дизайн | Разновидности одинаковости | По ту сторону кнопок | Символы и метафоры | Особые случаи | Динамическая навигация | БЛОКИ ТЕКСТА | Кегль | Шрифт | Коренные шрифты | Все шрифты ношу с собой | Осторожно:

кириллица | Цвет | Ссылки | Другие параметры | When all else fails | Правила набора текстов | Расстановка пробелов | Неразрываемые пробелы | Текстовые выделения | Спецсимволы | ПОЗИЦИОНИРОВАНИЕ | Таблицы и распорки | Дурная наследственность | Двойное дно | Белое место | Фэйсом об тэйбл | Позиционирование в CSS | Веб-графика.

ТЕХНИКА | Палитра и диффузия | Цветовые границы | Экранный анти-алиасинг | Из-под пятницы суббота | Пиксельные эффекты | Оптимизация | JPEG | GIF | Взболтать и настоять | Чудное мгновенье | Blow up | ФУНКЦИИ | Выставочная графика | Фоны | Как не надо делать фон | Прогладить с изнанки | Одномерные фоны | Одним куском | Логотипы | Диалектика формы | На единицу площади | Про что картинка?

| Символ и слово | Аспекты логотипа | Баннеры | Сколько натикало? | Форматы | В нужное время и в нужном месте | Слева при входе | Больше жизни | Пьеса в трех действиях | В начале было что то | Собственная гордость | Удар ниже пояса | Смена поколений | На килограмм живого веса | Acknowledgements | Визуал | Рынок визуалов | ПРИЕМЫ | Трехмерность | Император иллюзий | Пластмассовый призрак | Скульптура или барельеф | Искусство искажений | Что упало, то пропало | Нетекстурируюшие эффекты | Текстурируюшие эффекты | Примеры.

www.kirsanov.com | Логотип | Цветовая схема | Входные цвета | Информационные цвета | Первая страница | Карты на стол | Навигация | www.quiotix.com | Логотип | Первая страница | Внутренние страницы | Miscellanea | ГАЛЕРЕЯ ИНДЕКС Техминимум К сожалению, веб-дизайн еще не достиг той ступени развития, на которой технические средства реализации дизайнерских идей отошли бы на второй план. Веб-дизайнер обязан не только свободно ориентироваться во всем спектре технологий современного Интернета, но и сам следить за тем, чтобы его сайты отвечали духу и букве соответствующих стандартов и спецификаций.

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

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

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

Так, поставив на первое место в этой главе технологии разметки текста (HTML и XML), я был вынужден сделать еще шаг назад и начать со стандартов кодирования текста в компьютере. Причина не только в особой актуальности этой темы для пользователей, имеющих дело с кириллическим алфавитом;

важно также, что она даст нам возможность обсудить некоторые общие принципы передачи и обработки информации в компьютере.

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

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

ASCII Однако прежде чем переходить к восьмибитным кодировкам, нужно сказать несколько слов о кодировке под названием ASCII (American Standard Code for Information Interchange) — кодировке также восьмибитной, но охватывающей только 128 символов и потому довольствующейся семью значимыми битами (старший, восьмой бит при этом всегда равен нулю). Важность этой кодировки, включающей латинский алфавит, цифры и основные знаки пунктуации, необычайно велика: почти все остальные (большие по размеру) кодировки совместимы с ней, т. е. размещают на своих первых 128 знакоместах те же самые символы в том же порядке.

Первые 32 позиции в кодировке ASCII заняты так называемыми управляющими символами {control characters), предназначенными не для передачи собственно текстовой информации, а для управления устройством, читающим (или получающим по линии связи) текстовый файл. Лишь немногие из этих символов — возврат каретки, перевод строки, табуляция — до сих пор используются в более-менее общепринятых значениях;

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

ОДНОБАЙТОВЫС КОДИРОВКИ Задействовав в кодировке ASCII старший бит, мы получаем дополнительные 128 знакомест, которых должно хватить для кодирования, например, кириллического алфавита или набора каких-нибудь специ-альных символов.

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

Хронологически одним из первых стандартов кодирования русских букв на компьютерах был КОИ8 («Код обмена информацией, 8-битный»). Эта кодировка применялась еще в доисторические советские времена на компьютерах ЕС ЭВМ, и когда в середине 80-х появились первые русифицированные версии операционной системы UNIX, они унаследовали эту кодировку у своих «предков». Сеть Редком, открывшая в начале 90-х эпоху российского Интернета, в те годы состояла в основном из компьютеров с UNIX и потому также приняла кодировку КОИ8 в качестве стандартной. В результате КОИ8 является сейчас единственно допустимой кодировкой в русскоязычной электронной почте и телеконференциях Usenet и одной из кодировок, которые обязательно должна поддерживать любая русская веб-страница.

Вторая по значению в русском Интернете (и, безусловно, первая по употребимости на персональных компьютерах) кодировка — это стандартная кириллическая кодировка Microsoft Windows, обозначаемая аббревиатурой СР1251 («СР» расшифровывается как «Code Page», «кодовая страница»). Все Windows приложения, работающие с русским языком, обязаны понимать эту кодировку без перевода. Благодаря распространенности Windows кодировка СР1251, вместе с КОИ8, входит в абсолютный минимум кодировок, которые приходится поддерживать русскоязычным сайтам.

Реликтом эпохи MS DOS остается так называемая «альтернативная» кодировка, в терминологии фирмы Microsoft — кодировка СР866. И хотя в Интернете компьютеры с MS DOS — большая редкость, кодировка эта сохраняет определенный авторитет благодаря тому, что она принята в качестве стандартной в операционной системе OS/2 и в некоммерческой сети Фидо. Поэтому изредка можно встретить сайты, предлагающие посетителям в качестве одного из вариантов и альтернативную кодировку MS DOS.

Однако первой фирмой, выпустившей русифицированную операционную систему, была все-таки не Microsoft, a Apple. И разумеется, русифицированные Макинтоши, появившиеся в конце 80-х, имели свою собственную, ни с кем не совместимую кодировку кириллицы. Хотя в нашей стране компьютеры этой марки так и не приобрели популярности, сравнимой с их популярностью на Западе, в Сети можно встретить и кириллическую кодировку для Макинтошей.

Так и срослось. Зачем, однако, вообще понадобилось создавать разные кодировки для одного и того же алфавита? Помимо соображений конкуренции, вообще способствующих появлению несовместимых решении, изобретателями кодировок в первую очередь двигал чисто практический расчет. Как правило, еще до того, как операционная система русифицируется, за символами из верхней половины таблицы ASCII (с кодами от 128 до 255) уже закреплено то или иное употребление, и чтобы разместить в этом же диапазоне кириллический алфавит, приходится чем-то жертво вать. Разумеется, наименее ценные кодовые позиции, замещение которых нанесет меньше всего ущерба функциональности системы, в каждом случае свои, и чаще всего необходимые для полного набора кириллицы 66 знакомест (включая букву «ё», которая традиционно выносится за пределы основного алфавита) не удается расположить подряд. Этим и объясняется тот факт, что ни в одной из кодировок, кроме ISO 8859 5 и Unicode, русские буквы не идут сплошным блоком. В некоторых кодировках допус каются даже отклонения от алфавитного порядка — в частности, в КОИ8 расположение русских букв определяется, как это ни смешно, алфавитом тех латинских букв, которые на клавиатурах советского производства располагались на одних клавишах с соответствующими буквами кириллицы: например, буква «Ю» стояла на одной клавише с символом «@», идущим в ASCII перед латинской «А», и потому стала в КОИ8 «первой буквой алфавита».

Семейство 8859. Похожая ситуация с конкурирующими платформами и операционными системами и, как следствие, с конкурирующими несовместимыми кодировками наблюдается и в других языках, пользующихся своим собственным алфавитом или даже латинским алфавитом с расширениями. Международная организация по стандартизации (International Standards Organization, ISO) попыталась навести порядок в восьмибитных кодировках, создав серию кодировок ISO 8859, расширяющих таблицу ASCII для латинских букв с диакритикой и лигатур (кодировка ISO 8859-1), кириллицы (ISO 8859-5), арабского (ISO 8859-6), греческого (ISO 8859-7), иврита (ISO 8859-8) и других алфавитов.

Если кодировка ISO 8859-5 для кириллицы так и не прижилась, первая из этой серии — кодировка ISO 8859-1, известная также под именем Latin-1, — сумела стать общепринятым стандартом для кодирования «расширенной» латиницы. В эту кодировку включены почти все символы, употребляющиеся в письменностях западноевропейских языков — французского, немецкого, испанского и т.д. По аналогии с ASCII первые позиции во второй половине кодировок серии ISO 8859 (коды со 128 по 159 включительно) объявлены «неиспользуемыми». На сей раз, однако, производители программ решили обойти этот запрет. Так, большинство шрифтов для Windows соответствуют кодировке ISO 8859-1 начиная с позиции 160 до конца таблицы, но в диапазоне 128—159 размещают некоторые дополнительные символы (в частности, длинное тире и символ «торговой марки», стр. 233). Поскольку HTML обязан соответствовать стандарту Latin-1 (а начиная с версии 4 — Unicode), числовые подстановки (стр. 29) не могут ссылаться на коды из этого диапазона.

ДВУХБАЙТОВЫЕ КОДИРОВКИ.

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

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

В 1991 году была предпринята попытка создать единую универсальную двухбайтовую кодировку, охватывающую все алфавиты и иероглифические системы мира. Результатом стал стандарт под названием Unicode, покрывающий не только системы письменности всех живых и большинства мертвых языков мира, но и множество музыкальных, математических, химических и прочих символов. Хотя массовое применение Unicode в документах и программах остается делом будущего, для веб-дизайнера эта кодировка имеет особое значение, так как именно она объявлена «стандартной кодировкой документа» в HTML начиная с версии 4 (стр. 32).

ISO 10646 и UTF-8. Предвидя неизбежное рано или поздно исчерпание и двухбайтового кодового пространства (пока еще до этого далеко, так как около 30% кодов в Unicode до сих пор не заняты), ISO уже застолбила стандарт четырехбайтовой, совместимой с Unicode кодировки под названием ISO 10646. Пока что вместо этого обозначения, которое то и дело попадается в стандартах, вы можете с чистой совестью подставлять «Unicode», так как никаких новых символов, выходящих за границы совпадающих с Unicode первых 65536 знакомест, в ISO еще не определено.

По-видимому, в ближайшее время все более важную роль будет играть особый формат Unicode (и ISO 10646) под названием UTF-8. Эта «производная» кодировка пользуется для записи символов цепочками байтов различной длины (от одного до шести), которые с помощью несложного алгоритма преобразуются в Unicode-коды, причем более употребительным символам соответствуют более короткие цепочки. Главное достоинство этого формата — совместимость с ASCII не только по значениям кодов, но и по количеству бит на символ, так как для кодирования любого из первых символов в UTF-8 достаточно одного байта (хотя, например, для букв кириллицы нужно уже по два байта).

HTML Вместе с XML, которому посвящен следующий раздел HTML обычно причисляют к «языкам разметки текста». На самом деле роль этих двух языков, как и самого формата под названием «просто текст» («plain text»), выходит далеко за рамки обработки текстовой информации.

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

ИСТОРИЯ Давайте для начала проследим короткую, но необычайно насыщенную историю HTML — языка, в котором столкнулись противоположные (и, в идеале, взаимодополняющие) подходы к проблеме представления информации в компьютере и который стал в последние годы ареной сотрудничества и противоборства основных действующих лиц «компьютерного театра».

В начале был SGML. Начало истории HTML следует отнести к далекому 1969 году, когда Чарльз Гольдфарб, работавший тогда в компании IBM, создал прототип языка для разметки технической документации, впоследствии названного GML, а с приданием ему в 1986 году статуса международного стандарта — SGML (Standard Generalized Markup Language). Этот обобщенный метаязык предназначен для построения систем логической, структурной разметки любых разновидностей текстов. Слово «структурная» означает, что управляющие коды, вносимые в текст при такой разметке, не несут никакой информации о форматировании документа, а лишь указывают границы и соподчинение его составных частей, т. е. задают его структуру.

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

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

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

синтезатор речи, читающий документ вслух, сможет отметить заголовок паузой и изменением интонации;

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

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

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

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

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

единственное требование к информации, сохраняемой средствами SGML, — это ее структурированность. В виде иерархической структуры вложенных друг в друга элементов вполне можно представить не только содержимое документа, но и набор относящихся к нему правил и параметров оформления (как это и сделано в языке XSL, стр. 53). Собственно говоря, SGML-документ больше всего похож на базу данных с произвольной длиной поля и возможностью установления иерархических отношений между полями. Как и базе Данных, SGML-документу все равно, что хранить в себе, лишь бы данные соответствовали заранее заданной структуре, — смысл которой придан ей человеком и существует только для него.

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

Золотой век. Принципы, на которых строится язык SGML, значительны и интересны;

несомненно, идеология языка оказала влияние на многие компьютерные разработки. Однако сам по себе SGML не получил сколько нибудь заметного распространения до тех пор, пока в 1991 г. сотрудники Европейского института физики частиц (CERN), занятые созданием системы передачи гипертекстовой информации через Интернет, не выбрали SGML в качестве основы для нового языка разметки гипертекстовых документов. Этот язык — самое известное из приложений SGML — был назван HTML (HyperText Markup Language, «язык разметки гипертекста»).

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

Первым же (и единственным в те далекие времена) графическим броузером была программа Mosaic, разработанная, как и сам WWW, в научном учреждении — Национальном центре суперкомпьютерных приложений США (NCSA). Так что нет ничего удивительного в том, что в этот «золотой век» никаких противоречий между официальными стандартами и их реализацией в броузерах еще не существовало. HTML неторопливо развивался, оставаясь в рамках парадигмы структурной разметки, и в апреле 1994 г. началась подго товка спецификации следующей версии языка — 2.0. Этим занимался образованный в том же году Консорциум W3 (W3 Consortium, сокращенно W3C), перенявший от CERN верховную власть и авторитет в мире WWW.

В настоящий момент консорциум, имеющий статус «международного и некоммерческого», объединяет свыше 150 организаций-членов, в том числе фирмы Netscape, Microsoft и множество других. Однако в 1994—1995 гг.

его членами были почти исключительно университеты и научные учреждения. Столь академический состав W3C сказывался как на самих документах, публикуемых консорциумом, так и на процедуре (и особенно на сроках) их принятия. Достаточно сказать, что спецификация HTML 2.0, единственным серьезным усовершенствованием в которой был механизм форм (стр. 30) для отсылки информации с компьютера пользователя на сервер, была окончательно утверждена лишь в сентябре 1995 г., когда в W3C уже полным ходом шло обсуждение HTML 3, — или, как его называли поначалу, «HTML+».

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

Противоречие это было разрешено опять-таки в полном соответствии с идеологией SGML: W3C ввел в HTML поддержку так называемых иерархических стилевых спецификаций (CSS, стр. 40). Система CSS формально неза висима от HTML, имеет совершенно иной синтаксис, не наследует никаких идеологических ограничений и позволяет, уже в совершенно иных терминах, задавать параметры графического (так же как и текстового, звукового и какого угодно другого) представления для любого тега HTML.

Нет сомнения, что CSS — почти идеальный способ избавить HTML от наследственных дефектов и перевести его развитие на принципиально новые рельсы. Тем досаднее то, как сложилась судьба этого замечательного изобретения. Поскольку спецификацию CSS увязали с другими нововведениями HTML 3, W3C долго не утверждал ее в качестве официального стандарта;

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

Идолы рынка. А между тем коммерческое освоение WWW не заставило себя долго ждать. В начале 1994 г.

группа разработчиков броузера Mosaic основала корпорацию Netscape Communications и вскоре выпустила первую версию коммерческого броузера Netscape (начиная с. версии 2.0 — Netscape Navigator, а с версии 4.0 — Netscape Communicator). С этого момента начался экспоненциальный рост WWW, продолжающийся по сей день.

Чтобы закрепить лидерство (на которое, впрочем, тогда еще мало кто покушался) и привлечь новых пользователей, Netscape вводила в HTML все новые и новые усовершенствования, — поддерживаемые, разумеется, только броузером Netscape.

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

Бяки и буки. Такая политика компании, с одной стороны, принесла ей быстрый и впечатляющий успех (одно время версии Netscape Navigator составляли более 90% всех используемых броузеров), а с другой — вызвала ожесточенное сопротивление наиболее сознательной части HTML-сообщества. Энтузиасты неустанно разъясняли и разъясняют каждому, кто согласен их слушать, что HTML по природе своей не имеет права зависеть от какого-то конкретного броузера и что заявления типа «эту страницу лучше всего смотреть в Netscape Navigator» являются просто насмешкой над здравым смыслом.

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

С другой стороны, если все-таки признать за HTML (в отсутствие CSS) право совмещать в себе содержательный и оформительский аспекты разметки, то можно, придерживаясь ряда несложных правил (стр. 35), создавать страницы, великолепно выглядящие в графических броузерах и притом вполне доступные в любых неграфических средах.

Те же и Microsoft. В конце 1995 г. ситуация в мире HTML была довольно смутной. Популярность броузера Netscape неуклонно росла;

программисты этой фирмы готовили к выпуску версию 2.0, которая должна была утвердить господство Netscape на вечные времена благодаря неслыханному набору новшеств (интерфейс подключаемых модулей, поддержка Java-апплетов, встроенный язык сценариев JavaScript, возможность разбивки окна на фреймы и многое другое). К этому времени W3C окончательно завяз в своем проекте HTML 3, который был слишком сильно оторван от реальности и на завершение которого у консорциума попросту не хватало ни сил, ни средств. HTML 3 по сравнению с HTML 2.0 был важным шагом вперед, однако он развивался по прежнему в рамках идеологии структурной разметки, а инструмент, дающий возможность выйти за эти рамки, — система CSS — был еще далек от завершения.

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

И именно на броузерном фронте, где господство Netscape оставляло меньше всего шансов конкурентам, корпорация Microsoft нанесла свой главный удар. Поначалу мало кто верил, что броузер Microsoft Internet Explorer, который тогда существовал в версии 2.0 и не представлял собой ничего выдающегося, сможет составить конкуренцию Netscape. Тем не менее выпущенная летом 1996 г. версия Internet Explorer 3.0, которая поддерживала почти все расширения Netscape, вызвала настоящий бум и очень быстро утвердилась в качестве «второго главного броузера». Сейчас Microsoft и Netscape делят рынок броузеров почти поровну, и окончательный исход их битвы не берется предсказать никто.

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

Очевидно, чувствуя потерю инициативы, корпорация Netscape решилась весной г. на беспрецедентный шаг — опубликовала исходные тексты своего броузера на сайте http://www.mozilla.org/и пригласила всех желающих программистов и тестеров принять на некоммерческой основе участие в подготовке следующей версии. Как это ни странно, именно работающие из чистой «любви к искусству» энтузиасты создали многие свободно распространяемые и пользующиеся притом огромной популярностью программы (в их числе даже целая операционная система — Linux), и Netscape явно не прочь подзарядиться новыми силами и идеями из этого неисчерпаемого и почти бесплатного источника. По некоторым сведениям, не коммерческих конкурентов, а именно «открытые» программы со свободно распространяемым исходным кодом Microsoft считает главной угрозой для своего могущества.

Три, четыре... Одновременно с разработкой конкурентоспособного броузера Microsoft решила «навести порядок» и в мире HTML. Взяв под свою опеку W3C, она напитала его денежными и людскими ресурсами и тем самым заработала право едва ли не решающего голоса в этой организации. Проект HTML 3 был заморожен, а вместо него в сжатые сроки создан стандарт HTML 3.2, который, по сути, всего лишь описывает большинство расширений Netscape (с тем же успехом их можно назвать теперь «расширениями Microsoft»). Пройдя обычный в W3C процесс обсуждения и внесения поправок, спецификация HTML 3.2 была утверждена в январе 1997 года.

Спираль развития HTML завершила свой первый виток — как и в «золотой век», расхождения между предписаниями стандарта и реализацией HTML в броузерах вновь были сведены к минимуму.

В декабре того же 1997 г., с принятием стандарта HTML 4.0, маятник, похоже, качнулся уже в обратную сторону — наряду с дальнейшим обогащением репертуара визуальных тегов, эта версия ввела немало пусть и не вполне «логических», но очень важных расширений для поддержки многоязычных документов (стр. 32) и обеспечения доступности документа в разных средах (стр. 34). Кроме того, в HTML 4 наконец-то прямо в тексте стандарта четко проведено разделение логических и визуальных тегов (последние объявлены «нерекомендованными», «deprecated»). Кстати, объем спецификации HTML 4 (которую я советую прочесть всем, кто имеет хоть какое-то отношение к веб-дизайну) в несколько раз больше, чем у 3.2, в основном не за счет описания новых тегов, а благодаря гораздо более подробному обоснованию целей и идеологии языка — так, в спецификацию включен даже краткий курс SGML и разбор HTML DTD.

Многие считают, что язык HTML исчерпал потенциал своего развития и что добавление новых тегов вряд ли выведет его на принципиально иной уровень. История HTML, полная борьбы и противоречий, по-видимому, близится к завершению. Точнее, подошла к концу история его развития, так как применяться в более или менее неизменном (и, по-видимому, близком к современному) виде он будет еще долго — ведь в мире накоплено огромное количество ресурсов, жестко привязанных к этому языку. Очень хочется надеяться на то, что наследником HTML станет XML (стр. 47) — язык, гораздо более близкий по идеологии к SGML и в то же время достаточно простой для массового применения. Врожденные и теперь уже вряд ли исправимые недостатки HTML особенно очевидны для тех, кто занимается практическим веб дизайном: из-за того, что HTML с самого начала не был рассчитан на описание внешнего вида документа, он не в состоянии удовлетворительно выполнить эту задачу даже сейчас, при наличии множества визуально-ориентированных тегов. Прямым следствием этого является огромное количество расхождений в интерпретации тегов броузерами. Как бы строго вы ни следовали стандарту, HTML-файл приходится обязательно тестировать по меньшей мере в графических броузерах фирм Netscape и Microsoft, и чаще всего такое тестирование не обходится без неприятных сюрпризов:

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

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

Важно понимать различие между тегами — единицами разметки и элементами — составными частями документа. Теги, во-первых, разделяют исходный неформатированный текст документа на элементы, а во вторых, создают новые элементы, которым ничего не соответствовало в тексте (например, графические вставки или Java-апплеты). Соответственно, и сами теги бывают двух видов — парные, охватывающие какой-то фрагмент текста и/или другие теги, и стоящие в одиночестве непарные:

<парный-тег>текст или другие теги <непарный-тег> Парные теги должны вкладываться друг в друга без пересечений, т. е. если в области действия тега А открылся тег В, он должен закрыться до того, как закроется тег А.

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

Многие теги, как парные, так и непарные, имеют атрибуты, изменяющие и уточняющие действие тега:

<тег атрибут1="значение" атрибут2="значение"...> Регистр букв в идентификаторах тегов и атрибутов (но не в значениях атрибутов) не учитывается. Пары атрибут="значение" распознаются как таковые только внутри угловых скобок тега и отделяются друг от друга пробелами. В большинстве случаев атрибуты являются необязательными, и в их отсутствие интерпретатор HTML должен использовать значения по умолчанию, заданные в стандарте языка. Существуют атрибуты, не требующие присвоения значения, сам факт присутствия которых просто включает какой-то режим работы данного тега. Согласно стандарту, кавычки вокруг значения атрибута обязательны в тех случаях, когда значение это содержит какие-либо символы кроме букв, цифр, точки или дефиса;

однако если вас интересует совместимость с XML, то лучше пользоваться кавычками всегда.

Подстановки. Чтобы ввести в документ символы, отсутствующие на клавиатуре или же имеющие в синтаксисе HTML специальное значение, употребляются подстановки (entities) двух видов — мнемонические и числовые.

Первые имеют вид &мнемонический код;

, например;

è

для ё <

для < &

для & Набор мнемонических кодов, определенный в стандарте HTML, включает в себя, в частности, весь символьный репертуар Latin-1 (в том числе символ неразрываемого пробела

, стр. 229), а начиная с HTML версии 4 и некоторые из символов Unicode (стр. 231).

В числовых подстановках вместо мнемонического кода используется десятичный числовой код нужного символа с добавлением впереди символа # (например, б0;

для того же символа неразрываемого пробела).

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

(хотя поймет ли такую подстановку броузер — это уже другой вопрос).

Минимальный документ. Интересно задаться вопросом -- каково содержимое минимального документа, который тем не менее отвечает с формальной точки зрения стандарту HTML? Ответ на этот вопрос содержится в спецификации HTML 4, но он достаточно интересен, чтобы привести его и здесь. Оказывается, обязательными в HTML-документе являются только два тега: TITLE (стр. 199) и !DOCTYPE. Последний тег, о существовании которого очень многие не подозревают, согласно синтаксису SGML необходим, чтобы удостоверить, что данный файл — именно HTML (а не, скажем, XML), и указать притом его версию (точнее, тот DTD, которому он соответствует, — стр. 48). Например:

ТЕКСТОВАЯ РАЗМЕТКА О возможностях HTML и CSS в области разметки текста довольно подробно рассказывается в гл. III. Здесь мне хотелось бы еще раз подчеркнуть врожденную двуплановость языка HTML, сплетенность в нем средств структурной и визуальной разметки, которая особенно четко проявляется именно в текстовой части документа.

Использование минимума структурных тегов, результатом которого является «академический стиль» (стр. 159), — самый разумный выход для тех, кому не очень-то нужен какой бы то ни было дизайн или нет средств на его создание.

ССЫЛКИ И ПРИВЯЗКИ Очевидно, возможность связывать документы паутиной взаимных ссылок — первое и главное отличие Интернета от всех других средств распространения информации, отраженное даже в названии HTML — языка разметки гипертекста. В то же время тег А, реализующий это волшебство, сам по себе весьма прост и ограничен по возможностям. Любая ссылка в HTML имеет два обязательных элемента: источник — то изображение или фрагмент текста (в более общей трактовке — тот элемент документа), который заключен между <А> и и щелчок по которому активизирует ссылку, и пункт назначения — URL-адрес документа, на который ведет ссылка.

Адрес назначения может указывать не только на весь документ в целом, но и на какое-то место (точнее, опять таки, какой-то элемент) внутри документа, в том числе и внутри самого документа со ссылкой. Для этого пункт назначения должен быть помечен с помощью атрибута name того же самого тега А создателем того документа, на который делается ссылка. В свою очередь, в теге А в документе-источнике эта метка приписывается к адресу назначения через символ У/. Для документов, генерируемых в ответ на запрос программой на сервере (стр. 71), прямо в адресе можно передавать параметры вызова (например, строку поиска);

обычно такие параметры, записанные в виде переменная=значение, отделяются от UR.L вызываемой программы символом ?.

Пожалуй, в гипертекстовом аспекте WWW новичков больше всего поражает не сама возможность ссылаться откуда угодно куда угодно, а тот факт, что для создания ссылки от владельца документа назначения не требуется ровным счетом ничего (за исключением описанного выше особого случая со ссылкой внутрь документа).

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

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

ФОРМЫ.

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

Собственно тег FORM объединяет группу связанных по смыслу элементов и указывает адрес той программы на сервере (стр. Т1), которой будут посланы введенные пользователем данные из всех элементов формы. HTML страница может содержать любое количество независимых друг от друга форм, в каждой из которых должна присутствовать «пусковая кнопка», отправляющая данные на сервер. Кнопке этой не обязательно быть стандартной интерфейсной кнопкой (создаваемой тегом INPUT с атрибутом type="submit");

в этой же роли может использоваться изображение, а для простых форм, состоящих из одного поля ввода или выпадающего списка, посылка данных может активизироваться нажатием Enter в поле ввода или операцией выбора элемента в списке.

ИЗОБРАЖЕНИЯ И ОБЪЕКТЫ Тег IMG, предназначенный для вставки изображений, относится к тегам, создающим новые элементы документа, отсутствовавшие в исходном тексте. Тег этот ссылается на хранящееся в отдельном файле изображение в формате GIF или JPEG (стр. 252);

этот графический файл может располагаться там же, где и HTML-файл страницы (в таком случае в атрибуте src достаточно указать имя файла), а может лежать и в другом каталоге и даже на другом сервере (в этом случае нужно указывать полный URL-адрес). Большинство атрибутов этого тега управляют форматированием изображения, устанавливая его размеры (стр..256), поля, выравнивание и проч. Правила использования атрибута alt приведены на стр. 35.

В последующих версиях HTML, вполне вероятно, будет предпринята попытка перейти на использование тега OBJECT для вставки любых внешних по отношению к документу объектов или данных, в том числе и изображений. Обобщенный синтаксис тега OBJECT позволяет указать множество дополнительных сведений об изображении и его роли в документе, а принадлежность этого тега к разряду «парных с игнорируемым содержимым» (стр. 28) обеспечит его обратную совместимость с броузерами, понимаю щими только тег IMG.

ТАБЛИЦЫ.

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

ФРЕЙМЫ Возможность поделить окно броузера на части, загрузив в каждую из «форточек» — фреймов — отдельный HTML-файл, замечательна не столько открывающимися перспективами развития интерфейса сайта, сколько тем фактом, что один HTML-файл получает при этом возможность ссылаться на другие. Таким образом, URL читаемой вами с экрана страницы может совершенно не совпадать с тем адресом, который отображен в строке URL броузера. Это особенно интересно, если учесть, что «просто вставить» внутрь одного файла содержимое другого средствами HTML невозможно (хотя для этого могут использоваться, например, SSI-вставки, стр. 71).

Сайты с фреймами нравятся не всем;

иногда их критикуют за неудобство и нелогичность навигации. Более серьезными, однако, являются проблемы доступности фреймов для неграфических сред и для автоматических сборщиков информации (программ-роботов поисковых систем, стр. 38). Дизайнерские аспекты работы с фреймами подробно обсуждаются на стр. 188.

НАЦИОНАЛЬНЫЕ ОСОБЕННОСТИ Хотя с текстовыми кодировками мы уже знакомились (стр. "14), теория и практика создания разноязычных HTML-документов — особая тема. Как я уже упоминал, стандартной кодировкой HTML-документов начиная с версии 4 объявлена кодировка Unicode. Однако это совсем не означает, что все HTML-документы должны создаваться, храниться и передаваться в этой кодировке. Стандарт допускает использование автором страницы любых других кодировок (при условии, разумеется, что набор символов выбранной кодировки соответствует потребностям документа);

однако «внутри себя», разбирая синтаксис документа, броузер обязан перекодировать его из внешней, заданной автором кодировки в Unicode.

Для дизайнера это требование имеет, пожалуй, только одно практическое следствие: числовые подстановки (стр. 29) должны ссылаться на Unicode-коды нужных символов, а не на их коды в текущей кодировке документа.

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

К сожалению, поскольку многие версии броузеров до сих пор не подозревают об этом требовании стандарта, с известной гарантией можно пользоваться только числовыми или мнемоническими кодами из репертуара Latin- (которая является подмножеством Unicode).

Согласование кодировок. Веб-сервер, посылая документ по запросу броузера, обязан указывать внешнюю ко дировку этого документа в так называемом HTTP-заголовке, предшествующем любому отправляемому с сервера файлу и содержащем служебную информацию о нем. Броузер же по получении такой посылки должен переключиться в эту кодировку, что сводится обычно к замене шрифтов, которыми выводится документ, и/или перекодировке (например, из КОИ8 в СР1251, если предполагается использовать функции вывода операционной системы Windows, для которой эта кодировка «родная»).

К сожалению, этой возможностью пользуются далеко не все серверы русского Интернета. Часто, попав на страницу по ссылке с другого сайта, приходится вручную переключать кодировку отображения командой в меню броузера. (Очевидно, что веб-серверы вряд ли игнорировали бы необходимость указывать кодировку отсылаемых документов, если бы броузеры не позволяли переключать кодировки пользователю.) Автор документа может эмулировать HTTP-заголовок прямо в HTML с помощью тега МЕТА, заставляя броузер переключаться в нужную кодировку без перенастройки сервера.

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

Распространенные графические броузеры пока что не поддерживают эту возможность.

СРЕДЫ И ДОСТУПНОСТЬ Обеспечение доступа к сайту для любых платформ и любых сред (графической, текстовой, звуковой) — важный аспект веб-дизайна, к сожалению, часто упускаемый из виду практикующими дизайнерами. Не следует думать, что общепринятыми графическими броузерами не может пользоваться только пренебрежимо малый процент чудаков, инвалидов и обладателей текстовых терминалов вместо «настоящих компьютеров». Все больше становится пользователей, по разным причинам предпочитающих слушать, как специальная программа читает текст вслух (например, почему бы не послушать таким образом новости с любимого сайта, сидя за рулем), или владельцев всевозможных переносных устройств для доступа к сети, очень часто с черно-белым, весьма ограниченным по возможностям экраном. Наконец, нельзя забывать о том, что вашу страницу будут читать не только люди, но и всевозможные «роботы» и автоматические сборщики информации, которые очень похожи на «неполноценных» пользователей именно своей ограниченностью текстовым аспектом информации.

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

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

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

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

Как писать alt-тексты. Особого внимания заслуживает атрибут alt тега IMG, предназначенный для записи текстового эквивалента изображения. Значением этого атрибута может быть строка символов, содержащая любые подстановки (например,

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

• Для распорок (стр. 237) и декоративных элементов, не несущих никакой информации, обязательно указывать, пустой alt-текст (alt=""). Как ни странно, этот простейший случай не является значением по умолчанию, так что автор должен сам позаботиться об обнулении alt-текста во всех вспомогательных изображениях.

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

• Для разделителей, аналогичных по функции тегу HR (стр. 203), подходящим alt-текстом будет ряд небук венных значков — например, "======" или "******".

С другой стороны, такое решение неплохо смотрится только в текстовых броузерах вроде Lynx, тогда как владельцам речевых броузеров, скорее всего, не очень-то понравится слушать монотонное «знак равенства, знак равенства, знак равенства...» • Для кнопок панелей навигации (стр. 206) и всех прочих изображений-ссылок разумно принять особое правило оформления alt-текстов (например, я рекомендую заключать их в квадратные скобки). Это следует делать не только для того, чтобы ссылки легко было найти в текстовом эквиваленте страницы, но и для отделения alt-текстов друг от друга: дело в том, что, если графические вставки идут одна за другой без пробелов, их alt-тексты также не будут ничем разделены, если только пробелы или другие символы разделители не предусмотрены в них самих.

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

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

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

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

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

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

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

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

Ограничения этим не исчерпываются. Существуют роботы, которым не по зубам документы с символами за пределами Latin-1, а в некоторых случаях даже и ASCII. Другие не могут индексировать сайты с фреймами.

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

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

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

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

<МЕТА name="keywords" content="searching, search engines, keywords, HTML"> Важно понимать, что стандарт HTML предписывает для тега МЕТА только наличие атрибутов name и content, тогда как интерпретация значений этих атрибутов оставлена целиком на усмотрение того, кто их читает. Поэтому разные поисковые системы имеют разные требования в том, что касается максимальной длины списка ключевых слов, его синтаксиса (например, нужны ли запятые между элементами списка), допустимости повторений одного слова в разных грамматических формах. Аннотация (description) используется многими поисковыми системами при выводе результатов поиска;

если она отсутствует, страница в списке результатов обычно представлена первыми несколькими словами своего текста.

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

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

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

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

CSS Язык иерархических стилевых спецификаций (Cascading Style Sheets, CSS) был разработан в качестве дополнения к HTML, призванного восполнить ограниченные возможности этого языка в области визуального форматирования, а в идеале — и полностью взять на себя определение внешнего вида документа, оставив за HTML только структурную разметку.

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

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

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

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

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

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

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

Режем по живому. Даже если не учитывать несовершенство HTML, в котором логический и визуальный аспекты оказались смешанными по причинам скорее историческим, соблюдение ортогональности — как и любая реализация некоей абстрактной идеи на практике — сталкивается и с вполне объективными трудностями.

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

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

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

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

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

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

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

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

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

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

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

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

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

The Coad Method focuses on... frequent, tangible, working results.

Модульный 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 действительно создаются в последнее время во множестве — от сложного языка Math ML для разметки математических текстов до простеньких наборов из пары десятков тегов для хранения кулинарных рецептов или текстов церковных проповедей.

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

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

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

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

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

Например, в 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 придется записывать так:

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

Существуют утилиты, переводящие 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-ссылки можно указать, будет ли она обычной ссылкой, активизируемой пользователем (щелчком мышью, к примеру), или же броузер, встретив в документе эту ссылку, должен активизировать ее сам, не дожидаясь команды пользователя.

• Для ссылки можно указывать результат ее активации, а именно: вывести ли документ, на который она ссылается, вместо текущего (например, в том же окне броузера), создать ли для него новый контекст вывода (например, новое окно), или же содержимое нового документа нужно вставить внутрь текущего документа.

• Важные усовершенствования внесены в синтаксис URL-адресов, использующихся в ссылках. Выше я уже упоминал, что адреса могут содержать параметры вызова программы или идентификатор фрагмента документа, отделяемые от основной части адреса соответственно символами ? и # (стр. 30). XML расширяет синтаксис этих конструкций, благодаря чему, не теряя обратной совместимости с существующими адресами, они позволяют адресовать практически любой фрагмент любого XML- или HTML-файла. При этом не требуется, чтобы автор файла, на который ссылаются, как-то по-особому разметил этот фрагмент (в HTML, как вы знаете, его нужно пометить тегом А с атрибутом name). Более того, вырезание этого фрагмента из документа можно переложить на сервер, на котором документ хранится, тем самым избежав пересылки по сети документа целиком (правда, для этого нужно, чтобы сервер умел обрабатывать такие «расширенные» запросы).

XSL. Как я уже упоминал, ничто не мешает использовать с XML-документами стилевые спецификации на языке CSS (стр. 40), и для не особенно требовательных к дизайну документов эта комбинация технологий, по видимому, будет оптимальной. С другой стороны, оформить заголовки, блоки текста и навигационные элементы хотя бы приблизительно так же, как они оформлены на веб-странице на рис. "I, с помощью CSS невозможно.

Поэтому в качестве одной из стандартных надстроек над XML Консорциум W3 разработал стилевой язык XSL (extensible Stylesheet Language, «Расширяемый язык стилевых спецификаций»).

Один из прототипов XSL — созданный уже довольно давно для использования совместно с SGML язык DSSSL (Document Style Semantics and Specification Language, «Язык стилистических и семантических спецификаций документов»). Как и DSSSL, XSL предполагает два последовательных этапа при обработке документа. На первом этапе иерархическое дерево элементов исходного документа преобразуется в другое дерево, которое, в принципе, может не иметь с исходным почти ничего общего: содержимое может быть переупорядочено, по иному разбито на элементы, в нем может отсутствовать часть исходного материала (фильтрация) и добавлен новый (генерируемое содержимое, стр. 44). Теги, которыми размечен этот преобразованный документ, могут опять-таки быть любыми (стилевая спецификация документа описывает правила их порождения в зависимости от содержимого оригинала), но общий принцип состоит в том, что эти новые теги уже не должны соотноситься со структурной основой документа, а могут содержать только параметры форматирования тех его частей, которые подлежат выводу.

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

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

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

Этот сценарий предлагает путь относительно безболезненной миграции на XML для огромной массы сайтов, использующих сейчас типично «визуальный» HTML. Для этого, однако, их HTML-разметка должна как можно точнее соблюдать заповеди модульного HTML (стр. 45). Например, приведенный на стр. 46 блок внутритекстового заголовка глобальным поиском легко заменить на логический XML-элемент:

The Coad Method Теперь достаточно написать стилевую спецификацию на XSL, которая преобразовывала бы каждую копию элемента FRAMED-HEADING в соответствующий HTML-блок и вставляла бы в нужное место внутри этого блока содержимое обрабатываемого элемента — т. е. текст заголовка, попутно переводя его в верхний регистр (несомненно, регистр текста принадлежит в данном случае к аспекту представления, а не содержания, так что из XML-документа эту подробность лучше убрать).

На момент написания этой книги конверсия модульного HTML в XML + XSL реализуема только в броузере MS1E 4.0 с помощью разработанного фирмой Microsoft ActiveX компонента (стр. 70), транслирующего XML в HTML и передающего полученный HTML-код стандартному механизму форматирования броузера.

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

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

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

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

Векторное изображение состоит из объектов — геометрических форм, составленных из прямых, дуг окружности и кривых Безье (стр. 99). Во всех векторных форматах объекты могут варьировать толщину и цвет контура, а замкнутые объекты — еще и цвет заливки. Объекты могут накладываться, частично или полностью заслоняя друг друга. В качестве отдельных объектов могут включаться растровые изображения и строки или абзацы текста (буквы которых могут также храниться в виде геометрических форм, но допускают и более высокий уровень абстракции — разделение на собственно текст, который можно редактировать, и параметры его оформления). Именно такой базовый набор возможностей предусмотрен в языке PostScript — одном из первых векторных форматов, появившемся в 1986 г. и до сих пор остающемся lingua franca для векторных изображений.

Фирма Adobe, которой принадлежит язык PostScript, разработала также первый векторный графический редактор Adobe Illustrator, для которого PostScript был стандартным форматом файлов. Однако долгие годы сохранявшееся монопольное положение этого формата сыграло с ним злую шутку: тот факт, что он стал стандартным входным форматом появившихся к тому времени лазерных принтеров и фотонаборных автоматов, практически затормозил его развитие, так как зашитое в принтер программное обеспечение, в отличие от программы, установленной на компьютере, не так-то просто обновить. В результате уже к началу 90-х PostScript стал узким местом и Adobe Illustrator, и векторных редакторов других фирм, — которые могли бы реализовать, к примеру, частичную прозрачность объектов, но не решались сделать это из боязни потерять совместимость с PostScript.

В последнее время, однако, избавившись от гипноза PostScript'a, векторные форматы развиваются очень бурно — являясь по самой своей природе «сборниками абстракций», они легко заимствуют подходящие идеи из соседних областей. Некоторые из этих форматов двигаются в направлении поддержки сложных многостраничных документов с элементами логической разметки, а программы для работы с ними все больше походят на системы верстки. Другие вводят элементы анимации, мультимедиа и интерактивности. Все это сопровождается развитием собственно векторной основы графики, изобретением все новых свойств объектов и трансформаций для работы с ними. Конечно, векторные эффекты еще не столь многочисленны, как растровые (стр. 295), но они позволяют иногда добиться в векторной графике, при сохранении всех присущих ей достоинств, таких вещей, которые до недавнего времени казались прерогативой только и исключительно растра.

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

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

Тем не менне среди реально применяемых в Интернете векторных форматов уже есть свои лидеры. У дизайнеров популярен формат Shockwave Flash фирмы Macromedia, замечательный своими богатыми интерактивными и анимационными возможностями (один из предков Flash – профессиональный пакет компьютерной анимации Macromedia Director). Приспособленный специально для Интернета, формат этот поддерживает гипертекстовые ссылки, а в дополнение к своей врожденной векторной нетребовательности пользуется сжатием информации на манер утилит – архиваторов. Для просмотра этого формата в броузере нужен подключаемый модуль (plug-in), бесплатно распространяемый фирмой Macromedia. Для отдельных анимированных вставок использовать Flash вряд ли целесообразно, однако существуют сайты, целиком построенные на этой технологии (например, www.olympic.org).

Для статических текстовых документов популярен формат PDF (Portable Document Format, «переносимый формат документов») фирмы Adobe, разработанный на основе PostScript со сжатием данных обязательным инкапсулированием растровой графики и шрифтов и с возможностью использования гипертекстовых ссылок и интерактивных форм. Хотя графические возможности PDF ничуть не богаче, чем у PostScript, формат этот удобен для выкладывания в Интернете рекламных брошюр, проспектов, журнальных статей и прочих материалов, либо существовавших ранее в виде бумажных копий, либо предназначенных для распечатывания пользователем. Особенно удобно то, что формат PDF не привязан к какой-то графической программе и системе верстки: печатать на PostScript-принтерах и, следовательно, давать на выходе PostScript умеют все программы без исключения, а конвертация из PostScript в PDF – процедура полностью автоматическая. Программа для чтения этого формата под названием Acrobat Reader распространяется бесплатно и существует как в виде подключаемого модуля для броузера, так и в виде самостоятельного приложения.

Консорциум W3 готовит стандарт «языка векторной разметки» VML (Vector Markup Language), использующего синтаксис XML и семантику CSS2 для описания векторных объектов. Относительная примитивность этого языка искупается тем, что для реализации его в современных броузерах не потребует много усилий, так как VML максимально использует набор свойств элементов разметки и механизм абсолютного позиционирования CSS2 (стр.241). Поэтому вполне можно надеяться на то, что язык этот сможет найти свою нишу в современном Интернете.

3D Особую разновидность векторной графики представляют трехмерные форматы, из которых самый известный и чаще всего встречающийся в Интернете – язык VRML (Virtual Reality Modeling Language).

Описываемые трехмерным форматом сцены состоят, как и векторные изображения, из математически описанных объектов, - с той только разницей, что все их точки имеют по три пространственных координаты (а в форматах с поддержкой анимации – еще и четвертую, временную координату). Кроме обычных объектов, сцены могут содержать разноцветные и произвольно размещаемые источники освещения, а программа – интерпретатор покажет вам сцену с любой точки и даже позволит зайти внутрь и «побродить» между объектами. Интерактивная трехмерная графика как метод представления информации грозилась одно время занять место в арсенале приемов профессионального веб-дизайна, однако ничего подобного так и не произошло – трехмерность остается любимой игрушкой непрофессионалов, но для создания в жанре вещей, интересных с художественной точки зрения, время, по-видимому, ещё не пришло (стр. 290).

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

Разница между вектором и растром напоминает отличие студийной записи от «живого» концерта. Студийная мастер-копия сохраняет на отдельных дорожках партию каждого инструмента;

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

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

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

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

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

Цвета. Самые важные для веб-дизайнера форматы — GIF и JPEG — подробно рассматриваются в гл. IV (стр.

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

Так, формат GIF имеет от одного до восьми бит на пиксел и, следовательно, может отображать от 21 = 2 до 28 = 256 цветов. С использованием диффузии даже полноцветную фотографию можно ужать в 256 цветов так, что она будет выглядеть пристойно — но, к сожалению, не более чем «пристойно». Уровень качества, при котором глаз неспособен отличить компьютерную фотографию от настоящей, достигается только при не менее чем трех байтах на пиксел, что дает 224, или около 16 миллионов цветов.

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

Цветовые возможности компьютера зависят от количества его видеопамяти, в которой хранится экранное изображение, и, как правило, один и тот же компьютер может работать в нескольких режимах — либо с большим разрешением (стр. 193), но меньшим количеством цветов, либо с меньшим разрешением, но более богатым цветом.

Видеопамять компьютера расположена не в мониторе, а на видеоплате в системном блоке;

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

Кроме идеального с точки зрения цветопередачи трехбайтового режима, который обычно называется «true color», у многих дисплеев есть промежуточный режим — «high color», отводящий по два байта (точнее, по битов) на пиксел. На широких плавных цветовых переходах в режиме high color можно, приглядевшись, заметить «ступеньки», но для большинства практических нужд режим этот ничем не уступает true color.

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

Таким образом, объем памяти, выделенной на каждый пиксел, делится на три равные части, хранящие яркость красной, зеленой и синей составляющих цвета данного пиксела. В режиме high color на каждую составляющую приходится по 5 бит (что дает 32 градации яркости), а в true color — 1 байт (256 градаций). А поскольку известно, что режим true color превосходит цветовую разрешающую способность человеческого глаза, можно сделать вывод, что для качественной передачи монохромного изображения, изменяющегося только по одной цветовой координате (или, что то же самое, сохраняющего одно и то же соотношение трех составляющих), должно быть достаточно одного байта на пиксел.

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

СИСТЕМЫ ПРЕДСТАВЛЕНИЯ ЦВЕТА.

Самая распространенная и понятная компьютеру без перевода система RGB (от англ. «Red, Green, Blue», т.е.

«красный, зеленый, синий») — не единственная. Если цвет компьютерного экрана изменяется от черного (отсутствие цвета) до белого (максимальная яркость всех трех составляющих), то на бумаге, наоборот, отсутствию цвета соответствует белый, а смешению максимального количества красок — черный (точнее, темно бурый). Поэтому вместо системы RGB, называемой аддитивной («складывающей»), при подготовке к печати изображение должно быть переведено в субтрактивную («вычитающую») систему, использующую противоположные исходным цвета — противоположный красному голубой, противоположный зеленому пурпурный и противоположный синему желтый. Чтобы расширить диапазон цветовоспроизведения, к этим трем компонентам добавляется четвертый — черный, и вся система получает наименование CMYK («Cyan, Magenta, Yellow, Black»;

черный обозначается в этой аббревиатуре буквой К, чтобы не путать его с синим). Таким образом, для подготовленного к печати изображения в системе CMYK нужно 4 байта на пиксел, и далеко не все растровые форматы способны хранить такое изображение (чаще всего для этого используется формат TIFF).

В компьютерных графических программах применяется еще одна система представления цвета — система HSV (от англ. Hue-Saturation-Value, тон-насыщенность-яркость;

эту же систему называют иногда HSB, Hue Saturation-Brightness, или HLS, Hue-Lightness-Saturation). Эта система представляет собой абстракцию, моделирующую не физические свойства цвета, а его восприятие человеком. Растровые форматы не используют систему HSV для хранения изображений, но с ее помощью очень удобно подбирать цвет при практической работе (стр. 103).

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

Существуют, однако, исключения из этого правила. Интересно отметить, что если до сих пор всегда программы порождали данные и оперировали ими, то в Интернете, наоборот, данные (веб-страницы) могут включать в себя и подчинять своим целям программные вставки. Эти «островки интерактивности» — JavaScript сценарии, Java-апплеты и даже элементы HTML-форм — до сих пор не стали и, очевидно, никогда уже не станут несущим каркасом для информации Интернета. Однако во многих случаях программирование способно с выгодой «оживить» статические веб-страницы и реализовать те функции, без которых невозможно полноценное общение с компьютером, в какой бы среде оно ни происходило.

JavaScript.

Разработанный в 1995 г. фирмой Netscape для версии 2.0 своего броузера язык JavaScript до сих пор остается вспомогательным, но в то же время абсолютно незаменимым инструментом, позволяющим загруженной в броузер странице динамически управлять своим содержимым, а заодно и собственно броузером. По своему набору функций этот язык близок к макроязыкам, которые с давних пор встраиваются в любую достаточно сложную программу или систему программ. В отличие от Java, JavaScript-сценарии не замыкается в изолированном апплете (стр. 69), а свободно переплетается и взаимодействует с HTML-разметкой страницы.

Будучи тесно связан с HTML, язык этот имеет сходные недостатки и очень похожий по извилистости жизненный путь.

JavaScript из Netscape 2.0 не умел почти ничего, кроме как открывать и закрывать окна броузера (стр. 198), загружать в них документы, управлять фреймами и взаимодействовать с полями форм (например, проверяя правильность введенных в них значений). Сценарий, встроенный в документ с помощью тега SCRIPT, мог вставлять кусочки HTML-кода в то место документа, в котором расположен сам, но не мог ни считывать содержимое других частей документа, ни, самое главное, изменять текст или графику документа после его загрузки на компьютер пользователя.

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

Динамический HTML. Недоделанность JavaScript пришлась как нельзя более на руку компании Microsoft, как раз в это время бросившей все усилия на завоевание рынка броузеров. Еще в третьей версии Microsoft Internet Explorer язык сценариев (который фирме пришлось назвать JScript, так как марка JavaScript принадлежала Netscape) отличался от своего конкурента разве что тем, что многочисленные ошибки и упущения в его реализации были расположены в непривычных местах. В четвертой версии, однако, фирма Microsoft решила уйти в отрыв.

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

Чтобы не раздражать пользователей путаницей между JScript и JavaScript, фирма Microsoft окрестила комбинацию, включающую расширенный язык сценариев, частичную поддержку CSS2 и несколько мелких усовершенствований, словосочетанием «динамический HTML», — развернув, по своему обыкновению, массированную рекламную кампанию, подающую его как средство от всех без исключения болезней «обычного» HTML. Netscape волей-неволей должна была ответить на вызов и, скрепя сердце, объявила о поддержке динамического HTML в четвертой версии своего броузера, — хотя его возможности имели довольно мало общего с набором технологий Microsoft.

Основную идею динамического HTML можно сформулировать очень просто: полный контроль языка сценариев над всеми без исключения элементами документа, параметрами их оформления и размещения (как подразумеваемыми в HTML, так и задаваемыми с помощью CSS) и даже над самим текстом страницы. Благодаря этому любой элемент HTML-документа сможет двигаться в произвольном направлении, как угодно изменять свое форматирование и буквально переписываться — как в ответ на действия пользователя, так и по собственной инициативе. В сочетании с абсолютным позиционированием элементов средствами CSS (стр. 241) это позволяет реализовать на веб-странице почти полноценный программный интерфейс с выпадающими многоуровневыми меню (стр. 214), перетаскиванием объектов мышью и т. п.

До сих пор, впрочем, динамический HTML особого распространения в Интернете не получил, и для этого есть объективные причины. Главную роль играет, конечно, несовместимость броузеров-конкурентов, из-за которой очень трудно, а в некоторых случаях и невозможно создать одну версию динамической страницы, которая сохраняла бы работоспособность в обоих броузерах. Сказывается также конкуренция со стороны формата Shockwave Flash, в котором можно реализовать не менее интерактивные эффекты, чем в динамическом HTML, который притом полностью застрахован от несовместимостей (существует только один, разработанный самой фирмой Macromedia подключаемый модуль для просмотра Flash-вставок) и имеет стандартную специализированную среду разработки. Конечно, с доступностью информации в неграфических средах (стр. 34) у Flash дела обстоят куда хуже, чем у динамического HTML, но графические дизайнеры, к сожалению, редко задумываются о таких вещах.

Pages:     || 2 | 3 | 4 | 5 |   ...   | 6 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.