Тема 01

Веб и HTML: основы

Веб и HTML: основы

Курс начинается с языка разметки HTML — фундамента, на котором держится клиентская часть любого веб-приложения. Прежде чем перейти к самому языку, обратимся к контексту: что такое веб, как устроена доставка документа от сервера к браузеру, какие организации стандартизируют веб-технологии. Эти сведения часто остаются за рамками курсов фронтенд-разработки, но без них непонятно, почему HTML устроен именно так и почему современные практики выглядят как выглядят.

Базовые понятия веба

Гипертекст и гипермедиа

Гипертекст (англ. hypertext) — это методика связи электронных текстовых документов с помощью интерактивных элементов — гиперссылок (англ. hyperlink), позволяющая читателю самостоятельно выбирать последовательность просмотра. По размещённым в тексте ссылкам читатель переходит к другим документам или к иным фрагментам того же документа; порядок такого перемещения он определяет сам.

Идея нелинейного чтения возникла ещё в докомпьютерную эпоху, но воплощение в современном виде стало возможным с развитием вычислительной техники. Термин гипертекст был введён математиком и философом Тедом Нельсоном в 1965 году в докладе «Complex Information Processing: A File Structure for the Complex, the Changing and the Indeterminate» 1. Несколько позже тем же автором был предложен расширенный термин гипермедиа (англ. hypermedia) — концепция распространялась не только на текст, но и на другие виды электронного контента, — однако в обиходе закрепился именно первоначальный вариант.

Идеи Нельсона при его непосредственном участии воплотились в проекте гипертекстовой системы Xanadu, которая существует по сей день, но сколь-либо значимого распространения не получила. Несмотря на это, сама концепция гипертекста оказалась востребованной — особенно в научной среде, где она облегчала поиск и консолидацию больших объёмов информации.

Всемирная паутина: от идеи до современного состояния

В 1989 году в Европейской организации по ядерным исследованиям (фр. Organisation européenne pour la recherche nucléaire; аббревиатура CERN сохранилась от исторического названия Conseil Européen pour la Recherche Nucléaire — временного совета 1952–1954 годов) исследователи Тим Бернерс-Ли и Роберт Кайо работали над информационной системой для структурирования служебной информации с использованием гипертекста 2. Результатом стал язык разметки документов HyperText Markup Language (HTML) и протокол передачи данных HyperText Transfer Protocol (HTTP). Параллельно Бернерс-Ли предложил концепцию Всемирной паутины (англ. World Wide Web, WWW) — распределённой системы доступа к семантически связанным документам, расположенным на разных компьютерах единой сети, — а также написал первый в мире HTTP-сервер httpd и программу-клиент, веб-браузер (англ. web browser) WorldWideWeb (позднее переименованный в Nexus, чтобы избежать путаницы с самой паутиной).

К 1992 году благодаря распространению вычислительной техники и стандартизации межсетевого обмена набирала обороты тенденция укрупнения университетских и исследовательских сетей в единую глобальную сеть. Её прообразом была ARPANET (1969), созданная по заказу Министерства обороны США; опорной магистралью, объединившей региональные сети в гражданский Internet, стала NSFNet (1985) — сеть Национального научного фонда США (англ. National Science Foundation, NSF). Концепция WWW была удачно имплементирована как сервис в развивающейся глобальной сети, а базовая механика — «пользователь вводит в браузере адрес HTML-документа (URL) → используя протокол HTTP, браузер отправляет запрос по этому URL на веб-сервер → веб-сервер возвращает HTML-документ» — практически без изменений используется по сей день.

URL и HTTP как основа доступа к ресурсам

Бернерс-Ли также является автором Uniform Resource Locator (URL) — единообразного указателя местонахождения ресурса. URL представляет собой последовательность символов, определяющую протокол передачи данных, доменное имя и путь к конкретному ресурсу:

https://example.org/articles/intro.html?lang=ru#section-2

