Помощничек
Главная | Обратная связь


Археология
Архитектура
Астрономия
Аудит
Биология
Ботаника
Бухгалтерский учёт
Войное дело
Генетика
География
Геология
Дизайн
Искусство
История
Кино
Кулинария
Культура
Литература
Математика
Медицина
Металлургия
Мифология
Музыка
Психология
Религия
Спорт
Строительство
Техника
Транспорт
Туризм
Усадьба
Физика
Фотография
Химия
Экология
Электричество
Электроника
Энергетика

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



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

 




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

©2015-2020 studopedya.ru Все права принадлежат авторам размещенных материалов.