Благодарности
Спасибо всем, кто помог в создании рабочих черновых вариантов, приведших к спецификации HTML 4.0, и всем отправившим предложения и исправления.
Большое спасибо группе Web Accessibility Initiative (WAI HC) за работу по улучшению доступности HTML и Т.В. Раман (компания Adobe) за разработку доступных форм.
Авторы этой спецификации, члены Рабочей группы HTML W3C , заслуживают аплодисментов за тщательную проверку этого документа, конструктивные комментарии и труд: Джон Д. Бургер (MITRE), Стив Байрн (JavaSoft), Мартин Дж. Дюрст (Цюрихский университет), Дэниел Глазман (ElectricitE de France), Скотт Айзакс (Microsoft), Мюрей Малони (GRIF), Стивен Пембертон (CWI), Роберт Пернетт (Lotus), Яред Соренсен (Novell), Пауэлл Смит (IBM), Роберт Стиван (HP), Эд Тикот (Microsoft), Джеффри Веен (HotWired), Майк Векслер (Adobe), Миша Вольф (Reuters) и Лорен Вуд (SoftQuad).
Спасибо Дену Коннолли (W3C) за работу редактора и тщательное руководство в качестве председателя Рабочей группы HTML. Спасибо Салли Худаири (W3C) за ее работу над пресс-релизами.
Спасибо Дэвиду М. Абрахамсону и Роджеру Прайсу за внимательное чтение и конструктивные комментарии.
Спасибо Яну Кэррману, автору html2ps за огромную помощь в создании версии спецификации в формате Postscript.
Особую помощь W3C в София-антиполис принесли Дженет Бертот, Берт Бос, Стефан Боера, Даниель Дардельер, Ив Лафон, Хокон Ли, Крис Лилли и Кола Нахабу (Bull).
И наконец, спасибо Тиму Бернерс-Ли, без которого все это было бы невозможно.
Целевые имена кадров
За исключением приведенных ниже зарезервированных имен, целевые имена кадров (%FrameTarget; в DTD) должны начинаться с алфавитных символов (a-zA-Z). Агенты пользователей должны игнорировать все остальные имена.
Следующие target names зарезервированы и имеют специальные значения.
_blank
Агенты пользователей должны загружать документ в новое окно без имени.
_self
Агенты пользователей должны загружать документ в тот же кадр, в котором находится ссылающийся на него документ.
_parent
Агенты пользователей должны загружать документ в непосредственный родительский кадр этого кадра во . Это значение эквивалентно _self, если текущий кадр не имеет родительского кадра.
_top
Агенты пользователей должны загружать документ в полное окно (закрывая все остальные кадры). Это значение эквивалентно _self, если у текущего кадра нет родительского кадра.
Числовые ссылки на символы
Числовые ссылки на символы указывают символа в наборе символов документа. Числовые ссылки на символы могут также принимать две формы:
Синтаксис "&#D;", где D - десятичное число, указывает символ Unicode с десятичным номером D.
Синтаксис "&#xH;" или "&#XH;", где H - шестнадцатеричное число, указывает на символ Unicode с шестнадцатеричным номером H. Шестнадцатеричные числовые ссылки учитывают регистр.
Вот некоторые примеры числовых ссылок на символы:
å (десятичное) представляет букву "a" с кружком сверху (используемую, например, в норвежском языке). å (шестнадцатеричное) представляет тот же символ. å (шестнадцатеричное) представляет тот же символ. И (десятичное) представляет кириллическую заглавную букву "I". 水 (шестнадцатеричное) представляет китайский иероглиф "вода".
Примечание.
Хотя шестнадцатеричное представление не определено в [ISO8879], оно ожидается в новой версии, как описано в [WEBSGML]. Это соглашение особенно полезно, поскольку стандарты символов обычно используют шестнадцатеричные представления.
Цвета
Значение атрибута типа "color" (%Color;) относится к определениям цветов, как указано в [SRGB]. Значение цвета может быть шестнадцатеричным числом (которому предшествует знак диеза) или одним из следующих шестнадцати названий цветов. Названия цветов учитывают регистр.
 | Black = "#000000" |  | Green = "#008000" |
 | Silver = "#C0C0C0" |  | Lime = #00FF00" |
 | Gray = "#808080" |  | Olive = "#808000" |
 | White = "#FFFFFF" |  | Yellow = "#FFFF00" |
 | Maroon = "#800000" |  | Navy = #000080" |
 | Red = "#FF0000" |  | Blue = "#0000FF" |
 | Purple = "#800080" |  | Teal = "#008080" |
 | Fuchsia = "#FF00FF" |  | Aqua = "#00FFFF" |