В этом адресе различимы пять частей: схема (https), хост (example.org), путь (/articles/intro.html), параметры запроса (?lang=ru) и фрагмент (#section-2). Параметры запроса позволяют передавать дополнительные данные между клиентом и сервером, фрагмент адресует часть документа на стороне клиента и серверу не отправляется.

HTTP — это прикладной протокол по схеме «запрос — ответ». Клиент (браузер) отправляет запрос, описывающий желаемое действие методом (GET, POST, PUT, PATCH, DELETE) и адресом, а сервер возвращает ответ со статус-кодом и телом сообщения. Подробное рассмотрение протокола, методов, статус-кодов и заголовков мы отложим до темы 8, посвящённой API-клиенту; пока ограничимся пониманием, что HTTP — основной транспорт, по которому браузер получает HTML-документы, изображения, стили и скрипты.

В разговорной практике термины «HTTP-сервер» и «веб-сервер» часто используются как синонимы и обозначают программный продукт, реализующий работу с протоколом HTTP (nginx, Apache httpd, Caddy). При необходимости уточняют контекст: говорят о веб-сервере как о хосте (физической или виртуальной машине) с установленным на нём HTTP-сервером и обслуживаемым контентом, либо как о самом ПО.

Архитектура браузера: движок, рендеринг, JavaScript-интерпретатор

Веб-браузер — это клиентское приложение, которое получает доступ к веб-страницам и отображает их пользователю. Современные браузеры являются очень сложными программными продуктами; их архитектура может различаться в деталях, но как правило включает следующие компоненты:

  • пользовательский интерфейс (англ. user interface, UI) — адресная строка, меню навигации, меню закладок и т. д.;
  • движок браузера (англ. browser engine) — согласует действия между пользовательским интерфейсом и движком рендеринга;
  • движок рендеринга (англ. rendering engine) — отвечает за отображение контента: разбирает (парсит) HTML и CSS и отображает результат на экране;
  • модуль сетевого взаимодействия (англ. networking module) — обслуживает сетевые вызовы (например, HTTP-запросы);
  • бэкенд пользовательского интерфейса (англ. UI backend) — отрисовывает базовые виджеты (выпадающие списки, поля ввода, флажки), абстрагируя различия операционных систем;
  • интерпретатор JavaScript, JavaScript-движок (англ. JavaScript engine) — парсит и выполняет код на JavaScript;
  • модуль хранения данных (англ. Data storage module) — отвечает за локальное хранение файлов cookie, данных Web Storage, IndexedDB и т. п.

Изучение устройства браузеров не является целью курса, но для лучшего понимания процессов веб-разработки полезно ознакомиться со статьями Tali Garsiel 3 и Mariko Kosaka 4.

На момент подготовки пособия наиболее распространённые браузеры (по данным независимой службы анализа веб-трафика StatCounter) перечислены ниже.

Логотип Google Chrome
Google Chrome

Chrome использует движок рендеринга Blink (форк WebKit) и высокопроизводительный JavaScript-движок V8. Реализована многопроцессная архитектура: каждая вкладка работает в отдельном процессе, что повышает стабильность и облегчает изоляцию (sandboxing). Технология Site Isolation изолирует сайты друг от друга в памяти. Chrome активно поддерживает передовые веб-стандарты — WebAssembly, WebRTC, PWA, HTTP/3.

Логотип Apple Safari
Apple Safari

Safari работает на движке WebKit, который Apple оптимизирует для производительности и энергоэффективности на macOS и iOS. JavaScript исполняется движком JavaScriptCore (Nitro). Safari ориентирован на низкое энергопотребление и поддерживает Intelligent Tracking Prevention (ITP) — систему защиты от отслеживания. Safari известен консервативным подходом к внедрению новых веб-стандартов, из-за чего разработчикам приходится учитывать его ограничения.

Логотип Microsoft Edge
Microsoft Edge

С 2020 года Microsoft Edge основан на Chromium и использует те же Blink и V8, что и Chrome; ранее работал на собственном движке EdgeHTML. Edge обеспечивает более низкое потребление оперативной памяти благодаря системе Sleeping Tabs и поддерживает технологию Application Guard для виртуализации вкладок. На основе Chromium Edge поддерживает практически все современные веб-стандарты и расширения из Chrome Web Store.

Логотип Mozilla Firefox
Mozilla Firefox

Firefox использует движок Gecko и JavaScript-движок SpiderMonkey. Технология Quantum обеспечивает многопоточный рендеринг. Firefox традиционно играет роль независимой реализации стандартов, не привязанной к Chromium, и активно поддерживает WebAssembly, WebRTC, HTTP/3, TLS 1.3, а также расширения на основе WebExtensions API.

Стандартизация: W3C, WHATWG, HTML как Living Standard

Одна из ключевых организаций, отвечающих за стандартизацию веб-технологий, — W3C (World Wide Web Consortium). W3C — международная организация, основанная в 1994 году Тимом Бернерсом-Ли. Её основная задача — разработка и продвижение стандартов, обеспечивающих развитие интернета как открытой и доступной среды. Члены W3C включают крупные IT-компании (Google, Microsoft, Apple, Mozilla), академические учреждения и независимых экспертов. W3C разрабатывает спецификации, известные как W3C Recommendations, которые становятся официальными стандартами после обсуждения и тестирования. Эти рекомендации охватывают HTML, CSS, DOM, WCAG, Web APIs, SVG, Semantic Web и другие технологии.

Разработка нового стандарта проходит несколько этапов: Working Draft (черновик) → Candidate Recommendation (кандидат в рекомендации) → Proposed Recommendation (предложенная рекомендация) → W3C Recommendation (официальная рекомендация).

Параллельно с W3C над стандартами веба работает консорциум WHATWG (Web Hypertext Application Technology Working Group), основанный в 2004 году разработчиками браузеров Apple, Mozilla и Opera в ответ на медленный темп работы W3C. Современный HTML развивается именно в WHATWG, как непрерывно обновляемый Living Standard, без зафиксированных «версий». Ранее принятая нумерация (HTML 4.01, HTML5) сегодня используется скорее как маркетинговый и методический ярлык; формальный источник истины — спецификация WHATWG. Долгое время W3C и WHATWG публиковали параллельные, местами расходящиеся версии HTML и DOM, что создавало путаницу для разработчиков. В 2019 году организации подписали соглашение, по которому WHATWG стал единственным держателем спецификаций HTML и DOM, а W3C сосредоточилась на других направлениях — CSS, WCAG, Web APIs.

Несмотря на разработанные стандарты, разные браузерные движки интерпретируют код несколько по-разному, поэтому веб-страницы могут выглядеть в браузерах не идентично. Это породило практики кросс-браузерной вёрстки и кросс-браузерного тестирования. В 2021 году основные производители браузеров инициировали проект Compat 2021, направленный на улучшение совместимости. Годом позже стартовал Interop 2022, в рамках которого вендоры договорились поэтапно доводить поддержку заранее оговорённого объёма веб-технологий до идентичной работы во всех браузерах. Год за годом расхождения сокращаются.

Язык HTML и его роль

HTML как язык разметки контента, а не оформления

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

Наглядный пример — теги <h1> и <p>, размечающие заголовок и абзац:

<h1>Великолепный заголовок</h1>
<p>Не менее потрясающий абзац.</p>

Браузер отобразит:

Заголовок и абзац, отрендеренные браузером по умолчанию
Результат отображения заголовка и абзаца с применением браузерных стилей по умолчанию

Несмотря на то, что текст заголовка и абзаца визуально различается, сам HTML не позволяет управлять начертанием, кеглем, отступами и прочими параметрами отображения. Для этого служит язык стилизации CSS, который мы рассмотрим в теме 2. Различие в отображении <h1> и <p> объясняется тем, что браузер применяет к ним собственный стиль по умолчанию (англ. user-agent stylesheet).

Здесь и далее под HTML-документом мы будем понимать код на языке HTML, помещённый в файл с расширением .html или .htm, а под веб-страницей — результат рендера этого документа браузером, с применением CSS-стилизации и исполняемого JavaScript-кода, если они были использованы.

Структура HTML-элемента: открывающий и закрывающий теги, атрибуты, содержимое

Рассмотрим структуру HTML-элемента на примере элемента <a> (англ. anchor, якорь), который предназначен для создания ссылок.

Схема HTML-элемента: открывающий тег с атрибутами, содержимое, закрывающий тег
Структура HTML-элемента: открывающий тег с атрибутами, содержимое, закрывающий тег

HTML-элемент состоит из:

  • открывающего и закрывающего тегов (<a> и </a>);
  • атрибутов в открывающем теге — пар вида имя="значение", описывающих параметры элемента. Многие атрибуты применимы ко всем элементам, но часть атрибутов специфична для конкретных тегов. Полный перечень атрибутов, определённых стандартом, доступен в справочнике MDN;
  • содержимого — текста или вложенных элементов, к которым применяется тег.

У тега <a> ключевой атрибут — href (англ. hypertext reference), задающий адрес перехода. В значении допустим не только веб-URL: href="mailto:author@example.org" откроет почтовый клиент, href="tel:+79991234567" — приложение для звонка, href="#section-2" прокрутит страницу к элементу с id="section-2". Атрибут target="_blank" открывает ссылку в новой вкладке; при этом в rel принято указывать noopener (и для надёжности noreferrer), иначе целевая страница получает через window.opener доступ к текущей — потенциальная уязвимость.

Парные и пустые элементы

Тег <a> является парным: его открывающая и закрывающая части обрамляют содержимое. Однако существуют и пустые (англ. void) элементы, у которых нет содержимого и нет закрывающего тега. Типичные примеры — изображение <img>, перенос строки <br>, горизонтальная линия <hr>, поле ввода <input>, метатег <meta>, ссылка на ресурс <link>. Такие элементы целиком описываются одним тегом и набором атрибутов:

<img src="logo.svg" alt="Логотип компании">
<input type="email" name="contact" required>
<meta charset="UTF-8">

В XHTML и XML-совместимой записи подобные теги принято завершать косой чертой (<br />) — отсюда ещё одно распространённое название, «самозакрывающиеся» (англ. self-closing). В современном HTML5 слеш в пустом теге парсером допускается, но игнорируется и на поведение не влияет, поэтому такая запись считается избыточной.

Комментарии

Любой фрагмент HTML можно заключить в комментарий вида <!-- ... -->. Содержимое комментария не отображается на странице и не влияет на разметку, но видно в исходном коде и в DevTools. Комментарии используются для пояснений в разметке (обозначить начало секции, оставить TODO для команды) и временного отключения участков, которые жалко удалять окончательно. Главное ограничение — комментарии нельзя вкладывать друг в друга: парсер закроет внешний на первой же встреченной последовательности -->, и остаток уйдёт в обычный текст страницы.

Вложенность элементов и иерархическая модель документа

HTML позволяет вкладывать одни элементы в другие, образуя иерархическую структуру страницы. Вложенность важна для правильного отображения и логической организации контента. Пример:

<div id="el-1">
    Элемент 1
    <div id="el-2">
        Элемент 2
    </div>
    <div id="el-3">
        Элемент 3
    </div>
</div>

После небольшой стилизации браузер отобразит это так:

Три вложенных контейнера: внешний и два внутренних
Вложенность HTML-элементов: внешний контейнер и два внутренних

По отношению к элементам 2 и 3 элемент 1 является родительским, а элементы 2 и 3 — дочерними по отношению к элементу 1. Совокупность таких отношений образует дерево документа: каждый элемент имеет ровно одного родителя (кроме корневого) и любое количество дочерних элементов. Это дерево лежит в основе всей последующей работы — на нём строятся CSS-селекторы, на нём же стоит DOM, через который JavaScript манипулирует страницей (тема 7).

Хорошим тоном при написании HTML-кода является явная демонстрация вложенности через отступы (англ. indent), как показано в примере выше. Современные редакторы и форматировщики делают это автоматически.

Структура HTML-документа

Каждый HTML-документ имеет определённую структуру, состоящую из обязательных и вспомогательных элементов. Рассмотрим базовый пример:

<!DOCTYPE html>
<html lang="ru">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Вдохновляющий заголовок страницы</title>
</head>
<body>
    <h1>Великолепный заголовок</h1>
    <p>Не менее потрясающий абзац.</p>
</body>
</html>

<!DOCTYPE> и режим стандартов

<!DOCTYPE> (document type) — объявление типа документа, в котором указывается тип и версия языка разметки для корректной обработки последующего содержимого браузером. Правильное объявление типа критически важно: при его отсутствии или некорректной форме браузер переходит в режим совместимости (англ. quirks mode), имитирующий поведение старых версий браузеров. Это сделано, чтобы не сломать унаследованные сайты двадцатилетней давности, но почти гарантированно приведёт к неправильной интерпретации актуального HTML- и CSS-кода.

В современной практике используется HTML5, которому соответствует лаконичная инструкция <!DOCTYPE html> — её и следует ставить первой строкой любого нового документа. Для более старых версий HTML и XHTML существовали свои громоздкие формы записи, которые сегодня встречаются только в исторических документах.

Проверить разметку на соответствие спецификации можно официальным валидатором W3C — validator.w3.org. Он принимает URL, файл или фрагмент кода и возвращает перечень нарушений: незакрытые теги, недопустимая вложенность, неизвестные атрибуты, проблемы с доступностью. Прогонять через валидатор готовые страницы — полезная привычка: часть ошибок браузеры молча «прощают», но они всплывают позже в виде странных артефактов рендера или проблем с доступностью.

Корневой элемент <html>, атрибуты lang и dir

<html> — корневой элемент, внутри которого размещается весь контент страницы. Из его атрибутов в практике важны прежде всего:

  • lang — указывает язык содержимого документа. В нашем примере значение "ru" соответствует русскому языку. Атрибут позволяет браузеру корректно применить типографические правила (вид кавычек, расстановка переносов), а ассистивным технологиям — выбрать правильный движок синтеза речи. Указывать lang — обязательная практика;
  • dir — направление текста: ltr (слева направо, значение по умолчанию) или rtl (справа налево, для арабского, иврита и др.).

Раздел <head>: кодировка, viewport, заголовок, подключение ресурсов

<head> содержит метаинформацию о документе, не отображаемую как контент страницы. Типовое наполнение:

  • <meta charset="UTF-8"> — кодировка документа. UTF-8 сегодня является де-факто стандартом, обеспечивающим корректное отображение символов любых письменностей;
  • <meta name="viewport" content="width=device-width, initial-scale=1.0"> — управляет масштабом страницы на мобильных устройствах. Без этого тега мобильные браузеры покажут страницу в режиме «как на настольном компьютере» с уменьшенным масштабом, что для современных адаптивных сайтов нежелательно;
  • <title> — заголовок страницы, отображается на вкладке браузера, в результатах поиска и в подписях ссылок при шаринге;
  • <link rel="stylesheet" href="styles.css"> — подключение внешнего файла со стилями;
  • <script src="script.js" defer></script> — подключение внешнего JavaScript-файла. Атрибут defer откладывает выполнение скрипта до построения дерева документа. Скрипт может подключаться и в <body> (обычно в самом конце, чтобы не блокировать рендер контента), но современная практика — размещать <script> в <head> с атрибутом defer или async. Для ES-модулей используется запись <script src="script.js" type="module"></script>; подробнее о модулях — в теме 6.

Раздел <body>: видимый контент страницы

<body> содержит основное содержимое веб-страницы — текст, изображения, ссылки, формы, мультимедиа. Всё, что пользователь увидит на странице, должно располагаться здесь. У <body> нет жёстких ограничений на состав, кроме одного: внутри <body> не размещают теги, относящиеся к разделу <head> (например, <meta> или <title>).

Базовые блочные и строчные элементы

Поток документа — естественный порядок размещения элементов перед применением стилей. Браузер рендерит HTML сверху вниз, располагая элементы в порядке их появления в коде. Этот процесс называется нормальным потоком документа.

По умолчанию браузер размещает элементы в одном из двух базовых режимов, определяемом типом элемента:

  • блочные (англ. block) элементы занимают всю доступную ширину родительского контейнера и начинаются с новой строки, располагаясь друг под другом. Даже если ширина блочного элемента явно задана и рядом мог бы поместиться такой же, в потоке они выстраиваются один под другим. Блочные элементы могут содержать как другие блочные, так и строчные элементы. Примеры: <div>, <p>, <h1><h6>, <section>;
  • строчные (англ. inline) элементы занимают только необходимую ширину и не создают разрывов строк. Несколько строчных элементов стремятся уместиться на одной строке, насколько хватает ширины родителя; при недостатке ширины текст переносится на следующую строку. Как правило, строчные элементы содержат текст или другие строчные элементы; из этого правила есть исключения (например, у <a> в HTML5 прозрачная модель содержимого, и он может оборачивать блочные элементы), но на первых порах ориентироваться на упрощённое правило удобно. Примеры: <span>, <a>, <q>, <code>.

Нормальный поток и его поведение мы детально рассмотрим в теме 3, посвящённой layout. Пока достаточно понимать, что разделение на блочные и строчные элементы — это базовая настройка отображения, которую затем можно переопределить с помощью CSS.

В HTML возможно использование специальных символов — мнемоник (англ. named character references). В первую очередь они нужны для знаков, конфликтующих с синтаксисом самого HTML: &lt;, &gt;, &amp;. Кроме того, мнемоники вроде &copy; (©), &mdash; (—), &nbsp; (неразрывный пробел) исторически применялись для типографических символов, отсутствующих на клавиатуре. При кодировке UTF-8 все эти знаки можно и удобнее записывать в исходнике напрямую; мнемоника &nbsp; остаётся востребованной, поскольку сам неразрывный пробел в коде визуально неотличим от обычного.

Семантическая разметка

Зачем нужна семантика: доступность, SEO, ассистивные технологии

Семантическая разметка — способ структурирования веб-страницы с использованием элементов, которые ясно передают смысл их содержимого. Большинство HTML-тегов уже несут семантическую нагрузку: <h1> отмечает заголовок первого уровня, <p> — абзац, <ul> — ненумерованный список. В HTML5 были добавлены специальные секционирующие теги — <header>, <nav>, <main>, <section>, <article>, <aside>, <footer> — позволяющие выразить не только смысл отдельных фрагментов, но и общую структуру страницы.

Семантичная разметка преследует три практические цели:

  • доступность (англ. accessibility): ассистивные технологии, в первую очередь программы чтения с экрана (англ. screen reader), используют семантическую разметку для построения навигации по странице. Пользователь скринридера может перейти к следующему <h2> или попасть в основной блок <main> одной командой — но только если эти элементы расставлены;
  • поисковая оптимизация (англ. Search Engine Optimization, SEO): поисковые роботы используют семантическую разметку для понимания иерархии и важности контента;
  • сопровождаемость кода: разметка с осмысленными именами тегов читается быстрее, чем сплошное полотно из <div>.

Секционирующие элементы: header, nav, main, article, section, aside, footer

Секционирующие теги используются для определения структуры страницы и организации контента в крупные смысловые блоки:

  • <header> — заголовочная часть страницы или отдельного раздела;
  • <nav> — основная навигация сайта;
  • <main> — основной контент страницы (уникальный для каждой страницы; на странице должен быть ровно один такой элемент);
  • <section> — логически связанный раздел контента;
  • <article> — независимый контент, который имеет смысл и вне страницы (статья, пост блога, карточка товара);
  • <aside> — боковой блок с дополнительной информацией, связанной с основным контентом косвенно (врезки, сноски, справочные блоки);
  • <footer> — нижняя часть страницы или раздела с контактами, копирайтом, ссылками.

Пример типового использования:

<header>
    <h1>Название отличного сайта</h1>
    <nav>
        <ul>
            <li><a href="/">Главная</a></li>
            <li><a href="/about">О нас</a></li>
        </ul>
    </nav>
</header>
<main>
    <section>
        <h2>Наши услуги</h2>
        <p>Мы предоставляем лучшие решения.</p>
    </section>
    <aside>
        <h3>Полезные ссылки</h3>
        <ul>
            <li><a href="/blog">Блог</a></li>
            <li><a href="/contacts">Контакты</a></li>
        </ul>
    </aside>
</main>
<footer>
    <p>&copy; 2026 Все права защищены.</p>
</footer>

Текстовые и групповые элементы: figure, figcaption, details, summary, dialog

Помимо секционирующих, в HTML5 есть набор текстовых и групповых элементов для разметки отдельных смысловых единиц:

  • <figure> — контейнер для иллюстраций, схем, фотографий, фрагментов кода, таблиц, на которые ссылается основной текст;
  • <figcaption> — подпись к содержимому <figure>, обычно первый или последний дочерний элемент;
  • <details> и <summary> — раскрывающийся блок: пользователь видит <summary>, а развёрнутое содержимое <details> показывается по клику. Готовая встроенная функциональность аккордеона без JavaScript;
  • <dialog> — модальное или немодальное диалоговое окно, открываемое через DOM-метод showModal(). Современная замена ручных реализаций модальных окон поверх <div>;
  • <mark> — выделение фрагмента, который требует внимания читателя (например, найденный поиском текст);
  • <time> — дата или время в машинно-читаемой форме (<time datetime="2026-04-22">22 апреля 2026</time>);
  • <address> — контактная информация автора или владельца раздела;
  • <cite> — указание на источник или название цитируемой работы;
  • <blockquote> — блочная цитата большого объёма.

Пример сочетания нескольких контентных элементов:

<article>
    <figure>
        <img src="cover.jpg" alt="Обложка статьи">
        <figcaption>Обложка статьи</figcaption>
    </figure>
    <p>Дата публикации: <time datetime="2026-04-22">22 апреля 2026</time></p>
    <details>
        <summary>Аннотация</summary>
        <p>Краткое содержание статьи, раскрываемое по клику.</p>
    </details>
</article>

Сравнение семантичной разметки и «div-ада»

Среди всех HTML-элементов отдельно стоит выделить <div>. Этот элемент — конструкционный контейнер: он не несёт семантического значения и без стилизации невидим для пользователя. Та же страница, что в примере выше, могла бы быть собрана исключительно на <div>:

<div>
    <h1>Название отличного сайта</h1>
    <div>
        <ul>
            <li><a href="/">Главная</a></li>
            <li><a href="/about">О нас</a></li>
        </ul>
    </div>
</div>
<div>
    <div>
        <h2>Наши услуги</h2>
        <p>Мы предоставляем лучшие решения.</p>
    </div>
</div>
<div>
    <p>&copy; 2026 Все права защищены.</p>
</div>

Визуально после рендера обе страницы могут выглядеть идентично. Но, как несложно заметить, разметка на сплошных <div> менее читаема, и — что важнее — она негативно влияет на SEO и доступность: поисковые роботы и скринридеры теряют возможность понять, где здесь шапка, где навигация, а где основной контент. Подобная практика получила в индустрии полуироничное название «div-ад» (англ. div soup) и считается антипаттерном. Простое правило: если для смыслового блока существует подходящий семантический тег — использовать его, а к <div> прибегать там, где нужен именно конструкционный контейнер для целей вёрстки.

Метаинформация документа

Метатеги управления рендерингом и индексацией

Раздел <head> помимо подключения ресурсов содержит набор метатегов, передающих браузеру и внешним системам сведения о документе. Среди практически значимых:

  • <meta name="description" content="..."> — короткое описание страницы, используемое поисковыми системами в качестве сниппета в результатах поиска. В пределах 150–160 символов;
  • <meta name="robots" content="index, follow"> — инструкция поисковым роботам: индексировать ли страницу и переходить ли по ссылкам с неё. Значения noindex, nofollow исключают страницу из индекса или запрещают переход по её ссылкам;
  • <link rel="canonical" href="..."> — указание канонического URL страницы. Используется, когда одна и та же страница доступна по нескольким адресам, чтобы поисковые системы не считали их дубликатами;
  • <link rel="icon" href="favicon.svg"> — пиктограмма страницы во вкладке браузера, в избранном, в результатах поиска.

Встречающийся в старой разметке <meta http-equiv="X-UA-Compatible" content="IE=edge"> относился к режимам совместимости Internet Explorer; с выводом IE из поддержки в 2022 году тег стал историческим артефактом и в новой разметке не нужен.

Метатег <meta name="keywords"> исторически использовался для перечисления поисковых запросов, по которым автор хотел бы видеть страницу в выдаче. Современные поисковые системы его игнорируют — он остался как памятник эпохе массового SEO-спама.

Системы разметки метаданных

Помимо базовых метатегов, которые читают сами браузеры и поисковые роботы, существует ряд внешних систем разметки — протоколов и словарей, с помощью которых страница сообщает о себе сторонним сервисам: соцсетям, мессенджерам, агрегаторам, поисковым движкам. Технически все они выражаются через те же <meta> и <link> в <head> либо через атрибуты прямо на содержательной разметке, но логически это отдельный слой «разметки про разметку».

Задачи, которые решают такие системы, сводятся к двум:

  • сформировать превью при публикации ссылки — карточку с заголовком, описанием и изображением в соцсетях, мессенджерах, поисковых сниппетах (этим занимается протокол Open Graph и родственные ему Twitter Cards);
  • описать содержимое страницы как структурированные сущности — товар, событие, рецепт, организацию, статью — в формате, который поисковые системы могут использовать для расширенных сниппетов и агрегаций (этим занимаются словарь schema.org и форматы его записи: JSON-LD, Microdata, RDFa).

Доступность на уровне разметки

Доступность (англ. accessibility, a11y) — свойство веб-страницы быть пригодной к восприятию пользователями с разными возможностями: незрячими и слабовидящими, людьми с моторными или когнитивными нарушениями, пользователями в условиях плохой сети или нестандартного устройства ввода. Практически это означает, что страница должна корректно работать не только при визуальном просмотре мышью, но и при навигации клавиатурой, при озвучивании программой чтения с экрана (англ. screen reader), при увеличенном масштабе, при контрастной теме. Разработка с учётом доступности — не отдельная опция для узкой аудитории, а часть нормального качества продукта: те же приёмы, которые делают страницу пригодной для скринридера, улучшают её SEO, облегчают автоматическое тестирование и делают интерфейс устойчивее к нестандартным условиям использования.

Международный стандарт доступности — Web Content Accessibility Guidelines (WCAG), разрабатываемый W3C в рамках инициативы WAI (Web Accessibility Initiative). WCAG определяет четыре базовых принципа — воспринимаемость, управляемость, понятность, надёжность — и формулирует проверяемые критерии соответствия на трёх уровнях: A, AA (целевой для большинства публичных сайтов) и AAA. Дополняет стандарт спецификация WAI-ARIA, описывающая роли (role), состояния и свойства (aria-*), которыми размечаются кастомные интерактивные виджеты, когда встроенной семантики HTML недостаточно.

На уровне разметки грамотная доступность держится на нескольких простых подходах: логический порядок элементов в HTML соответствует порядку, в котором контент должен восприниматься (CSS может переупорядочить его визуально, но скринридер читает исходник); заголовки <h1><h6> образуют последовательную иерархию и работают для скринридера как навигация; семантические теги используются вместо анонимных <div> (см. предыдущий раздел); у каждого <img> задан осмысленный alt (пустой alt="" — явный сигнал декоративности, отсутствующий атрибут — ошибка). Действует устойчивая формулировка, известная как первое правило ARIA: «Не используйте ARIA, если можно обойтись нативным HTML-элементом». Нативные <button>, <a>, <input> из коробки получают правильную семантику, поведение клавиатуры и фокус — ARIA нужен только там, где этих средств недостаточно.

Базовую проверку доступности дают бесплатные инструменты, доступные прямо в браузере: расширение axe DevTools, встроенный в Chrome DevTools аудит Lighthouse, вкладка Accessibility с деревом доступности. Они быстро ловят типовые нарушения, но не заменяют ручной проверки клавиатурой и реальным скринридером, которая остаётся стандартом.

Итоги темы

Веб-страница — это конечный результат цепочки «URL → HTTP-запрос → HTML-документ → рендер браузером». В этой цепочке HTML играет роль базового языка, описывающего структуру и смысл контента, тогда как оформление и поведение возложены на CSS и JavaScript. Современный HTML — это Living Standard, поддерживаемый WHATWG; его развитие синхронизируется с реализациями в основных браузерных движках (Blink, WebKit, Gecko) через инициативы вроде Interop.

Корректная разметка строится из трёх слоёв: правильная структура документа (DOCTYPE, <html>, <head>, <body>), осмысленный выбор семантических тегов вместо сплошных <div> и согласованная метаинформация. Поверх этой основы накладывается забота о доступности: логический порядок элементов, иерархия заголовков, осмысленные атрибуты alt, минимально необходимое использование ARIA. Эти решения принимаются на самом раннем этапе и стоят дёшево, если о них помнить с первой строки разметки, и дорого — если возвращаться к ним постфактум.

В следующей теме мы перейдём к языку CSS и научимся управлять оформлением страницы, сохраняя смысловую структуру, заложенную здесь.

Литература

  1. Nelson T. H. A File Structure for the Complex, the Changing and the Indeterminate. — Proceedings of the 1965 20th National Conference, 1965, С. 84–100, DOI: 10.1145/800197.806036.
  2. Berners-Lee T. Information Management: A Proposal. — CERN, 1989, https://www.w3.org/History/1989/proposal.html.
  3. Garsiel T., Irish P. How browsers work: Behind the scenes of modern web browsers. — 2011, http://taligarsiel.com/Projects/howbrowserswork1.htm.
  4. Kosaka M. Inside look at modern web browser. — 2018, https://developer.chrome.com/blog/inside-browser-part1.

Дополнительные материалы

Базовые понятия веба

  • Doka: URL — подробный русскоязычный разбор структуры URL: схема, authority, путь, query-параметры, фрагмент, абсолютные и относительные формы, практические замечания о кодировании. Удобное расширение соответствующего подраздела основного текста.
  • MDN: Что такое URL? — учебная статья MDN с пошаговым разбором частей URL на русском языке, с примерами использования разных схем (http, https, mailto, ftp) и ролью порта.
  • URL Living Standard (WHATWG) — первоисточник современной спецификации URL: формальное определение компонентов, алгоритм парсинга, правила нормализации, percent-encoding. Нужен, когда требуется разрешить пограничный случай, в котором справочники MDN/Doka оставляют недосказанность.
  • URI — сложно о простом (Хабр) — разбор соотношения URI, URL и URN с опорой на RFC 3986: откуда взялись эти термины, чем различаются, как соотносятся их грамматики. Помогает снять типичную путаницу между понятиями.
  • Как разобрать URL в JavaScript? (Хабр) — практический обзор конструктора URL() и API URLSearchParams: парсинг, валидация, работа с query-параметрами. Полезно для перехода от теоретической структуры URL к её использованию в клиентском коде.
  • WHATWG — сайт консорциума, разрабатывающего HTML Living Standard. Здесь же — DOM, Fetch, URL и другие базовые спецификации, на которые ссылается вся остальная платформа.
  • W3C — сайт W3C со списком рабочих групп и актуальных спецификаций (CSS, WCAG, ARIA, SVG). Полезен как точка входа, когда нужно уточнить статус конкретного стандарта.
  • Browser market share (StatCounter) — актуальная статистика распространённости браузеров по странам и типам устройств. Имеет смысл сверяться при принятии решений о кросс-браузерной поддержке.

Язык HTML и его роль

  • HTML Living Standard (WHATWG) — первоисточник по HTML: полная спецификация всех элементов, атрибутов, алгоритмов парсинга. Написана языком стандарта, но остаётся единственной авторитетной точкой для спорных вопросов.
  • MDN: HTML — русскоязычная справочная документация по HTML-элементам и атрибутам с примерами и заметками о поддержке браузерами. Основной ежедневный справочник фронтенд-разработчика.
  • Doka: HTML — русскоязычный путеводитель по HTML от сообщества: короткие статьи по каждому тегу и атрибуту в объяснительном стиле, с практическими примерами и типичными ошибками.

Структура HTML-документа

  • MDN: атрибуты HTML — полный перечень глобальных и специфичных для элементов атрибутов с описанием поведения и ограничений. Удобно, когда нужно уточнить список допустимых значений или поддержку конкретного атрибута.
  • Quirks Mode and Standards Mode (MDN) — объяснение, чем режим совместимости отличается от стандартного режима, какие DOCTYPE во что переключают и какие именно поведения ломаются в quirks mode.
  • HTML Living Standard: именованные символьные мнемоники — справочная таблица всех именованных HTML-сущностей (&amp;, &copy;, &mdash; и т. д.) с кодами символов. Используется как шпаргалка при типографической доводке текста.

Семантическая разметка

  • HTML Living Standard: Sections — раздел спецификации о секционирующих элементах: формальные определения <article>, <section>, <nav>, <aside>, алгоритм построения outline документа. Снимает типовые споры о том, какой тег уместен в конкретном месте.
  • MDN: справочник HTML-элементов — алфавитный перечень всех HTML-элементов со ссылками на подробные страницы. Удобная точка входа, когда известно только приблизительное назначение тега.
  • <article> vs. <section>: How To Choose The Right One (Smashing Magazine) — прикладной разбор различий между <article> и <section>: когда уместен каждый тег, как они влияют на дерево доступности и какие ошибки типичны при их сочетании. Помогает снять основную неопределённость при выборе секционирующего элемента.

Метаинформация документа

  • Open Graph protocol — официальная спецификация протокола Open Graph: перечень свойств og:*, типы объектов, требования к изображениям. Основной источник при настройке превью страницы для соцсетей и мессенджеров.
  • schema.org — общий словарь типов и свойств, используемый всеми тремя синтаксисами структурированной разметки (Microdata, RDFa, JSON-LD). Справочник, к которому обращаются при описании сущностей вроде Product, Article, Event, Organization.
  • Google Search Central: Введение в структурированные данные — русскоязычное руководство Google о назначении структурированной разметки, поддерживаемых форматах (с приоритетом JSON-LD) и связанных возможностях поисковой выдачи (rich results). Прагматичная точка входа в тему.
  • Сложный и противоречивый мир синтаксиса микроразметки. Опыт Яндекса (Хабр) — разбор истории появления Microdata, RDFa, JSON-LD и microformats, их сильных и слабых сторон с точки зрения поискового движка. Полезен, чтобы понять, почему существует несколько параллельных стандартов.
  • JSON-LD 1.1 (W3C Recommendation) — формальная спецификация JSON-LD: модель данных, контексты, алгоритмы расширения и сжатия. Первоисточник, когда нужно разобраться в тонкостях формата за пределами типовых примеров.
  • HTML Microdata (W3C) — спецификация синтаксиса Microdata: атрибуты itemscope, itemtype, itemprop, правила вложенности. Ссылка нужна, если приходится поддерживать или мигрировать существующую разметку на Microdata.

Доступность на уровне разметки

  • Web Accessibility Initiative (W3C WAI) — портал W3C по доступности: стандарты (WCAG, ARIA), руководства для авторов и разработчиков, образовательные материалы. Отправная точка для погружения в тему a11y.
  • WCAG 2.1 Quick Reference — интерактивный чеклист критериев WCAG 2.1 с фильтрами по уровню соответствия (A / AA / AAA) и техникам реализации. Рабочий инструмент для самопроверки страницы.
  • Doka: доступность — русскоязычная подборка статей по a11y: практические приёмы, типовые ошибки, разбор ARIA-паттернов. Хороший мост между общими принципами WCAG и конкретной вёрсткой.

Браузерные DevTools

  • Chrome DevTools (официальная документация) — исчерпывающий справочник по панелям DevTools: Elements, Console, Sources, Network, Performance, Memory, Application, Lighthouse. Основной источник, когда нужно разобраться в конкретной функции или горячей клавише.
  • Firefox DevTools User Docs — аналогичная документация по инструментам разработчика Firefox. Полезна для сравнения: часть фич (инспектор grid, editor для CSS shapes) исторически появлялись в Firefox раньше, чем в Chrome.
  • Консоль разработчика (learn.javascript.ru) — русскоязычное введение в DevTools от Ильи Кантора: как открыть, как смотреть ошибки, основы работы с консолью. Подходит для первого знакомства.
  • Обзор Chrome DevTools. Решаем основные задачи разработчика (HTML Academy) — русскоязычный практический тур по DevTools с типовыми сценариями: правка CSS «на лету», отладка JS, анализ запросов, аудит Lighthouse. Хорошо дополняет официальную документацию конкретными задачами.
  • Профессиональное применение инструментов разработчика Chrome: 13 советов (Хабр) — подборка менее очевидных возможностей DevTools: снимки покрытия кода, условные брейкпоинты, копирование объектов, эмуляция сетевых условий. Помогает вывести использование DevTools за пределы базовой правки CSS.
Окружение практического занятияzip

Практическое занятие 1. Семантическая разметка дашборда «Личный кабинет магистранта»

Объём: 2 академических часа

Раздел курса: тема 1 «Введение в веб-стек, HTML, семантика»

Введение

Первое занятие — точка входа в работу с референсным проектом «Личный кабинет магистранта». Референсный проект используется в практикуме до того момента, пока у магистранта не появится собственный согласованный с научным руководителем макет; начиная с этого момента занятия идут уже на собственном проекте магистранта. На этом занятии мы намеренно ограничиваемся одним пластом — структурой документа: ни CSS, ни JavaScript ещё не подключаются. Такое ограничение позволяет увидеть, как браузер интерпретирует чистый HTML, какие user-agent-стили он применяет по умолчанию и почему семантика тегов имеет значение задолго до того, как появляется визуальное оформление.

Цель работы

Собрать семантичный HTML-каркас главной страницы дашборда по Figma-макету и освоить базовый инструментарий фронтенд-разработчика: Emmet в редакторе, DevTools в браузере, валидатор разметки.

После выполнения работы магистрант сможет:

  • разметить страницу-дашборд семантическими тегами HTML5 и обосновать выбор тегов для каждого блока;
  • использовать Emmet для разворачивания типовых конструкций разметки;
  • проводить аудит DOM-дерева и применённых user-agent-стилей в DevTools;
  • проходить Nu Html Checker без ошибок и осознанно принимать предупреждения;
  • сдавать работу через Merge Request в личном GitLab-проекте.

Теоретический минимум

Часть материала уже разобрана в теме и здесь сводится к короткой отсылке; остальное вводится прямо в задании, потому что в лекции не раскрывалось.

Из лекционного материала

  • Структура HTML-документа: <!DOCTYPE>, корневой элемент <html> с атрибутами lang и dir, разделы <head> и <body> — см. учебное пособие, тема 1, раздел «Структура HTML-документа».
  • Секционирующие элементы <header>, <nav>, <main>, <article>, <section>, <aside>, <footer> и правила их вложенности — там же, раздел «Семантическая разметка», подраздел «Секционирующие элементы».
  • Текстовые и групповые элементы <figure> / <figcaption>, <details> / <summary>, <dialog> — там же, подраздел «Текстовые и групповые элементы».
  • Метатеги charset, viewport, description — раздел «Метаинформация документа».

Инструментарий, вводимый на занятии

Редактор и Emmet. Рабочий редактор курса — VS Code (подойдёт и любой другой с поддержкой Emmet: WebStorm, Sublime Text, Zed). Emmet — плагин с набором сокращений, позволяющих разворачивать в валидный HTML целые фрагменты разметки одним нажатием Tab. В VS Code встроен без дополнительной установки.

Несколько базовых паттернов Emmet:

  • ! + Tab → полный HTML5-каркас с <!DOCTYPE>, <html lang>, <head> с <meta charset> и <meta viewport>, <title>, пустым <body>;
  • div.card + Tab → <div class="card"></div>;
  • section#disciplines>h2+ul>li*6 + Tab → секция с заголовком и списком из шести пустых <li>;
  • header>nav>ul>li.nav-item*5>a + Tab → каркас шапки с навигацией из пяти пунктов;
  • article.card>h3{$$}+p*2 + Tab → карточка с нумерованным заголовком и двумя параграфами;
  • оборачивание уже существующего HTML в тег — команда Emmet: Wrap with Abbreviation (Shift+Ctrl+P → ввод команды).

Emmet избавляет от набора закрывающих тегов и атрибутов руками; осваивается за один вечер и дальше экономит часы. Подробный справочник — docs.emmet.io/cheat-sheet.

Браузерные DevTools. Инструменты разработчика встроены во все современные браузеры. Открываются F12 или Ctrl+Shift+I (Cmd+Opt+I в macOS). Вкладки, нужные на этом занятии:

  • Elements — дерево DOM после парсинга. Показывает реальную структуру документа, который отрисовал браузер (не путать с исходным текстом). Используется, чтобы проверить вложенность тегов, наличие непарных и ненужных элементов, разобраться в чужой вёрстке.
  • Styles (панель справа от Elements) — стили, применённые к выбранному элементу, включая user-agent styles — браузерные стили по умолчанию. Блок user agent stylesheet показывает, почему, например, у <body> отступ 8 px или у <ul> — маркеры и padding, хотя мы CSS не подключали. Эти стили станут предметом практического занятия 2.
  • Network — список всех HTTP-запросов страницы. Полезно, чтобы увидеть, какие ресурсы (изображения, шрифты) на самом деле подгружаются.
  • Sources → Page — исходный HTML-текст страницы до парсинга. Сравнение Elements и Sources показывает, какие ошибки разметки браузер «молча» починил.

DevTools — основной рабочий инструмент фронтенд-разработчика; на каждом следующем занятии к нему будут добавляться новые вкладки и сценарии. Подробно — developer.chrome.com/docs/devtools.

Nu Html Checker. Эталонный валидатор разметки W3C, доступен на validator.w3.org/nu. Принимает URL, загруженный файл или вставленный текст. Сообщения делятся на Error (нарушение спецификации — должно быть исправлено) и Warning (предупреждение о сомнительной практике — может быть принято осознанно). Для сдачи занятия нужны 0 ошибок; предупреждения допустимы при объяснении в отчёте.

Перечень оснащения

  • VS Code 1.90+ либо аналог с поддержкой Emmet.
  • Chrome 120+ или Firefox 120+.
  • Установленный git, доступ к GitLab кафедры (см. общие правила выполнения работ практикума).
  • Макет дашборда в Figma: aidt-mag-frontend-sample, фрейм dashboard-student-light. В макете уже проставлены имена слоёв, совпадающие с будущими семантическими тегами и классами (app-header, sidebar, main-content, card-schedule, nav-home и т. д.) — используются как шпаргалка по структуре.
  • Бриф и доменная модель референсного проекта — pz-env/brief.md рядом с текстом занятия. В нём перечислены сущности (дисциплины, расписание, прогресс, дедлайны, уведомления, KPI магистранта), значения, которые подставляются в разметку, а также явно зафиксировано, чего на дашборде нет.

Порядок выполнения работы

Работа состоит из трёх частей, которые выполняются последовательно: сначала каркас документа и метаинформация, затем семантическая разметка содержимого по макету, в завершение — отладка через DevTools и валидация. По итогам каждой части магистрант фиксирует промежуточный результат коммитом в рабочую ветку.

Часть 1. Каркас документа и метаинформация

Задание

  1. Откройте свой проект, создайте файл lab-01/index.html. В пустом файле наберите ! и нажмите Tab — Emmet развернёт базовый HTML5-каркас. Доведите его до вида, соответствующего проекту:
    • атрибут lang="ru" на <html>;
    • <meta charset="utf-8"> и <meta name="viewport"> с width=device-width, initial-scale=1;
    • <title> формата «Дашборд — Личный кабинет магистранта ВГТУ».
  2. Добавьте <meta name="description"> — одно-два предложения о назначении страницы.
  3. CSS и JavaScript на этом этапе не подключайте. Занятие оценивает разметку.

Результат

index.html с заполненной шапкой <head>, открывается в браузере без ошибок консоли. Во вкладке Elements DevTools структура <head> читается сверху вниз без сюрпризов. Nu Html Checker на этом этапе проходит без ошибок парсинга.

Часть 2. Структура дашборда по макету

Задание

Откройте Figma-макет рядом с редактором. Используя его как визуальный референс, разметьте <body> семантическими тегами. Следуйте именам слоёв в макете — они подсказывают, какой тег уместен в каждом месте. Сверьтесь с брифом (pz-env/brief.md), чтобы понимать, что означает каждый блок и какие данные он показывает.

Состав страницы определяется макетом. Минимальный набор:

  1. Шапка приложения — <header> со слоем app-header в макете. Содержит:
    • логотип кафедры (знак + название) — обёрнут в ссылку <a href="/">;
    • поле поиска — <input type="search"> внутри <form role="search">; подсказка про сочетание Ctrl+K / Cmd+K оформляется внутри <kbd>;
    • действия в правой части (контейнер <div class="header-actions">): кнопка переключения темы, кнопка уведомлений с числовым бейджем, меню профиля — аватар плюс индикатор раскрытия. Действия — <button type="button">.

    Горизонтального текстового меню в шапке нет (главная навигация — в сайдбаре).
  2. Сайдбар — <aside> со слоем sidebar слева от основного контента. Это единственная навигация уровня приложения, поэтому внутри <aside> лежит <nav> со списком <ul> / <li> из семи иконочных пунктов: nav-home (Дашборд), nav-profile (Профиль), nav-portfolio (Портфолио), nav-messages (Сообщения), nav-programs (Программы), nav-schedule (Расписание), nav-reference (Справочник). Текущий пункт (nav-home) помечается атрибутом aria-current="page".
  3. Основной контент — <main> со слоем main-content.
    • Хлебные крошки «Главная / Дашборд» — <nav aria-label="Хлебные крошки"> со списком <ol>.
    • Заголовок первого уровня <h1> с приветствием «Добро пожаловать, Иван».
    • Подзаголовок-строка: текущая дата в <time datetime="…">, далее семестр в <span> или <small>.
    • Секция «KPI» (<section aria-label="Ключевые показатели"> без видимого заголовка) с четырьмя карточками-метриками: средний балл, активные курсы, сдано заданий, ближайший дедлайн. Каждая карточка — <article> с заголовком (<h3>), иконкой и значением. Значение-число в <strong> или отдельном <p class="metric"> — на усмотрение автора.
    • Секция «Расписание на сегодня»<section> с <h2>. Список занятий — <ol>. Каждая строка: время в <time datetime="…">, название дисциплины, аудитория с преподавателем, тип занятия как <span class="tag">.
    • Секция «Прогресс по курсам»<section> с <h2> и списком. Каждый элемент: название дисциплины и индикатор <meter min="0" max="100" value="65">. Почему <meter>, а не <progress> — объясняется в контрольных вопросах.
    • Секция «Ближайшие дедлайны»<section> с <h2> и списком. Каждый элемент: название задания, дисциплина, срок в <time datetime="…">.
    • Секция «Уведомления»<section> с <h2>, списком уведомлений и ссылкой/кнопкой «Все». Индикатор непрочитанности (точка слева у каждой строки) — декоративный.

В макете на дашборде нет футера, модальных окон и горизонтального меню — соответствующих элементов в разметке быть не должно.

Требования к разметке:

  • один <h1> на странице; секции — <h2>; карточки — <h3>; иерархия без «перескоков»;
  • списки везде, где это список: расписание, дисциплины, задания, уведомления;
  • <time datetime="…"> с машиночитаемым ISO-значением для всех дат и сроков;
  • ссылки — <a href>, действия — <button type="button">.

Где активно использовать Emmet:

  • каркас секций (section#schedule>h2+ol>li*4>time+span+small);
  • повторяющиеся строки расписания и дедлайнов;
  • повторяющиеся карточки KPI (article.card-kpi*4>h3+p.metric).

Старайтесь писать руками минимум — Emmet быстрее и меньше опечаток.

Результат

Файл lab-01/index.html с разметкой дашборда, соответствующей описанию и макету. Во вкладке Elements DevTools читается та же структура, что вы написали в редакторе (если есть расхождения — значит, браузер что-то «починил» за вас, разберитесь почему). Reader View браузера отображает документ как связный текст с осмысленной иерархией заголовков.

Часть 3. Отладка через DevTools и валидация

Задание

  1. Откройте готовый lab-01/index.html в браузере и проведите аудит через DevTools:
    • На вкладке Elements разверните дерево полностью и сверьте с вашим исходником. Найдите, куда браузер вставил <tbody> / заменил относительные URL / скорректировал невалидную вложенность.
    • Кликните на <body> и посмотрите справа в Styles блок user agent stylesheet. Запомните, какие отступы и шрифты браузер применяет по умолчанию — они объяснят, почему страница без CSS всё равно «как-то выглядит».
    • На вкладке Sources → Page откройте ваш index.html в исходном виде — сравните с тем, что показано в Elements.
  2. Прогоните файл через Nu Html Checker (загрузка файла или вставка текста). Добейтесь 0 ошибок. Если остались предупреждения — решите по каждому: исправить или осознанно принять с пояснением в отчёте.
  3. Проверьте базовую клавиатурную навигацию: Tab проходит по ссылкам, кнопкам и полям поиска в порядке, близком к визуальному. Это проверка самой разметки (правильные теги для правильных ролей), не отдельная «а11y-часть».

Результат

В отчёте lab-01/report.md (раздел «Ход выполнения») — короткие (1–2 предложения на каждый пункт) ответы на:

  • Что нашли в Elements, чего нет в исходнике? Почему браузер это вставил/изменил?
  • Какие user-agent styles сильнее всего влияют на голую страницу? (2–3 примера.)
  • В чём расхождения между Sources → Page и Elements для вашего файла?
  • Какие предупреждения валидатора приняли осознанно и почему (если такие есть).

К отчёту приложите скриншот lab-01/screenshots/validator.png с экраном валидатора (0 errors).

Форма отчёта

Базовая структура отчёта — в общих правилах выполнения работ практикума, раздел «Состав отчёта». Специфика отчёта по этой работе:

  • решение в файле lab-01/index.html; CSS и JavaScript не подключаются;
  • в lab-01/report.md в разделе «Ход выполнения» — ответы на четыре вопроса из Части 3 (что нашли в Elements против исходника, какие user-agent-стили сильнее всего влияют, в чём расхождение Sources и Elements, какие предупреждения валидатора приняли осознанно и почему);
  • в подпапке lab-01/screenshots/validator.png с экраном Nu Html Checker (0 errors), вставленный в отчёт через ![](screenshots/validator.png);
  • бриф, wireframes, Figma-макет и доменные данные в проект не копируются — читаются из курсового репозитория и Figma по ссылкам из раздела «Перечень оснащения».

Контрольные вопросы

  1. Что разворачивает Emmet-аббревиатура ! + Tab, и какие из этих строк нельзя опустить на продакшн-странице? Обоснуйте для каждой.
  2. В чём разница между Sources → Page и Elements в DevTools? Приведите пример ситуации, когда их содержимое различается, и объясните, почему.
  3. Что такое user-agent stylesheet? Назовите 2–3 свойства, которые браузер применяет к элементам по умолчанию, и скажите, где в DevTools это видно.
  4. Чем принципиально различаются <section> и <article>? Приведите пример, когда карточка на дашборде должна быть <article>, и пример, когда — <section>.
  5. В каких случаях на странице может быть несколько <nav>? Как их различать в инструментах и зачем это нужно?
  6. Чем отличаются <meter> и <progress>, какой из них уместен для «прогресса по дисциплине», а какой — для «загрузки файла»? Почему?
  7. Почему <meta name="viewport"> нужен уже на этом этапе, где CSS ещё нет? Что произойдёт с отображением страницы на мобильном без него?
  8. Зачем атрибут datetime на элементе <time>, если пользователь всё равно видит только текст внутри тега? Кому и для чего он нужен?
  9. Какую роль играют атрибуты aria-label и aria-current="page" в разметке этого дашборда? Приведите по одному примеру использования каждого.
  10. Какую Emmet-аббревиатуру вы использовали для самого длинного фрагмента разметки в вашей работе? Запишите её и расшифровку.