Двухбайтовые кодировки

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

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

ISO 10646 и UTF-8

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

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

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

HTML

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

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

История

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

В начале был SGML

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

20

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

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

определений элементов, представляющий собой, по сути, формальное описание структуры документа.

Прикладная философия

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

глазах медленному и трудному процессу вычленения и очищения аспектов компьютерного представления информации. До сих пор подавляющее Большинство текстов создаются и хранятся в «фирменных», ориентированных на визуальное представление форматах вроде MS Word, — которые,

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

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

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

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

22

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

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

Золотой век

Принципы, на которых строится язык 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 3 поддержку так называемых иерархических стилевых специ­фикаций (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.

Практически все новые теги, без устали изобретаемые Net­scape, были направлены на улучшение внешнего вида до­кумента и расширение возможностей его форматирования. Причины понятны: чтобы убедить, скажем, бизнесмена, что ему пора обратить внимание на некую новую технологию, прежде всего нужно показать ему ее в привлекательном, «товарном» виде. Поставив себе целью завоевание корпора­тивного рынка, разработчики из 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 и не представлял собой ничего

26

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

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

Очевидно, чувствуя потерю инициативы, корпорация Netscape решилась весной 1998 г. на беспрецедентный шаг — опубликовала исходные тексты своего броузера на сайте 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) двух видов — мнемонические и числовые. Первые имеют вид & мнемонический код;, например:

&egrave; для

&lt; для <

&amp; для &

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

В числовых подстановках вместо мнемонического кода используется десятичный числовой код нужного символа с добавлением впереди символа # (например, &#160; для того же символа неразрываемого пробела). Важно помнить, что код символа берется из стандарта Unicode вне зависимости от кодировки основного текста документа. Так, в какой бы кодировке ни был представлен русский текст документа, подстановка для кириллической буквы «А» всегда будет иметь вид &#1040; (хотя поймет ли такую подстановку броузер — это уже другой вопрос).

Минимальный документ

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

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

Текстовая разметка

О возможностях HTML и CSS в области разметки текста довольно подробно рассказывается в гл. III Здесь мне хотелось бы еще раз подчеркнуть врожденную двуплановость языка HTML, сплетенность в нем средств структурной и визуальной разметки, которая особенно Четко проявляется именно в текстовой части документа Использование минимума структурных тегов, результатом которого является «академический стиль» (стр. 150), — самый разумный выход для тех, кому не очень-то нужен

какой бы то ни было дизайн или нет средств на его создание.

Ссылки и привязки

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

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

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

Формы

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

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

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

Изображения и объекты

Тег IMG, предназначенный для

вставки изображений, относится к тегам, создающим но­вые элементы документа, отсутствовавшие в исходном тексте. Тег этот ссылается на хранящееся в отдельном файле изображение в формате GIF или JPEG (стр. 252); этот графический файл может располагаться там же, где и HTML-файл страницы (в таком случае в атрибуте src достаточно указать имя файла), а может лежать и в дру­гом каталоге и даже на другом сервере (в этом случае нужно указывать полный URL-адрес). Большинство атри­бутов этого тега управляют форматированием изображения, устанавливая его размеры (стр. 2,5В), поля, выравнивание и проч. Правила использования атрибута alt приведены на стр. 35.

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

(стр. 28) обеспечит его обратную совместимость с броузерами, понимаю­щими только тег IMG.

Таблицы

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

Фреймы

Возможность поделить окно броузера на части, загру­зив в каждую из «форточек» — фреймов — отдельный HTML-файл, замечательна не столько открывающимися перспективами развития интерфейса сайта, сколько тем фактом, что один HTML-файл получает при этом возмож­ность ссылаться на другие. Таким образом, URL читаемой вами с экрана страницы может совершенно не совпадать с тем адресом, который отображен в строке URL броузера. Это особенно интересно, если учесть, что «просто вставить» внутрь одного файла содержимое другого средствами HTML невозможно (хотя для этого могут использоваться, напри­мер, SSI-вставки, стр. 71). Сайты с фреймами нравятся не всем; иногда их критикуют за неудобство и нелогичность навигации. Более серьезными, однако, являются проблемы доступности фреймов для неграфических сред и для ав­томатических сборщиков информации (программ-роботов поисковых систем, стр. 38). Дизайнерские аспекты работы с фреймами подробно обсуждаются на стр. 188.

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