Последние публикации

  16 Июля, 2011
Взлом капчи
Разбираемся, как ломают капчи. Теория и практика


  17 Июня, 2011
Справочник по PHP
Синтаксис языка и операторы. Функции работы с данными. Файлы и сети. Управляющие функции. ..


  25 Января, 2011
Основы web-технологий.
С появлением высокопроизводительных серверов, сетевого оборудования и высокоскоростных каналов связи ..


  22 Января, 2011
Теоретические основы защиты информации.
В настоящее время и у нас в стране, и за рубежом достаточно много публикаций по современным ..


Поиск по сайту

 

postheadericon Главная / web программирование / web технологии

Веб-дизайн


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

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

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

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

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

Рис. 1

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

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

Например

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

tr>table>

В начале блока ставится комментарий-идентификатор, а в предпоследней его строке мы видим единственный фрагмент, изменяющийся от одного заголовка к другому, — его текст (в данном случае «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 действительно создаются в последнее время во множестве — от сложного языка MathML для разметки математических текстов до простеньких наборов из пары десятков тегов для хранения кулинарных рецептов или текстов церковных проповедей.

DTD

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

 

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

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

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

• полный

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

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

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

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

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

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

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

Правильно структурированные документы, хотя и уступают по «правильности»

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

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

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

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

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

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

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

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

 

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

Конверсия

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

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

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

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

Существуют

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

Надстройки

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

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

XLL

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

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

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

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

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

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

XSL

 Как я уже упоминал, ничто не мешает использовать с XML-документами стилевые спецификации на языке CSS (стр. 40), и для не особенно требовательных к дизайну до­кументов эта комбинация технологий, по-видимому, будет оптимальной. С другой стороны, оформить заголовки, блоки текста и навигационные элементы хотя бы приблизительно так же, как они оформлены на веб-странице на рис. 1, с помощью 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 реализуема только в броузере MSIE 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 вряд ли целесообразно, однако существуют сайты, целиком построенные на этой техноло­гии.

Для статических текстовых документов популярен формат 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 Modelling 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», отводящий по два байта (точнее, по 15 битов) на пиксел. На широких плавных цветовых переходах в режиме 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, называемой аддитивной («складывающей»), при под­готовке к печати изображение должно быть переведено в субтрактивную («вычитающую») систему, использующую противоположные исходным цвета — противоположный красному голубой, противоположный зеленому пурпурный и противоположный синему желтый. Чтобы расширить диапазон цветовоспроизведения, к этим трем компонентам добавляется четвертый — черный, и вся система получает наименование CMYKCyan, Magenta, Yellow, blacK»; чер­ный обозначается в этой аббревиатуре буквой К, чтобы не путать его с синим). Таким образом, для подготовленного к печати изображения в системе CMYK нужно 4 байта на пиксел, и далеко не все растровые форматы способны хра­нить такое изображение (чаще всего для этого используется формат TIFF).