То есть, значения "#800080" и "Purple" оба означают пурпурный цвет.
Данные сценария
Данные сценария ( %Script; в ) могут быть содержимым элемента и значением . Агенты пользователей не должны оценивать данные сценариев в разметке HTML, а должны передавать эти данные ядру сценариев.
Учет регистра в данных сценариев зависит от языка сценариев.
Помните, что данные сценариев, являющиеся содержимым элемента, не могут содержать , но данные сценария, являющиеся значением атрибута, могут. В приложении приводится информация об .
Данные таблиц стилей
Данные таблиц стилей ( в ) могут быть содержимым элемента и значением атрибута . Агенты пользователей не должны оценивать данные стилей в разметке HTML.
Учет регистра данных стиля зависит от языка таблиц стилей.
Помните, что данные таблиц стилей, являющиеся содержимым элемента, не могут включать , но данные таблиц стилей, являющиеся значением атрибута, могут включать их. В приложении приводится дальнейшая информация об .
Дата и время
[ISO8601] позволяет много вариантов представления даты и времени. Текущая спецификация использует один из форматов, описанных в профиле [DATETIME] для определения допустимых строк дата/время ( %Datetime в DTD).
Это следующий формат:
ГГГГ-ММ-ДДTчч:мм:ссУЧП
где:
ГГГГ = год из четырех цифр ММ = месяц из двух цифр (01=январь и т.д.) ДД = день из двух цифр (01 - 31) чч = две цифры часов (00 - 23) (до/пп НЕ допускается) мм = две цифры минут (00 - 59) сс = две цифры секунд (00 - 59) УЧП = указатель часового пояса
Указатели часового пояса:
Z
означает UTC (Общее скоординированное время). "Z" должно быть в верхнем регистре.
+чч:мм
указывает, что местное время отстоит на чч часов и мм минут от UTC вперед.
-чч:мм
указывает, что местное время отстает на чч часов и мм минут от UTC.
Указанные компоненты должны присутствовать в точности, с точно такой же пунктуацией. Помните, что буква "T" отображается в строке литерально (она должна быть в верхнем регистре), для указания начала времени, как описано в [ISO8601]
Если генерирующее приложение не знает времени с точностью до секунды, для секунд может использоваться значение "00" (при необходимости также для минут и для часов).
Примечание. [DATETIME]
не касается добавочных секунд.
Дескрипторы носителей
Ниже приведен список распознаваемых дескрипторов носителей ( %MediaDesc в DTD).
screen
Предназначен для экранов компьютеров, не разделенных на страницы.
tty
Предназначен для носителя с фиксированной сеткой для символов, таких как телетайпы, терминалы или переносные устройства с ограниченными возможностями отображения.
tv
Предназначен для устройств типа телевизора (низкое разрешение, цвета, ограниченные возможности прокрутки).
projection
Предназначен для проекторов.
handheld
Предназначен для карманных устройств (небольшой экран, монохромный, растровая графика, ограниченный диапазон).
Предназначен для страничных, непрозрачных материалов и документов, просматриваемых на экране в режиме предварительного просмотра печати.
braille
Предназначен для тактильных устройств с алфавитом Бройля.
aural
Предназначен для синтезаторов речи.
all
Для всех устройств.
В будущих версиях HTML могут быть введены новые значения и разрешены параметризованные значения. Для упрощения введения этих расширений соответствующие спецификации агенты пользователя должны иметь возможность анализировать значение атрибута следующим образом:
Значение - это разделенный запятыми список элементов. Например,
media="screen, 3d-glasses, print and resolution > 90dpi"
отображается в :
"screen" "3d-glasses" "print and resolution > 90dpi"
Каждый элемент усекается перед первым символом, не являющимся буквой кодировки US ASCII [a-zA-Z] (десятичные коды Unicode 65-90, 97-122), цифрой [0-9] (шестнадцатеричные коды Unicode 30-39) или знаком переноса (45). В данном примере получается:
"screen" "3d-glasses" "print"
Затем с учетом регистра проводится сверка с набором определенных выше типов дескрипторов. Агенты пользователей могут игнорировать несовпадающие элементы. В данном примере останутся только элементы screen и print.
Примечание. Таблицы стилей могут включать вариации в зависимости от носителя (например, конструкция CSS @media). В таких случаях имеет смысл использовать "=all".
Длины
HTML определяет три типа значений длины для атрибутов:
Пикселы: Значение ( %Pixels; в DTD) - это целое, представляющее число пикселов (на экране, на бумаге). Таким образом, значение "50" означает пятьдесят пикселов. Нормативную информацию об определении пиксела см. в [CSS1].
Длина: Значение ( %Length; в DTD) может быть %Pixel; или доля вертикального или горизонтального расстояния в процентах. Таким образом, значение "50%" означает половину доступного пространства.
МультиДлина: Значение ( %MultiLength; в DTD) может быть %Length; или относительной длиной. Относительная длина имеет форму "i*", где "i" - целое число. При распределении пространства между элементами, конкурирующими за это пространства, агенты пользователя сначала отводят место для длин, определенных в пикселах и процентах, а затем делят оставшееся место между относительными длинами. Каждая относительная длина получает часть доступного пространства, пропорциональную целому числу, предшествующему "*". Значение "*" эквивалентно "1*". Таким образом, если имеется 60 пикселов пространства после того, как агент пользователя распределит пространство для длин, определенных в пикселах и процентах, а конкурирующими относительными длинами являются 1*, 2* и 3*, 1* получит 10 пикселов, 2* - 20 пикселов, а 3* - 30 пикселов.
Значения длин не учитывают регистр.
Доступные форматы
Рекомендацию W3C HTML 4.0 можно также получить в следующих форматах:
Текстовый файл:
(723 Кб), Файл gzip tar, содержащий документы в формате HTML:
(339 Кб), Файл zip, содержащий документы в формате HTML (это файл '.zip', а не '.exe'):
(372 Кб), Файл в формате Postscript:
(4.4 Мб, 363 страницы), Файл в формате PDF:
(2.1 Мб).
В случае расхождений электронной и печатной форм спецификации следует использовать электронную версию.
Информация о регистре
Каждое определение атрибута включает информацию об учете регистра его значениями. Информация о регистре представляется следующими ключами:
CS
Значение учитывает регистр (то есть агенты пользователя по-разному интерпретируют "a" и "A").
CI
Значение не учитывает регистр (то есть агенты пользователя одинаково интерпретируют "a" и "A").
CN
Значение не зависит от регистра, например, потому что это число или символ из набора символов документа.
CA
Само определение элемента или атрибута дает информацию о регитсре.
CT
Подробнее об учете регистра см. в определении типа.
Если значением атрибута является список, ключи применяются к каждому значению в списке, если не указано обратное.
Информация об авторском праве
Copyright © 1997 , (, , Университет Keio). Все права защищены.
Документы, находящиеся на сервере , предоставляются обладателями авторских прав в соответствии со следующей лицензией. Получая, используя и/или копируя этот документ или документ W3C, из которого имеется ссылка на это заявление, Вы признаете, что прочли и поняли следующие условия и обязуетесь их выполнять:
Разрешение на использование, копирование и распространение содержимого этого документа или документа W3C, из которого имеется ссылка на это заявление, с помощью любых средств, с любыми целями и без отчисления авторского гонорара дается при условии, что Вы включите во ВСЕ копии этого документа или его частей следующую информацию:
Ссылку на исходный документ W3C или его URI.
Имеющуюся информацию об авторском праве исходного автора, а если она отсутствует, информацию в форме: "Copyright © World Wide Web Consortium, (Массачусеттский технологический институт, , Университет Keio). Все права защищены."
СТАТУС документа W3C, если он существует.
Если позволяет пространство, следует включить полный текст следующего ЗАМЕЧАНИЯ. Кроме того, в любое программное обеспечение, документы и пр., созданные вследствие применения содержимого этого документа или любой его части, должна быть добавлена благодарность владельцам авторского права.
Данная лицензия не дает никаких прав изменения данного документа или создания документов, производных от него.
ДАННЫЙ ДОКУМЕНТ ПРЕДОСТАВЛЯЕТСЯ "КАК ЕСТЬ"; ОБЛАДАТЕЛИ АВТОРСКОГО ПРАВА НЕ ДАЮТ НИКАКИХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ ГАРАНТИИ КОММЕРЧЕСКОЙ ВЫГОДЫ, СООТВЕТСТВИЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ, НЕНАРУШЕНИЯ АВТОРСКОГО ПРАВА ИЛИ ОБЛАДАНИЯ ИМ, НО НЕ ОГРАНИЧИВАЯСЬ ТАКОВЫМИ; ТО ЕСТЬ ОБЛАДАТЕЛИ АВТОРСКОГО ПРАВА НЕ ДАЮТ ГАРАНТИЙ ТОГО, ЧТО СОДЕРЖИМОЕ ЭТОГО ДОКУМЕНТА СООТВЕТСТВУЕТ КАКИМ-ЛИБО ЦЕЛЯМ И ТОГО, ЧТО ПРИМЕНЕНИЕ СОДЕРЖИМОГО ЭТОГО ДОКУМЕНТА НЕ НАРУШИТ АВТОРСКИХ ПРАВ, ТОРГОВОЙ МАРКИ, ПАТЕНТА ИЛИ ДРУГИХ ПРАВ ТРЕТЬЕГО ЛИЦА ИЛИ ОРГАНИЗАЦИИ.
ОБЛАДАТЕЛИ АВТОРСКОГО ПРАВА НЕ НЕСУТ ОТВЕТСТВЕННОСТИ ЗА ЛЮБОЙ ПРЯМОЙ, КОСВЕННЫЙ, СПЕЦИАЛЬНЫЙ ИЛИ ЗАКОНОМЕРНЫЙ УЩЕРБ, ПОНЕСЕННЫЙ В РЕЗУЛЬТАТЕ ИСПОЛЬЗОВАНИЯ ЭТОГО ДОКУМЕНТА ИЛИ ПРИМЕНЕНИЯ ЕГО СОДЕРЖИМОГО.
Имя и торговые марки обладателей авторского права НЕ могут использоваться в рекламе, имеющей отношение к данному документу или его содержимому без особого письменного разрешения. Авторское право на этот документ навсегда остается за его обладателями.
Информативные ссылки
"SGML: Руководство автора по стандартному обобщенному языку разметки", М. Брайан, Addison-Wesley Publishing Co., 1988 г.
Continuous Acquisition and Life-Cycle Support (CALS). CALS - это стратегия достижения эффективного создания, обмена и использования цифровых данных для систем вооружения и оборудования Министерства обороны. Более подробную информацию можно найти на странице CALS по адресу .
Зарегистрированные значения наборов символов. Загрузите список зарегистрированны значений по адресу .
"Каскадные таблицы стилей, уровень 2", Б. Бос, Х. В. Ли, К. Лилли и Я. Джейкобс, ноябрь 1997 г.
Находится по адресу
The Dublin Core: подробнее см. по адресу
"Этнология, языки мира", 12-е издание, Барбара Ф. Граймс, редактор, Летний институт лингвистики, октябрь 1992 г.
"Справочник по SGML", К. Ф. Голдфарб, Clarendon Press, 1991.
"Спецификация языка разметки гипертекстов, версия 3.0", Дейв Рэгетт, сентябрь 1995 г.
Находится по адресу .
"Спецификация HTML 3.2", Дейв Рэгетт, 14 января 1997 г.
Находится по адресу
"HTML и таблицы стилей", Б. Бос, Д. Рэгетт и Х. Ли, 24 марта 1997 г.
Находится по адресу
"Лексический анализатор для HTML и основного SGML", Д. Коннолли, 15 июня 1996 г. Находится по адресу
Platform for Internet Content (PICS). Подробнее см.
Язык описания ресурсов: подробнее см.
"Стандарт формата текстовых сообщений Интернет ARPA", пересмотрен Дэвидом Х. Крокером, август 1982 г.
Находится по адресу .
"Стандарт обмена сообщениями USENET", М. Хортон, июнь 1983.
Находится по адресу .
"Японская кодировка символов для сообщений Интернет", Дж. Мюрай, М. Криспин и Э. Ван дер Поль, июнь 1993 г.
Находится по адресу .
"Универсальные идентификаторы ресурсов в WWW: унифицированный синтаксис для выражения имен и адресов объектов в сети, используемый в World-Wide Web", Т. Бернерс-Ли, июнь 1994 г.
Находится по адресу .
[RFC1866]
"Язык разметки гипертекстов 2.0", Т. Бернерс-Ли и Д. Коннолли, ноябрь 1995 г.
Находится по адресу .
[RFC1867]
"Выгрузка файлов на базе форм в HTML", Э. Небель и Л. Масинтер, ноябрь 1995 г.
Находится по адресу . RFC1867 должен быть обновлен по адресу , в данный момент работа продолжается.
[RFC1942]
"Таблицы HTML", Дейв Рэгетт, май 1996 г.
Находится по адресу .
[RFC2048]
"Многоцелевые расширения почты Интернет (MIME) Часть четвертая: Процедуры регистрации", Н. Фрид, Дж. Кленсин и Дж. Постел, ноябрь, 1996 г.
Находится по адресу . Обратите внимание, что этот RFC новее RFC1521, RFC1522 и RFC1590.
[RFC2070]
"Интернационализация языка разметки гипертекстов", Ф. Ерго, Ж. Николь, Г. Адамс и М. Дюрст, январь, 1997 г.
Находится по адресу .
[SGMLOPEN]
Консорциум SGML. Обратитесь к странице Консорциума SGML по адресу
[SP]
SP - общедоступный синтаксический анализатор SGML.
Находится по адресу . Более подробную информацию можно найти по адресу .
[SQ91]
"The SGML Primer", 3-е издание, SoftQuad Inc., 1991.
[TAKADA]
"Обмен многоязыковой информацией через World-Wide Web", Тошихиро Такада, Компьютерные сети и системы ISDN, том 27, № 2, стр. 235-241, ноябрь 1994 г.
[WAIGUIDE]
Принципы разработки доступных документов HTML можно найти на Web-сайте Web Accessibility Initiative (WAI): .
[VANH90]
"Практическое руководство по SGML", Э. ван Хервайнен, Kluwer Academic Publishers Group, Norwell and Dordrecht, 1990.
Языки
Единственной нормативной версией является английская версия данного документа. Однако переводы этого документа можно найти по адресу http://www.w3.org/MarkUp/html40-updates/translations.html.
Элементы и атрибуты
Названия элементов представляются символами в верхнем регистре (например, BODY). Названия атрибутов представляются символами в нижнем регистре (например, lang, onsubmit). Помните, что в HTML имена элементов и атрибутов не учитывают регистр; это используется для более легкого чтения.
В названиях элементов и атрибутов в этом документе используется разметка, поэтому агентами пользователей они могут генерироваться особым образом.
В каждом определении атрибута устанавливается тип его значения. Если имеется несколько возможных значений, приводится список значений, разделенных вертикальной чертой (|).
После информации о типе в каждом определении атрибута в квадратных скобках ("[]") указывается, учитывается ли в значениях регистр. Подробнее см. раздел .
Кодировки символов
Кодировки символов в этой спецификации имеют другие названия в других спецификациях (что может вызвать некоторую путаницу). Однако это понятие в Интернет означает примерно одно и то же. Одно и то же имя -- "charset - набор символов" - используется в заголовках протоколов, атрибутах и параметрах, ссылающихся на символы и использующих одни и те же значения из реестра (полный список см. в разделе [CHARSETS]).
Параметр "charset" идентифицирует кодировку символов, которая является способом преобразования последовательности байт в последовательность символов. Это преобразование естественно вписывается в схему деятельности Web: серверы отправляют документы HTML агентам пользователей в виде потока байт; агенты пользователей интерпретируют их как последовательность символов. Способы преобразования могут меняться от простого соответствия один к одному до сложных схем или алгоритмов переключения.
Простой техники кодировки "один байт - один символ" недостаточно для текстовых строк с таким широким репертуаром символов, как [ISO10646]. Кроме кодировок всего набора символов (например, UCS-4), имеются некоторые другие кодировки частей [ISO10646].
Атрибуты "charset" (%Charset в DTD) относятся к кодировкам символов, как описано в разделе . Значениями должны быть строки (например, "euc-jp") из реестра IANA (полный список см. в [CHARSETS]).
Имена кодировок символов учитывают регистр.
Агенты пользователей для определения кодировки символов внешнего ресурса должны выполнять шаги, описанные в разделе .
Коды языков
Значения атрибутов, типом которых является код языка ( %LanguageCode в DTD), относится к коду языка, как указано в [RFC1766], раздел 2. Информацию об указании кодов языков в HTML см. в разделе коды языков. В кодах языков пробелы недопустимы.
Коды языков учитывают регистр.
Комбинации ссылок на символы
Чтобы дать авторам более инициативный способ использования символов, HTML предлагает набор character entity references. Комбинации ссылок на символы используют символические имена, так что авторам не придется запоминать коды. Например, комбинация å обозначает символ "a" нижнего регистра с кружком сверху; "å" легче запомнить, чем å.
HTML 4.0 не определяет character entity reference для каждого символа. Например, для кириллической буквы "I" нет character entity reference. См. определенные в HTML 4.0.
Комбинации ссылок на символы учитывают регистр. Так, Å указывает на другой символ (A с кружком верхнего регистра), а не на å (a с кружком нижнего регистра).
Четыре ссылки нужно упомянуть специально, поскольку они часто используются для указания специальных символов:
"<" представляет знак <. ">" представляет знак >. "&" представляет символ &. "" представляет знак ".
Авторы, которые хотят поместить в текст символ "<", должны использовать ссылку "<" (десятичный код ASCII 60) во избежание возможной путаницы с началом тэга (открывающий разделитель начального тэга). Точно так же следует использовать ">" (десятичный код ASCII 62) вместо ">", чтобы избежать проблем со старыми версиями агентов пользователей, некорректно принимающих их за окончание тэга (закрывающий разделитель тэга).
Авторам следует использовать "&" (десятичный код ASCII 38) вместо "&" во избежание путаницы со ссылками на символы (открывающий разделитель entity reference). Авторам также следует использовать "&" в значениях атрибутов, поскольку ссылки на символы внутри значений атрибута разрешены.
Некоторые авторы используют character entity reference """ для кодирования экземпляров двойных кавычек ("), поскольку этот символ может использоваться для разделения значений атрибутов.
Набор символов документа
Для обеспечения возможность взаимодействия сетей SGML требует от каждого приложения (включая HTML) указания набора символов документа. Документ включает:
Репертуар: Набор абстрактных символов,, таких как латинская буква "A", кириллическая буква "I", китайский иероглиф "вода" и т.д.
Коды: Набор целочисленных ссылок на символы репертуара.
Каждый документ SGML (включая каждый документ HTML) - это последовательность символов из репертуара. Компьютерные системы идентифицируют каждый символ по его коду; например, в наборе символов ASCII коды 65, 66 и 67 означают символы 'A', 'B' и 'C' соответственно.
Набора символов ASCII недостаточно для такой глобальной информационной системы, как Web, поэтому HTML использует более полный набор символов, называемый Универсальным набором символов (Universal Character Set - UCS), и определенный в [ISO10646]. Этот стандарт определяет репертуар тысяч символов, используемых во всем мире.
Набор символов, определенный в [ISO10646] - это посимвольный эквивалент Unicode 2.0 ([UNICODE]). Оба эти стандарта время от времени обновляются, пополняются новыми символами, об изменениях следует узнавать на соответствующих серверах Web. В этой спецификации ISO/IEC-10646 или Unicode означают этот самый набор символов. Однако в спецификации HTML Unicode также упоминается при обсуждении других вопросов, таких как
Набора символов документа, однако, недостаточно, чтобы агенты пользователей могли корректно интерпретировать документы HTML при типичном обмене - закодированные как последовательность байт в файле или во время передачи по сети. Агенты пользователя должны также знать кодировки символов, которые использовались для преобразования потока символов документа в поток байт.
Неотображаемые символы
Возможно, агент пользователя не сможет отобразить все символы в документе, например, из-за отсутствия соответствующего шрифта или если символ имеет значение, которое не может быть выражено во внутренней кодировке агента пользователя и т.д.
Поскольку в этом случае есть несколько вариантов, этот документ не предписывает определенной тактики. В зависимости от применения непечатные символы могут также обрабатываться дополнительной системой отображения, а не самим приложением. В случае более сложного поведения, например, настроенного для определенного сценария или языка, рекомендуем следующее поведение для агентов пользователей:
Примите явно видимый, но незаметный механизм для предупреждения пользователя об отсутствующих ресурсах. Если отсутствующие символы представляются в другом числовом представлении, используйте шестнадцатеричную (не десятичную) форму, поскольку эта форма используется в стандартах наборов символов.
Нормативные ссылки
"Каскадные таблицы стилей, уровень 1", Х. В. Ли и Б. Бос, 17 декабря 1996 г.
Находится по адресу
"Форматы дат и времени", Замечание W3C, М. Вольф и К. Уикстед, 15 сентября 1997 г.
Находится по адресу
"Назначенные номера", STD 2, RFC 1700, USC/ISI, Дж. Рейнольдс и Дж. Постел, октябрь 1994 г..
Находится по адресу
"Коды для представления названий языков", ISO 639:1988.
Подробнее см. .
См. также .
"Коды представления названий стран", ISO 3166:1993.
"Элементы данных и форматы обмена -- Обмен информацией -- Представление дат и времени", ISO 8601:1988.
"Обработка информации -- Текстовые и офисные системы -- Стандартный обобщенный язык разметки (SGML)", ISO 8879:1986.
Информацию о стандарте см. по адресу .
"Информационные технологии -- Универсальный набор символов с кодированием несколькими октетами (UCS) -- Часть 1: Архитектура и основная многоязыковая плоскость", ISO/IEC 10646-1:1993. Текущей спецификации также учтены первые пять изменений в ISO/IEC 10646-1:1993.
"Обработка информации -- графические наборы символов с 8-разрядным однобайтовым кодированием -- Часть 1: Латинский алфавит № 1", ISO 8859-1:1987.
Список зарегистрированных типов содержимого (типы MIME). Список зарегистрированных типов можно загрузить по адресу
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/.
"Ивритская кодировка символов для сообщений Интернет", Х. Нуссбахер и И. Бурвинь, декабрь 1993 г.
Находится по адресу .
"Обработка двунаправленных текстов в MIME", Х. Нуссбахер, декабрь 1993 г.
Находится по адресу .
"Универсальный адрес ресурса", Т. Бернерс-Ли, Л. Масинтер и М. МакКахилл, декабрь 1994 г.
Находится по адресу .
"Теги и идентификация языков", Х. Алвестранд, март 1995 г.
Находится по адресу .
[RFC1808]
"Относительные универсальные адреса ресурсов", Р. Филдинг, июнь 1995 г.
Находится по адресу .
[RFC2044]
"UTF-8, формат преобразования Unicode и ISO 10646", Ф. Ерго, октябрь 1996 г.
Находится по адресу .
[RFC2045]
"Многоцелевые расширения почты Интернет (MIME) Часть первая: формат тел сообщений Интернет", Н. Фрид и Н. Боренштейн, ноябрь 1996 г.
Находится по адресу . Обратите внимание, что этот RFC новее RFC1521, RFC1522 и RFC1590.
[RFC2046]
"Многоцелевые расширения почты Интернет (MIME) Часть вторая: Типы устройств", Н. Фрид и Н. Боренштейн, ноябрь 1996 г.
Находится по адресу . Обратите внимание, что этот RFC новее RFC1521, RFC1522 и RFC1590.
[RFC2068]
"HTTP версия 1.1 ", Р. Филдинг, Дж. Геттис, Дж. Могул, Х. Фрюстюк Нильсен и Т. Бернерс-Ли, январь 1997 г.
Находится по адресу .
[RFC2119]
"Ключевые слова для использования в RFC для указания уровня требований", С. Брэднер, март 1997 г.
Находится по адресу .
[RFC2141]
"Синтаксис URN", Р. Моутс, май 1997 г.
Находится по адресу .
[SRGB]
"стандартное простарнство цветов в Интернет по умолчанию", версия 1.10, М. Стоукс, М. Андерсон, С. Чандрасекар и Р. Мотта, 5 ноября 1996 г.
Находится по адресу
[UNICODE]
"Стандарт Unicode: версия 2.0", Консорциум Unicode, Addison-Wesley Developers Press, 1996 г. В этой спецификации также учтены ошибки в .
Подробнее см. на странице консорциума Unicode по адресу
[URI]
"Универсальные идентификаторы ресурсов (URI): Общий синтаксис и семантика", Т. Бернерс-Ли, Р. Филдинг, Л. Масинтер, 18 ноября 1997 г.
Находится по адресу . Работа над этим документом все еще идет, и обновления находятся по адресам и .
[WEBSGML]
"предложение TC для адаптации WebSGML для SGML", К. А. Голдфарб, ed., 14 июня 1997 г.
Находится по адресу
Определения
Документ HTML
Документ HTML - это документ SGML, отвечающий ограничениям, налагаемым данной спецификацией.
Автор
Автор - это человек или программа, пишущая или генерирующая документы в формате HTML. Средство разработки - это отдельный случай автора, а именно программа, генерирующая код HTML.
Мы рекомендуем авторам создавать документы, соответствующие строгому DTD, а не другим DTD, определяемым этой спецификацией. Подробнее о DTD, определенных в HTML 4.0, см. в разделе информация о версии.
Пользователь Пользователь - это человек, взаимодействующий с агентом пользователя для просмотра, прослушивания или другого использования сгенерированного документа в формате HTML.
Агент пользователя
Агент пользователя - это любое устройство, интерпретирующее документы в формате HTML. Агенты пользователя включают визуальные браузеры (текстовые и графические), невизуальные браузеры (аудио, Бройля), поисковые машины, прокси и т.д.
Соответствующий агент пользователя для HTML 4.0 - это агент, отвечающий обязательным условиям ("должно") этой спецификации, включая следующие:
Агент пользователя должен избегать наложения произвольных ограничений длины на литералы значений атрибутов (см. подраздел о возможностях в разделе ). Вводную информацию по атрибутам SGML можно получить в разделе определения атрибутов.
Агент пользователя должен гарантировать, что генерация изображения не изменяется в связи с наличием или отсутствием начальных и конечных тэгов, если в HTML DTD указывается, что они не обязательны. Вводную информацию об элементах SGML см. в разделе .
Для совместимости с предыдущими версиями мы рекомендуем, чтобы средства интерпретации HTML 4.0 поддерживали HTML 3.2 (см. [HTML32]) и HTML 2.0 (см. [RFC1866]).
Ошибочные состояния
В этой спецификации не определяется, как соответствующие ей агенты пользователя обрабатывают общие ошибочные состояния, включая действия в случае, если они встречают элементы, атрибуты, значения атрибутов или комбинаций, не указанные в этом документе.
Однако для получения информации о рекомендуемой обработке ошибок обратитесь к .
Нежелательные
Нежелательный элемент или атрибут - это элемент, устаревший вследствие применения новых конструкций. Нежелательные элементы определены справочного руководства и явно помечены как нежелательные. Нежелательные элементы могут устареть в будущих версиях HTML.
Агентам пользователя следует по-прежнему поддерживать нежелательные элементы для обеспечения совместимости с предыдущими версиями.
В определениях элементов и атрибутов явно указано, если они нежелательны.
В этой спецификации содержатся примеры, показывающие, как можно избежать использования нежелательных элементов. В большинстве случаев это зависит от поддержки агентом пользователя таблиц стилей. В общем случае, авторам следует использовать таблицы стилей для получения стилистических эффектов и эффектов форматирования вместо атрибутов представления HTML. Атрибуты представления HTML нежелательны, когда существует альтернатива таблиц стилей (см., например, [CSS1]).
Устаревшие
Устаревший элемент или атрибут - это элемент или атрибут, поддержка которых агентами пользователя не гарантируется. Устаревшие элементы не определяются в этой спецификации, но перечислены в справочного руководства.
Организация спецификации
Спецификация состоит из следующих разделов:
Разделы 2 и 3: Введение в HTML 4.0
Во введении описывается место языка HTML в схеме World Wide Web, приводится краткая история развития языка HTML, описывается, что можно сделать с использованием HTML 4.0 и содержатся некоторые подсказки относительно создания документов в формате HTML.
Краткое руководство по SGML дает читателям понимание отношения языка HTML к языку SGML и предоставляет информацию о чтении Определений типов документов HTML (Document Type Definition - DTD).
Разделы 4 - 24: Справочное руководство по HTML 4.0
Главным содержанием руководства является справочник по языку HTML, в котором определены все элементы и атрибуты языка.
Этот документ упорядочен по разделам, а не по грамматике языка HTML. Разделы сгруппированы в три категории: структура, представление и интерактивность. Хотя конструкции языка HTML трудно разделить на эти три категории, такая модель отражает опыт Рабочей группы HTML, говорящий о том, что разделение структуры документа и его представления обеспечивает большую эффективность документов и лучшие возможности поддержки.
Информация о языке включает следующую:
Какие могут отображаться в документе HTML.
Основные документа HTML.
Элементы, управляющие структурой документа HTML, включая , списки, , и .
Элементы, управляющие представлением документа в формате HTML, включая , шрифты, цвета, горизонтальные разделители и другое визуальное представление, а также .
Элементы, управляющие интерактивностью документа HTML, включая и .
Формальное SGML-определение HTML:
. Три DTD: , и . .
Приложения
В первом приложении содержится информация об изменениях по отношению к HTML 3.2 с целью помочь авторам при переносе файлов в формат HTML 4.0. Во втором приложении содержатся , целью которых является помощь разработчикам в создании средств для использования HTML 4.0.
Ссылки
Список нормативных и информативных документов.
Указатели
Три указателя предоставляют читателям быстрый доступ к определению: , элементы и атрибуты.
Ошибки
Список обнаруженных в спецификации ошибок находится по адресу
Об ошибках, найденных в этом документе, сообщайте по адресу www-html-editor@w3.org.
Основные типы данных HTML
В этом разделе спецификации описываются основные типы данных, которые могут быть содержимым элементов или значением атрибутов.
Вводную информацию о чтении HTML DTD см. раздел .
Основные типы SGML
В определяется синтаксис содержимого элемента HTML и значений атрибутов с использованием меток SGML (например, PCDATA, CDATA, NAME, ID и т.д.). Полные определения см. в [ISO8879]. Вот обобщенная информация о ключах:
CDATA - это последовательность символов из набора символов документа, она может включать character entities. Агенты пользователей должны интерпретировать значения атрибутов следующим образом:
Заменять character entities на символы, Игнорировать перевод строки, Заменять каждый возврат каретки или табуляцию на один пробел.
Агенты пользователей могут игнорировать пробелы в начале и в конце значений атрибута CDATA (например, "myval " интерпретируется как "myval"). Авторы не должны объявлять значения атрибутов с пробелами в начала или в конце.
На некоторые атрибутов HTML 4.0 со значениями атрибутов CDATA спецификация налагает дополнительные ограничения на множество допустимых значений атрибутов, не выраженные в DTD.
Хотя элементы и используют CDATA для своей модели данных, для этих элементов агенты пользователей должны обрабатывать CDATA по-другому. Разметка и entities должны считаться текстом и передаваться в приложение как есть. Первое вхождение последовательности символов "</" (открывающий разделитель конечного тэга) считается концом содержимого элемента. В допустимых документах это будет конечный тэг элемента.
Метки ID и NAME должны начинаться с буквы ([A-Za-z]), за которой может следовать любое число букв, цифр ([0-9]), символов переноса ("-"), символов подчеркивания ("_"), двоеточий (":") и точек (".").
IDREF и IDREFS - это ссылки на метки ID, определенные другими атрибутами. IDREF - одиночная метка, а IDREFS -разделенный пробелами список меток.
Метки NUMBER должны содержать по крайней мере одну цифру ([0-9]).
Отдельные символы
Определенные атрибуты вызывают отдельный символ из набора символов документа. Эти атрибуты имеют тип %Character в DTD.
Отдельные символы можно указать с помощью ссылок на символы (например, "&").
Представление документа в формате HTML
В этой главе обсуждается, как документы в формате HTML представляются на компьютере и в Интернет.
Раздел относится к вопросу об абстрактных символах, которые могут входить в состав документа в формате HTML. В число этих символов входят латинская буква "A", кириллическая буква "I", китайский иероглиф "вода" и т.д.
Раздел относится к вопросу о том, как эти символы могут быть представлены в файле или во время передачи по Интернет. Поскольку некоторые кодировки могут прямо не представлять все символы, которые автор захочет включить в документ, HTML предлагает другие механизмы, называемые , для ссылки на любой символ.
Поскольку в человеческих языках имеется огромное количество символов и множество способов их представления, следует позаботиться о том, чтобы эти документы могли понимать агенты пользователей во всем мире.
SGML
HTML 4.0 - это применение SGML, соответствующее международному стандарту ISO 8879 -- Standard Generalized Markup Language SGML (определенному в [ISO8879]).
Примеры в тексте соответствуют , если пример не относится к элементам или атрибутам, определенным или . Для краткости большая часть примеров в данной спецификации не начинается с , обязательного для начала любого документа в формате HTML.
Фрагменты DTD в определениях элементов приводятся из , кроме элементов, относящихся к кадрам.
Подробную информацию об использовании строгих, переходных DTD или DTD с кадрами см. в разделе .
Комментарии в не имеют нормативного значения; они используются только для информации.
Агенты пользователя не должны генерировать инструкции обработки SGML (например, <?full volume>) или комментарии. Подробнее об этой и других возможностях SGML, которые допустимы в HTML, но не поддерживаются широко агентами пользователя, обратитесь к разделу возможности SGML с ограниченной поддержкой.
Соглашения
Этот документ написан читателями с двумя типами мышления: авторами и разработчиками. Мы надеемся, что спецификация предоставит авторам средства, необходимые им для создания эффективных, привлекательных и доступных документов и не обременяющие их подробностями применения HTML. Разработчики, однако, должны найти здесь всю необходимую для разработки соответствующих средств информацию.
Эту спецификацию можно использовать несколькими способами:
Прочесть от начала до конца. Эта спецификация начинается с общего представления языка HTML, а количество технических подробностей постепенно повышается.
Обращаться к необходимой информации. Для обеспечения максимальной скорости получения информации о синтаксисе и семантике в оперативную версию спецификации включены следующие возможности:
Каждая ссылка на элемент или атрибут связана с его определением в спецификации. Каждый элемент или атрибут определяется только в одном месте.
На каждой странице имеются ссылки на указатели, поэтому Вы всегда сможете найти определение элемента или атрибута, использовав не больше двух ссылок.
На первых страницах трех разделов руководства к исходному оглавлению добавляется более подробная информация о каждом разделе.
Соответствие: требования и рекомендации
В этом разделе мы начинаем спецификацию HTML 4.0, начиная с договора между авторами, документами, пользователями и агентами пользователей.
Ключевые слова "НУЖНО", "НЕ НУЖНО", "НЕОБХОДИМО", "СЛЕДУЕТ", "НЕ СЛЕДУЕТ", "РЕКОМЕНДУЕТСЯ", "ВОЗМОЖНО" и "НЕОБЯЗАТЕЛЬНО" в этом документе следует интерпретировать, как описано в [RFC2119]. Однако для простоты чтения эти слова в данной спецификации напечатаны не в верхнем регистре.
Иногда авторы этой спецификации дают рекомендации для пользователей и их агентов. Эти рекомендации не являются нормативными и соответствие этой спецификации не зависит от их реализации. Эти рекомендации содержатся в выражениях "Мы рекомендуем...", "Эта спецификация рекомендует..." и подобных им.
Рекомендация W3C 18 декабря
Рекомендация W3C 18 декабря 1997
Автор перевода:
Оригинал данного перевода находится
Эта версия:
Последняя версия:
Предыдущая версия:
Редакторы: <>
<>
<>
Ссылки на символы
Данная кодировка символов может не содержать все символы из набора символов документа. Для таких кодировок или для таких конфигураций оборудования и программного обеспечения, не позволяющих пользователям вводить определенные символы, авторы могут использовать ссылки на символы SGML. Ссылки на символы - это независимый от кодировки механизм ввода любых символов.
Ссылки на символы в HTML могут принимать две формы:
Числовые ссылки на символы (десятичные или шестнадцатеричные). Ссылки на комбинации символов.
Ссылки на символы в комментариях не имеют значения; они являются только данными комментариев.
Примечание.
HTML обеспечивает другие способы представления символов, в частности, .
Примечание. В SGML можно в некоторых случаях не использовать заключительный символ ";" после ссылки на символы (например, в символе переноса строки или непосредственно перед тэгом). В других обстоятельствах их нельзя удалять (например, в середине слова). Мы предлагаем использовать ";" всегда во избежание проблем с агентами пользователей, для которых этот символ обязателен.
Статус данного документа
Данный документ просматривался членами W3C и другими заинтересованными лицами и организациями, и одобрен Директором в качестве Рекомендации W3C. Это постоянный документ; он может использоваться в качестве справочника или приводиться в других документах в качестве нормативного. Ролью W3C в этой рекомендации является привлечение внимания к этой спецификации и расширение сферы ее применения. Это расширяет функциональность и возможность взаимодействия в Web.
W3C рекомендует пользователям и авторам (в особенности средствам создания документов) использовать версию HTML 4.0 вместо HTML 3.2 (см. [HTML32]). Для обеспечения совместимости с предыдущими версиями W3C также рекомендует для средств интерпретации HTML 4.0 поддержку HTML 3.2 и HTML 2.0.
Список текущих Рекомендаций W3C и других технических документов можно найти по адресу .
Дискуссия относительно функций HTML происходит по адресу www-html@w3.org.
Текстовые строки
Ряд атрибутов ( %Text; в DTD) принимают текст, который предназначается для чтения людьми. Вводную информацию об атрибутах Вы можете посмотреть в .
Тип содержимого text/html
Документы HTML отправляются через Интернет в виде последовательности байтов, сопровождаемой информацией о кодировке (описанной в разделе кодировки символов). Структура передачи, называемая message entity, определяется [RFC2045]) и [RFC2068]. message entity с "text/html" представляет документ в формате HTML.
Тип содержимого для документов HTML определяется следующим образом:
Имя типа содержимого: text Имя подтипа содержимого: html Обязательные параметры: нет Необязательные параметры: charset Кодировка: разрешены все кодировки Безопасность: См.
Необязательный параметр "charset" обозначает кодировку символов, используемую для представления документа HTML в качестве последовательности байт. Допустимые значения этого параметра определены в разделе кодировки символов. Хотя этот параметр необязателен, рекомендуется всегда указывать его.
Типы содержимого (типы MIME)
Примечание. "Тип носителя" (определенный в [RFC2045] и [RFC2046]) указывает природу связанного ресурса. Эта спецификация использует термин "тип содержимого" вместо "типа носителя" в соответствии с его использованием. Более того, в этой спецификации "тип носителя" может означать на котором агент пользователя генерирует документ.
Этот тип представлен в DTD с помощью %ContentType;.
Типы содержимого учитывают регистр.
Примеры типов содержимого включают "text/html", "image/png", "image/gif", "video/mpeg", "audio/basic", "text/tcl", "text/javascript" и "text/vbscript". Текущий список зарегистрированных типов MIME см. в [MIMETYPES].
Примечание. Тип содержимого "text/css",, хотя он и не зарегистрирован в IANA, должен использоваться, если связываемым элементом является таблица стилей [CSS1].
Типы ссылок
Авторы могут использовать следующие распознаваемые типы ссылок, перечисленные здесь вместе с условными интерпретациями. В DTD означает список типов ссылок, разделенных пробелами. Символы пробелов в типах ссылок не допускаются.
Эти типы ссылок не учитывают регистр, т.е. "Alternate" означает то же, что и "alternate".
Агенты пользователей, поисковые машины и т.д. могут интерпретировать эти типы ссылок несколькими способами. Например, агенты пользователя могут предоставлять доступ к связанным документам с помощью навигационной панели.
Alternate
Обозначает альтернативные версии документа, в котором находится ссылка. Вместе с атрибутом означает переведенную версию документа. Вместе с атрибутом означает версию, созданную для другого носителя.
Stylesheet
Обозначает внешнюю таблицу стилей. Подробнее см. раздел о . Используется вместе с типом ссылки "Alternate" для таблиц стилей, выбираемых пользователем.
Start
Обозначает первый документ в наборе. Этот тип ссылки сообщает поисковым машинам о том, какой документ автор считает началом набора.
Next
Обозначает следующий документ в линейной последовательности документов. Агенты пользователей могут предварительно загружать документ "next" для сокращения времени загрузки.
Prev
Обозначает предыдущий документ в упорядоченной серии документов. Некоторые агенты пользователей также поддерживают синоним "Previous".
Contents
Обозначает документ, служащий содержанием. Некоторые агенты пользователей также поддерживают синоним ToC (из "Table of Contents").
Index
Обозначает документ, являющийся указателем текущего документа.
Glossary
Обозначает документ - глоссарий терминов, относящихся к текущему документу.
Copyright
Обозначает замечание об авторском праве для текущего документа.
Chapter
Обозначает документ, являющийся главой в наборе документов.
Section
Обозначает документ, являющийся разделом в наборе документов.
Subsection
Обозначает документ, являющийся подразделом в наборе документов.
Appendix
Обозначает документ, являющийся приложением в наборе документов.
Help
Обозначает документ, содержащий справку (более подробная информация, ссылки на другие информационные ресурсы и т.д.)
Bookmark
Обозначает закладку. Закладка - это ссылка на ключевую точку в расширенном документе. Атрибут может использоваться, например, для пометки закладки. Помните, что в каждом документе можно определить несколько закладок.
Авторы могут определить дополнительные типы ссылок, не описанные в этой спецификации. При этом они должны использовать для указания соглашений, используемых для определения типов ссылок. Подробнее см. атрибут элемента .
Дальнейшее обсуждение типов ссылок см. в разделе .
Указание кодировки символов
Как сервер определяет, какая кодировка символов применяется в документе? Некоторые серверы проверяют первые несколько байт документа или сверяются с базой данных известных файлов и кодировок. Многие современные серверы Web предоставляют администраторам больше возможностей управления конфигурацией набора символов, чем старые серверы. Администраторы серверов Web должны при возможности использовать следующие механизмы для отправки параметра "charset", но должны позаботиться о том, чтобы не установить для документов ошибочное значение параметра "charset".
Как агент пользователя узнает, какая использовалась кодировка символов? Эту информацию предоставляет сервер. Лучшим способом проинформировать агента пользователя о кодировке символов документа - использовать параметр "charset" в поле заголовка "Content-Type" протокола HTTP ([RFC2068], разделы 3.4 и 14.18) Например, следующий заголовок HTTP объявляет, что используется кодировка EUC-JP:
Content-Type: text/html; charset=EUC-JP
Определение text/html см. в разделе .
Протокол HTTP ([RFC2068], раздел 3.7.1) считает ISO-8859-1 кодировкой символов по умолчанию, если параметр "charset" в поле заголовка "Content-Type" отсутствует. На практике эта рекомендация бесполезна, поскольку некоторые серверы не позволяют отправлять параметр "charset", а некоторые могут не быть сконфигурированы для отправки этого параметр. Поэтому агенты пользователей не должны предполагать никакого значения параметра "charset".
Для указания ограничений сервера или конфигурации документы HTML могут включать явную информацию о кодировке символов документа; для предоставления такой информации агентам пользователя может использоваться элемент .
Например, чтобы указать, что кодировкой символов в текущем документе является "EUC-JP", включите следующее объявление :
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
Объявление должно использоваться, только если кодировка символов упорядочена так, что символы ASCII стоят на своем месте (по крайней мере, при разборе элемента ). Объявления должны быть в тексте как можно раньше в элементе .
В случаях, когда ни протокол HTTP, ни элемент не предоставляют информации о кодировке документа, HTML предоставляет атрибут для некоторых элементов. Объединив все эти механизмы, автор может существенно повысить шансы на то, что, когда пользователь загружает ресурс, агент пользователя распознает кодировку символов.
Подводя итоги, соответствующие агенты пользователей при определении кодировки символов документа (от высшего приоритета к низшему) должны руководствоваться следующими источниками в соответствии с приоритетом:
Параметр "charset" протокола HTTP в поле "Content-Type".
Объявление , в котором для "http-equiv" установлено "Content-Type" и установлено значение для "charset".
Атрибут устанавливается на элемент, обозначающий внешний ресурс.
Кроме этого списка приоритетов, агент пользователя может использовать эвристические установки и установки пользователя. Например, многие агенты пользователей используют эвристику для распознавания различных кодировок, используемых для японского языка. Агенты пользователей обычно имеют определяемую пользователем локальную кодировку по умолчанию, которую они используют, если нет указаний кодировки.
Агенты пользователей могут обеспечивать механизм, позволяющий пользователям изменять некорректную информацию о наборе символов. Однако если агент пользователя предлагает такой механизм, он должен предлагать его только для просмотра, а не для изменения, во избежание создания Web-страниц с некорректным параметром "charset".
Примечание.
Если в каком-то приложении нужно использовать символы, не входящие в кодировку [ISO10646], этим символам должна быть назначена персональная зона во избежание конфликтов с настоящей или будущими версиями стандарта. Однако это не рекомендуется из соображений переносимости.
URI
В этой спецификации термин URI используется, как определено в [URI] (см. также [RFC1630]).
Помните, что URI включают URL (как определено в [RFC1738] и [RFC1808]).
Относительные URI разрешаются до полных URI с использованием основного URI. [RFC1808], раздел 3, где определен нормативный алгоритм этого процесса. Подробнее об основных URI см. в разделе в главе о ссылках.
URI представляются в DTD комбинацией символов %URI;.
URI вообще учитывают регистр. Могут быть URI, или части URI, в которых регистр не имеет значения (например, имена машин), но идентификация их может быть непроста. Пользователи должны всегда считать, что URI учитывают регистр (чтобы не ошибиться).
Информацию о см. в приложении.
Данная спецификация определяет HyperText Markup
Данная спецификация определяет HyperText Markup Language (Язык разметки гипертекстов - HTML) версии 4.0 - язык, который используется для публикаций в World Wide Web. Кроме текстовых, мультимедийных возможностей и гиперссылок, присутствующих в предыдущих версиях языка HTML, HTML 4.0 поддерживает новые мультимедийные возможности, скрипты, таблицы стилей, улучшенную печать и более доступные людям с физическими недостатками документы. В версии HTML 4.0 также успешно реализована интернационализация документов, целью которой является сделать Паутину действительно всемирной.
HTML 4.0 - это приложение SGML, соответствующее Международному стандарту ISO 8879 -- Standard Generalized Markup Language [ISO8879].
Выбор кодировки
Средства разработки (например, текстовые редакторы) могут кодировать документы HTML в кодировках по своему выбору, и этот выбор существенно зависит от соглашений, используемых системным программным обеспечением. Эти средства могут использовать любую удобную кодировку, включающую большинство символов в документе, при условии, что кодировка Некоторые символы, не включенные в эту кодировку, можно представить с помощью . Это всегда относится к набору символов документа, а не к кодировке символов.
Серверы и прокси могут изменять кодировку символов (что называется транскодированием) на лету для выполнения запросов агентов пользователей (см. раздел 14.2 [RFC2068], заголовок запроса HTTP "Accept-Charset"). Серверы и прокси не должны обслуживать документ в кодировке, включающей весь набор символов документа.
Широко используемые в Web кодировки - ISO-8859-1 (также называется "Latin-1"; используется для большинства западноевропейских языков), ISO-8859-5 (с поддержкой кириллицы), SHIFT_JIS (японская кодировка), EUC-JP (еще одна японская кодировка) и UTF-8 (вариант кодировки ISO 10646, использующий разное число байт для разных символов). Названия кодировок символов не учитывают регистр, так что, например, "SHIFT_JIS", "Shift_JIS" и "shift_jis" эквивалентны.
Эта спецификация не определяет, какие кодировки символов должен поддерживать агент пользователя.
должны корректно отображать в Unicode все символы в любых кодировках, которые они могут распознавать.
Замечания и примеры
Информативные замечания выделены, чтобы отличаться от остального текста и могут генерироваться агентами пользователей особым образом.
Все примеры, иллюстрирующие нежелательное использование, помечены как "ПРИМЕР НЕЖЕЛАТЕЛЬНОГО ИСПОЛЬЗОВАНИЯ". В примеры нежелательного использования входят также рекомендуемые альтернативные решения. Все примеры, иллюстрирующие недопустимое использование, помечены как "ПРИМЕР НЕДОПУСТИМОГО ИСПОЛЬЗОВАНИЯ".
В примерах и замечаниях используется разметка, поэтому некоторыми агентами пользователей они могут генерироваться особым образом.
Замечания об использовании цветов
Хотя цвета могут существенно добавлять информации в документ и повышать удобство чтения, при использовании цветов имейте в виду следующие основные принципы:
Использование элементов и атрибутов HTML для указания цвета нежелательно. Вместо этого следует использовать .
Не используйте комбинации цветов, вызывающие проблемы у пользователей.
Если Вы используете изображение в качестве фона или устанавливаете цвет фона, не забудьте становить и цвета текста.
Цвета, указанные в элементах и и в в таблицах выгладят по-разному на разных платформах (на рабочих станциях, Mac, Windows и на панелях LCD и CRT), поэтому не рассчитывайте на определенный эффект. В будущем поддержка цветовой модели [SRGB] вместе с цветовыми профилями ICC должна устранить эти проблемы.
При возможности принимайте общие соглашения.
Замечания об определенных кодировках
Когда текст HTML передается в UTF-16 (charset=UTF-16), текстовые данные должны передаваться в сетевом порядке байт ("big-endian", байт высшего порядка - первый) в соответствии с [ISO10646], раздел 6.3 и [UNICODE], положение C3, страница 3-1.
Более того, чтобы повысить вероятность правильной интерпретации, рекомендуется передавать документы UTF-16, всегда начиная с символа НЕРАЗДЕЛЯЮЩИЙ ПРОБЕЛ НУЛЕВОЙ ШИРИНЫ (шестнадцатеричный код FEFF, также называется Меткой порядка байтов (Byte Order Mark - BOM)), который при обращении байт становится шестнадцатеричным FFFE, никогда не назначаемым символом. Таким образом, агент пользователя, получивший шестнадцатеричный код FFFE в качестве первых байтов текста будет знать, что в остальном тексте байты нужно обратить.
Не следует использовать формат трансформации UTF-1[ISO10646] (зарегистрированный IANA как ISO-10646-UTF-1). Информацию об ISO 8859-8 и двунаправленном алгоритме см. в разделе .
