Синтаксис html и структура html-документа. Основы языка HTML В основу синтаксиса языка html лег стандарт

, , ,

.

Если открывающий тег содержит один или несколько атрибутов, то тег должен указываться обязательно.

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

До и после доктайпа разрешается вставлять любое количество пробелов или комментариев. Таким образом, доктайп не обязательно должен располагаться в первой строке кода.

В примере 1 показан минимальный код HTML для вывода традиционного приветствия.

Пример 1. Минимальный HTML

HTML5 IE Cr Op Sa Fx

Привет, мир!

Метка порядка байтов состоит из кода символа U+FEFF в начале документа, где она используется для определения кодировки. Рекомендуется убирать этот символ, поскольку его наличие приводит к ошибкам отображения документа в некоторых браузерах. Для этого можно использовать редактор Notepad++, в меню «Кодировки» выбрать пункт «Кодировать в UTF-8 (без BOM)» (рис. 3).

Рис. 3. Выбор кодировки

• Подробнее о метке порядка байтов
  http://unicode.org/faq/utf_bom.html#bom1
• Редактор Notepad++

В языке HTML5 впервые было введено понятие DOM (хотя он существовал и до этого, однако он не был частью языка) , теперь HTML-документ рассматривается как набор обектов, а не тегов. Поэтому как такого синтаксиса HTML5 не существует. Однако при написании кода вы можете придерживаться правил разметки тегов , которые были установлены в HTML 4.01 или XHTML 1.0

В HTML до пятой версии, существовало несколько правил написания кода:

В XHTML , существовало два правила написания кода:

При использовании HTML5, написав в начале HTML-документа, доктайп , вы можете использовать любой из перечисленных выше синтаксисов языка (правил написания кода) или даже совмещать HTML 4.01 и XHTML 1.0 друг с другом.

Например не обрамлять кавычками значения атрибутов атрибут=значение (свободный режим HTML 4.01 — loose) , но в тоже время ставить слеш в одиночных тегах
(строгий режим ХHTML 1.0 — strict) .

Опытные HTML-верстальщики обычно используют при написании кода на HTML5, строгий синтаксис XHTML strict , поскольку он держит верстальщика в тонусе, не позволяет ему расслабляться и тем самым оберегает его от возможных ошибок в коде. Также использование строгого синтаксиса пригодится при изучении программирования, ибо там строгость синтаксиса, крайне важна.

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

Для XML-документов этот алгоритм ПАгенты должны использовать для определения кодировки символов, заданной XML-спецификацией. Этот раздел не применяется к XML-документам.

Когда HTML-парсер работает с байтовым потоком ввода, имеющим определённую известную кодировку, тогда кодировка символов – эта кодировка, а – certain .

В некоторых случаях может быть нецелесообразно однозначно определять кодировку до разбора документа. По этой причине данная спецификация предоставляет двух шаговый механизм с опционным предварительным сканированием. В реализациях разрешается, как описано ниже, применять упрощённый алгоритм парсинга к каким бы то ни было доступным байтам до начала парсинга документа. Затем реальный парсер стартует, с использованием предварительного кодирования, взятого из этого предварительного парсинга и других out-of-band метаданных. Если, пока документ загружается, ПА обнаруживает объявление кодировки символов, которое конфликтует с этой информацией, тогда парсер может снова вызван для выполнения парсинга документа с реальной кодировкой.

ПАгенты должны должны использовать ниже следующий алгоритм, называемый алгоритм снифинга кодировки, для определения кодировки символов для использования при декодировании документа в первом шаге. Этот алгоритм принимает в качестве ввода любые out-of-band метаданные, доступные ПАгенту (например, Content-Type метаданные документа), и все доступные до сих пор байты, и возвращает кодировку символов и , которая tentative или certain .

Если пользователь явно указывает ПАгенту переопределить кодировка символов документа особой кодировкой, опционно возвратить эту кодировку с certain

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

ПА может больше доступных байтов ресурса либо на этом шаге, либо на более позднем шаге этого алгоритма. Например, ПА может ожидать 500ms или 1024 байт, смотря что будет первым. В целом предварительный парсинг ресурса для определения кодировки повышает производительность, так как это уменьшает необходимость отбрасывать структуры данных, используемых при парсинге после поиска информации кодировки. Однако, если ПА слишком затягивает с получением данных для определения кодировки, затраты времени на ожидание могут превысить любой выигрыш от препарсинга.