В компьютерных графических программах применяется еще одна система представления цвета — система HSV (от англ. Hue-Saturation-Value, тон-насыщенность-яркость; эту же систему называют иногда HSB, Hue-Saturation-Brightness, или HLS, Hue-Lightness-Saturation). Эта система представляет собой абстракцию, моделирующую не физические свойства цвета, а его восприятие человеком. Растровые форматы не используют систему НSVдля хранения изображений, но с ее помощью очень удобно подбирать цвет при практической работе (стр. 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, но графические дизайнеры, к сожалению, редко задумываются о таких вещах.

Как всегда с опозданием, свое слово сказал и W3C. Разработанный им стандарт «объектной модели докумен­та» (Document Object Model, DOM) подробно описывает взаимодействие встроенного в веб-страницу сценария с эле­ментами документа, перечисляя все возможные действия, свойства и взаимозависимости для объектов, на которые распадается содержимое документа с точки зрения сцена­рия. Пока достаточно близко к этим предписаниям подошел только броузер Microsoft.

Спецификация DOM оперирует достаточно общими прин­ципами и потому не зависит ни от конкретного языка разметки документа, ни от языка сценариев. В то же время стандартизации не избежал и сам JavaScript; его «официальная», в общественном пользовании находящаяся версия называется ECMAScript (стандарт этот был создан не W3C, а европейской промышленной ассоциацией ЕСМА). Интересно следить за тем, как компании, всегда стре­мившиеся любыми средствами добиться преимущества над конкурентами и по возможности монополизировать

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

Модульные технологии

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

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

К сожалению, существует сразу несколько препятствий к реализации этой простой схемы.

• Исполняемый файл программы, скомпилированной для одной компьютерной платформы (например, для Windows 95), не будет работать на другом типе ком­пьютеров (например, на Макинтоше) или в другой операционной системе (например, в DOS). Веб-страницащ не имеет возможности выяснить, в какую операционную систему она попала на компьютере пользователя, так что выбор нужной версии программы из нескольких имеющихся отпадает. Это ограничение можно обойти, пересылая с сервера не готовый к исполнению двоичный код, а исходный текст программы на языке програм­мирования, с тем чтобы компьютер пользователя само­стоятельно превращал его в понятный ему код. Такое решение, однако, имеет свои недостатки: потерю зна­чительной части быстродействия, незастрахованность от ошибок при компиляции и необходимость устанавливать на компьютер наряду с броузером еще и интерпретатор языка программирования (который будет тем объеми­стее, чем больше возможностей предоставляет данный язык).

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

заразить вас вирусом, попортить данные на вашем диске или уворовать конфиденциальную инфор­мацию.

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

На данный момент существуют три технологии встраивания программных объектов в документ. Все они так или иначе пытаются справиться с перечисленными ограничениями.

• Технология подключаемых модулей (plug-in modules) под­разумевает наличие двух компонентов: общего для всех объектов данного типа модуля, который достаточно пе­рекачать из сети один раз и установить на компьютере пользователя как обычную программу, и подключаемых к HTML-странице объектов. Последние интерпретиру­ются и выводятся на отведенное им место в пределах страницы соответствующим модулем, запуск которого (как правило, в фоновом режиме, т. е. без создания соб­ственного окна) берет на себя броузер.

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

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

• Апплеты на языке Java, при всех своих особенностях, имеют немало пунктов сходства с подключаемыми мо­дулями. Основную часть выполняемой апплетом работы берет на себя не передаваемый по сети объект ми­нимального объема, а большая программная система, называемая «виртуальной машиной Java» и устанавлива­емая на компьютер пользователя только раз (в отличие от подключаемого модуля, пользователю не приходится перекачивать ее из сети, так как оба визуальных броузера поставляются уже со встроенными виртуальными маши­нами). Подключаемый к веб-странице объект

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

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

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

• Одно время Java-апплетам пытались составить кон­куренцию так называемые «компоненты ActiveX» — технология фирмы Microsoft, ограниченная только бро­узером Internet Explorer и только платформой Windows. Это наделавшее поначалу много шума, но быстро за­бытое нововведение интересно отсутствием какой бы то ни было «прокладки» между программным модулем (по сути, обычным исполняемым файлом в форма­те Windows) и операционной системой. Для решения проблемы безопасности была разработана система «элек­тронных подписей» с регистрацией законопослушных авторов ActiveX-апплетов у спонсируемых Microsoft «ци­фровых нотариусов». Неудивительно, что эта громоздкая система оказалась нежизнеспособной. В настоящее вре­мя изредка используются лишь ActiveX-объекты самой фирмы Microsoft, поставляемые вместе с ее броузе­рами.

В Windows-версии броузера Internet Explorer (начиная с версии 4) тех­нология ActiveX является не одним из усовершенствований, а букваль­но фундаментом всей программы. При запуске броузера управление получает контейнер, сразу же вызывающий ActiveX-модуль, в котором, собственно, и заключены все функции броузера. Любой программист может, таким образом, без труда встроить в свою программу самый настоящий броузер, написав всего

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

Динамические страницы

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

По некоторым оценкам, больше половины всех страниц в современном Интернете генерируются и обновляются ди­намически — на основе информации из баз данных, в ответ на действия пользователя или в зависимости от каких-то внешних обстоятельств (например, текущей даты или курса доллара). Простейшая технология такого рода, поддержива­емая почти всеми веб-серверами, называется SSI (Server Side Include, «Вставки на уровне сервера»). Возможности ее огра­ничены вставкой внутрь одного HTML-файла содержимого другого, автоматической установкой даты, подсчетом числа загрузок страницы и т. п. Из более сложных технологий создания динамических сайтов особенно популярны две: CGI и ASP.

Стандарт CGI (Common Gateway Interface, «Общий интер­фейс шлюзов»), поддерживаемый большинством программ-серверов, не накладывает каких-либо ограничений на ис­пользуемый язык программирования, а лишь перечисляет правила, которые должна выполнять программа, генериру­ющая веб-страницу, чтобы сервер мог запускать ее в ответ на запрос документа с определенным URL. Однако по­скольку большинство таких программ пишутся на специ­ализированном языке Perl, термины «CGI» и «Perl» часто употребляются как синонимы. Стандарт CGI достаточно прост и, в частности, ничего не говорит о взаимодействии с какими бы то ни было базами данных, оставляя этот аспект целиком на совести самой CGI-программы и того языка, на котором она написана. Язык Perl не является собственностью какой-либо фирмы, и существуют бесплат­но распространяемые интерпретаторы этого языка для всех операционных систем.

Альтернатива CGI, появившаяся в последнее время, — язык ASP (Active Server Pages, «Активные страницы на сервере») фирмы Microsoft (вполне естественно, что поддержка ASP существует пока только в веб-сервере US этой же фирмы). ASP-код хранится не в отдельных объектах, а встраива­ется прямо в HTML «активной» страницы, но в отличие от JavaScript никогда не выходит за пределы веб-сервера. Инструкции языка ASP позволяют генерировать фрагменты HTML-кода, выбирать один из вариантов кода в зависи­мости от каких-то

условий, циклически повторять куски HTML с изменениями и т. п. ASP-файл может состоять це­ликом из ASP-инструкций, а может и быть чистым HTML без единой ASP-вставки; так или иначе, сервер отсылает броузеру только «сухой остаток» HTML после выполнения всех команд ASP. С практической точки зрения главным достоинством ASP являются развитые средства доступа к ба­зам данных, многие из которых, как и веб-сервер Microsoft, работают на платформе Windows NT.

Глава II. Основы дизай­на

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

От читателей моих статей по веб-дизайну, публикуемых по адресу www.webreference.com/dlab/

valign=bottom>THE COAD METHOD

Дата публикации: 29 Октября, 2010
Автор: Кирсанов Д
Прочитано: 5352 раз

-  39  -

<1 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 |  39  | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | ... | 251>

postheadericon Это интересно

Настройка безопасности компьютера.

Методика настройки приложений для безопасной работы в интернете.

Компьютерный вирус

Понятие и классификация.

Хакеры. Герои компьютерной революции.

Давайте проведем небольшой тест. Какие ассоциации вызывает у вас слово «хакер?».

Взлом капчи

Разбираемся, как ломают капчи. Теория и практика