Требования соответствия для декларации кодировки символов ограничивают её появление только в рамках первых 1024 байт . ПАгентам, следовательно, рекомендуется использовать алгоритм предварительного сканирования (далее) как вызванный этими шагами на первых 1024 байтах, но не останавливаться на этом.

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

Этот шаг ищет Unicode Byte Order Marks (BOMs).

То, что этот шаг идёт перед следующим, соблюдающим HTTP-хедэр Content-Type , является умышленным нарушение спецификации HTTP, что объясняется желанием быть максимально совместимым со старым содержимым.

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

UTF-8 кодирование имеет точно определяемый битовый патэрн. Документы, содержащие байты более 0x7F, совпадающие с UTF-8 патэрном, весьма вероятно, являются UTF-8, а документы с байтовыми последовательностями, не совпадающими с ним – очень вероятно, что нет. ПАгентам, следовательно, рекомендуется искать эту общую кодировку.

Иначе – возвратить определяемую реализацией или пользователем кодировка символов по умолчанию, с – tentative .

В управляемых окружениях или в окружениях, где кодировка документов может быть предписана (например, для ПАгенты, предназначенных конкретно для использования в новых сетях), рекомендуется исчерпывающая кодировка UTF-8 .

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

Содержимое этой таблицы выведено из умолчаний Windows, Chrome и Firefox.

Любой другой байт

Ничего не делать с этим байтом.

Поддержка кодировок на базе EBCDIC особенно не рекомендуется. Эта кодировка редко используется для публичного вэб-содержимого. Поддерживать UTF-32 также настоятельно не рекомендуется. Эта кодировка редко используется и часто некорректно реализуется.

Данная спецификация не пытается поддерживать кодировки на базе EBCDIC и UTF-32 в своих алгоритмах; поддержка и использование этих кодировок, следовательно, может дать непредсказуемое поведение в реализациях данной спецификации.

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

Поток ввода состоит из символов, протолкнутых в него как декодированный или из различных API, которые напрямую манипулируют потоком ввода.

Один ведущий символ U+FEFF BYTE ORDER MARK должен быть игнорирован, если они присутствуют в .

Требование вырезать символ U+FEFF BYTE ORDER MARK, независимо от того, использовался ли этот символ для определения порядка байтов, является умышленным нарушением Unicode, которое объясняется желанием повысить устойчивость ПАгентов в плане собственных транскодеров.

Любые появления любых символов из диапазонов от U+0001 до U+0008, от U+000E до U+001F, от U+007F до U+009F, от U+FDD0 до U+FDEF и символов U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE и U+10FFFF являются . Все они – управляющие символы или перманентно неопределённые/undefined Unicode-символы(несимволы/noncharacters).

Символы "CR" (U+000D) и "LF" (U+000A) рассматриваются особо. Все символы CR должны быть конвертированы в символы LF, а любые символы LF, которые идут после символа CR, должны игнорироваться. Таким образом, новые строки/newlines в HTML DOM представлены символами LF и никогда – символами CR во вводе к этапу .

Следующий символ ввода это первый символ в , который ещё не использован/consumed или явно игнорируется требованиями этого раздела. Начально это первый символ в потоке ввода. Текущий символ ввода это последний символ, который был .

Точка вставки/точка вставки это позиция (непосредственно перед символом или непосредственно перед концом потока ввода), где содержимое, вставленное с использованием document.write() , реально вставляется. Точка вставки является относительной к позиции символа сразу после неё, это не абсолютное смещение в потоке ввода. Начально точка вставки не определена/undefined.

Символ "EOF" в последующих таблицах это концептуальный символ, представляющий конец . Если парсер это парсер, созданный скриптом , тогда конец достигается, когда используется явный символ "EOF" (вставленный методом document.close()). Иначе символ "EOF" – это не реальный символ в потоке, а обозначение отсутствия любых последующих символов.

Обработка символов U+0000 NULL варьируется в зависимости от того, где символы находятся. В целом они игнорируются, кроме случаев, когда это может реально подставить по удар. Такая обработка, по необходимости, распространяется на стадии мнемонизации и построения дерева.