Лабораторная работа №2. Проектирование структуры клиентской части Web-приложения

1. Теория

1.0. Цель работы

Сформировать у обучающегося системное понимание HTML как языка разметки клиентской части Web-приложения:

что такое HTML и зачем он нужен в Web-архитектуре;
как устроен HTML-документ и почему структура важнее “красоты”;
как элементы HTML образуют DOM-дерево;
как проектировать структуру интерфейса под сценарии и будущую интеграцию с API;
как писать валидную, семантическую, доступную разметку.

Закрепить навык архитектурного описания UI через схему:

UI (HTML) → DOM → JS (events) → API (HTTP) → DB

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

Подводка (почему это важно): Во взрослом Web-проекте HTML — это не “текст с тегами”, а контракт между дизайнером, фронтендом, бэкендом и пользователем. Если HTML построен правильно, то:

данные из API легко “ложатся” в UI,
события JS привязываются к понятным узлам,
доступность (A11y) достигается без костылей,
SEO и стабильность рендера не требуют “магии”.

1.1. История и стандарты HTML

1.1.1. Эволюция HTML (HTML 2.0 → HTML5)

HTML начинался как язык для разметки научных документов и ссылок, но с развитием Web превратился в основу интерфейсов web-приложений.

HTML 2.0 (1995) Содержал базовые конструкции: заголовки, абзацы, ссылки, простейшие формы. Главная цель — текст + гиперссылки.
HTML 3.2 / 4.01 (1997–1999) Добавились таблицы, скрипты, стили. В этот период активно использовали HTML для “вёрстки внешнего вида” (таблицы как сетка, font, center), из-за чего страдала структура и смысл разметки. Подводка: так родилась “div-верстка” и привычка верстать “как попало”, а потом “чинить CSS/JS”.
XHTML (2000-е) Попытка привести HTML к строгости XML: обязательные закрывающие теги, строгая вложенность, чувствительность к ошибкам. На практике оказался слишком “ломким” для реального Web (страница могла не работать из-за одной синтаксической ошибки). Подводка: идеальная строгость — хорошо для данных, но плохо для хаотичного реального Web.
HTML5 (2014+ и далее как Living Standard) Появились семантические элементы (header, nav, main, article и др.), новые типы полей форм, встроенные возможности для медиа (audio, video, source, picture), улучшения доступности и унификация поведения браузеров.

Ключевой вывод: современный HTML ориентирован не на “красивую разметку текста”, а на проектирование структуры интерфейса, пригодной для:

динамики (JS),
данных (API),
доступности,
SEO.

Мини-пример (смысл HTML5): Раньше могли написать так:

<div class="top">
  <div class="menu">...</div>
</div>
<div class="content">...</div>
<div class="bottom">...</div>

Сегодня это должно стать семантически понятным:

<header>...</header>
<nav>...</nav>
<main>...</main>
<footer>...</footer>

И это не “мода”, а архитектура: браузер, поисковик и скрин-ридер начинают понимать, что есть что.

1.1.2. Роль W3C и WHATWG

Стандарты HTML формируются и поддерживаются организациями:

W3C (World Wide Web Consortium) — исторический центр стандартизации Web-технологий (HTML, CSS, Accessibility-спецификации, рекомендации).
WHATWG (Web Hypertext Application Technology Working Group) — сообщество, ведущее HTML как Living Standard (живой стандарт), который обновляется непрерывно, отражая реальные возможности браузеров.

Практический вывод для разработки: “HTML5” в учебной логике — это современный HTML, который развивается. Поэтому:

новые элементы и атрибуты появляются и закрепляются как часть Living Standard;
корректность лучше проверять валидатором и актуальными справочниками, а не только старой книжкой.

Подводка: В учебных заданиях важно писать “как в стандарте”, потому что:

это снижает число ошибок при интеграции,
повышает переносимость,
облегчает сопровождение.

1.1.3. Отличие HTML от XML и XHTML

HTML часто путают с “языком тегов” вообще. На самом деле различия принципиальные:

Критерий	HTML	XML	XHTML
Назначение	UI и структура документа в браузере	Универсальный формат данных	HTML в синтаксисе XML
Терпимость к ошибкам	Высокая: браузер «восстанавливает» структуру	Низкая: ошибка → документ некорректен	Низкая: ошибка может «сломать» документ
Синтаксис	Допускает «упрощения»	Строго формальный	Строго формальный
Главная идея	Представление и смысл	Хранение и передача данных	Дисциплина и совместимость

Вывод: HTML — для интерфейса, XML — для данных, XHTML — исторический компромисс, который сегодня используется редко.

Пример для понимания (HTML vs XML):

HTML (интерфейс):

<button type="button">Купить</button>

XML (данные):

<product>
  <name>Serum</name>
  <price currency="EUR">19.99</price>
</product>

Подводка: в Web-приложении данные приходят в JSON/XML, а UI строится HTML (через DOM).

1.1.4. Понятие DOM

DOM (Document Object Model) — это представление HTML-документа в виде дерева объектов.

Критически важно понимать: браузер не “показывает HTML-текст”. Он:

читает HTML,
строит DOM,
рисует страницу на основе DOM + CSS.

Схема:

HTML-текст → парсер → DOM-дерево → (CSSOM) → render tree → layout → paint

DOM-дерево состоит из узлов:

Document (корень),
Element (теги),
Text (текстовые узлы),
комментарии и другие типы.

Пример (логика, как думает браузер):

<main>
  <h2>Каталог</h2>
  <p>Товары в наличии</p>
</main>

DOM-идея: JavaScript работает не с HTML-строкой, а с объектами:

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

Пример “HTML → DOM → JS”:

HTML:

<section id="catalog">
  <h2>Каталог</h2>
  <div id="catalogList"></div>
</section>

JS (логика работы с DOM):

const list = document.querySelector("#catalogList");
list.textContent = "Загрузка...";

Подводка: Если в HTML нет понятных “точек входа” (id, data-*), JS превращается в хаос: сложные селекторы, зависимость от структуры, ломается при любом редизайне.

1.1.5. Браузер как интерпретатор HTML

Браузер выполняет “производственный конвейер” рендеринга:

Parsing HTML → DOM строится дерево элементов.
Parsing CSS → CSSOM строится дерево стилей.
DOM + CSSOM → Render Tree остаются только видимые узлы и их визуальные свойства.
Layout вычисляются размеры и позиции элементов.
Paint отрисовка пикселей.
Compositing сборка слоёв (анимации, эффекты, ускорение).

Практический вывод: качество HTML влияет на:

скорость и стабильность UI (чрезмерные вложенности, лишние узлы),
предсказуемость поведения (правильная вложенность),
доступность и SEO (семантика),
простоту JS-логики (понятные селекторы, id, data-*).

Пример “плохой структуры” (лишняя вложенность):

<div class="wrap">
  <div class="wrap2">
    <div class="wrap3">
      <div class="wrap4">Кнопка</div>
    </div>
  </div>
</div>

Пример “нормальной структуры”:

<button type="button" class="btn">Кнопка</button>

Подводка: меньше узлов — проще стили, проще события, быстрее рендер.

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

1.2.1. DOCTYPE

<!DOCTYPE html> — объявление типа документа. Оно включает standards mode, в котором браузер использует современные правила рендеринга.

Без DOCTYPE возможен “quirks mode”, где браузер имитирует старое поведение (опасно для вёрстки и предсказуемости).

Пример:

<!DOCTYPE html>

1.2.2. `<html>`

Корневой элемент документа. Часто содержит атрибут lang, который критичен для доступности:

<html lang="ru">

lang помогает:

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

Подводка: Если сайт на русском, но lang="en", скрин-ридер может читать русские слова “по-английски”, что делает интерфейс фактически непригодным.

1.2.3. `<head>`

head не отображается напрямую, но управляет:

кодировкой,
адаптивностью,
SEO-метаданными,
подключением ресурсов (CSS/JS),
иконками,
политиками безопасности (в продакшене — CSP и др.).

Ключевые элементы head:

meta charset
meta viewport
title
meta description
link rel="stylesheet"
script defer

Пример минимально корректного head:

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Каталог товаров</title>
  <meta name="description" content="Каталог товаров: поиск, фильтры, карточки." />
</head>

1.2.4. `<body>`

body — видимая часть страницы: структура интерфейса и элементы взаимодействия.

Важно: body должен быть организован логически, как интерфейс приложения, а не “куча дивов”.

Подводка: Если тело страницы — это “набор блоков”, то дальше:

трудно выделить основной контент (main),
трудно навигироваться с клавиатуры,
сложно интегрировать компоненты (каталог, корзина, профиль).

1.2.5. Кодировка

<meta charset="UTF-8" />

UTF-8 — стандарт для современного Web, предотвращает:

“кракозябры”,
ошибки с национальными символами,
проблемы при обработке данных.

1.2.6. Метатеги

Ключевой метатег адаптивности:

<meta name="viewport" content="width=device-width, initial-scale=1.0" />

SEO-метатег:

<meta name="description" content="..." />

Подводка: description часто попадает в сниппет поисковой выдачи. Неправильное описание = хуже CTR, хуже видимость.

1.2.7. Подключение ресурсов

CSS:

<link rel="stylesheet" href="./styles.css" />

JS (рекомендуемая практика для UI):

<script src="./app.js" defer></script>

Почему defer важен:

HTML строит DOM,
после этого запускается JS,
значит можно безопасно искать элементы в документе.

Пример проблемы без defer: Если JS запускается раньше DOM, то:

document.querySelector("#catalogList") // может быть null

1.2.8. Пример базового документа с комментариями

<!doctype html>
<html lang="ru">
  <head>
    <!-- Кодировка документа -->
    <meta charset="UTF-8" />

    <!-- Адаптивность (мобильные устройства) -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

    <!-- Заголовок вкладки (важно для SEO) -->
    <title>Каталог товаров</title>

    <!-- Описание страницы (SEO snippet) -->
    <meta name="description" content="Каталог товаров: поиск, фильтры, карточки." />

    <!-- Подключение CSS (визуальный слой) -->
    <link rel="stylesheet" href="./styles.css" />

    <!-- Подключение JS (логика), defer — выполнение после построения DOM -->
    <script src="./app.js" defer></script>
  </head>

  <body>
    <!-- Семантическая шапка -->
    <header>
      <h1>Каталог</h1>
    </header>

    <!-- Основной контент страницы -->
    <main>
      <p>Контент страницы…</p>
    </main>

    <!-- Подвал -->
    <footer>
      <small>© 2026</small>
    </footer>
  </body>
</html>

1.3. HTML в архитектуре Web-приложения: “разметка как проектирование”

1.3.1. Почему структура важнее “красоты”

В web-разработке внешний вид меняется часто: темы, дизайн-система, адаптив, редизайн. Если HTML написан правильно, то:

CSS можно полностью заменить без переписывания структуры,
JS-логика будет устойчивее (понятные точки привязки),
экран будет доступен людям с ограниченными возможностями,
страница будет лучше индексироваться.

Если HTML плохой (всё через div, хаотичная вложенность), то:

сложно поддерживать,
сложно тестировать,
сложно внедрять новые компоненты,
растёт количество ошибок UI.

Пример “архитектурной” страницы каталога: У нас есть сценарии: (1) пользователь ищет товар → (2) фильтрует → (3) открывает карточку → (4) добавляет в корзину. Значит в HTML заранее должны быть:

форма поиска,
зона фильтров,
контейнер списка,
шаблон карточки/точки привязки.

1.3.2. Связь HTML и данных (API)

HTML проектируется под данные, которые приходят с сервера. Пример: если сервер отдаёт список товаров, то UI обычно имеет:

контейнер списка,
карточку сущности (повторяющийся article),
элементы управления (кнопки, фильтры),
состояния загрузки/ошибки.

Архитектурная цепочка:

API (JSON) → JS парсит данные → создаёт DOM-узлы → пользователь видит UI

Мини-пример данных API:

[
  { "id": 101, "title": "Сыворотка", "price": 1999 },
  { "id": 102, "title": "Крем", "price": 1499 }
]

Пример HTML-контейнера под эти данные:

<section id="catalog">
  <h2>Каталог</h2>
  <div id="catalogState" aria-live="polite"></div>
  <div id="catalogList"></div>
</section>

Подводка: catalogState нужен для состояния (loading/error/empty), а catalogList — для карточек.

1.3.3. Контракт между HTML и JS

Чтобы JS мог управлять UI, HTML должен содержать:

уникальные id для ключевых узлов (точки входа),
class для групп,
data-* для идентификаторов сущностей (id товара, id заявки),
корректную семантику элементов управления (button, a, form).

Пример “контракта”:

<section id="catalog">
  <div id="catalogList"></div>
</section>

JS ожидает, что #catalogList существует, и будет туда “рисовать” карточки.

Расширенный пример “контракта” для карточки товара:

<article class="product-card" data-product-id="101">
  <h3 class="product-title">Сыворотка</h3>
  <p class="product-price">1999 ₽</p>
  <button type="button" class="btn-add" data-action="add-to-cart">
    В корзину
  </button>
</article>

Подводка: data-action позволяет ловить события “делегированием” и не навешивать тысячу обработчиков.

1.3.4. UI-состояния и HTML-структура

Даже без CSS и JS структура должна предусматривать состояния:

пустой список (“нет данных”),
загрузка (“loading…”),
ошибка (“не удалось загрузить”),
успешное действие (“сохранено”).

Это часть архитектурного мышления: UI — это не только “страница”, а система состояний.

Пример блоков под состояния:

<div id="catalogState" role="status" aria-live="polite"></div>
<div id="catalogList"></div>

JS в зависимости от ситуации меняет catalogState:

“Загрузка…”
“Ошибка: нет сети”
“Ничего не найдено”

1.4. Мини-схемы (для отчёта)

1.4.1. Схема уровней Web-интерфейса

HTML (структура) + CSS (стиль) + JS (поведение) → UI

1.4.2. Схема взаимодействия UI с сервером

User action → DOM event → JS → HTTP request → API → DB
                               ↓
                          HTTP response (JSON)
                               ↓
                          JS → DOM update → UI

Подводка (как это связано с лабораторными):

В ЛР по HTML вы строите структуру и “точки входа”.
В ЛР по JS вы учитесь слушать DOM events и обновлять DOM.
В ЛР по HTTP/API вы добавляете fetch() и обработку статусов.
В результате получается “живой” интерфейс, который реально работает с данными.

2. Элементы HTML

2.1. Классификация элементов

Тип	Примеры	Назначение
Блочные	`div`, `section`, `article`, `main`	Формируют структуру, занимают “строку”
Строчные	`span`, `a`, `strong`, `em`	Внутри текста, не разрывают поток
Пустые (void)	`img`, `br`, `hr`, `meta`, `link`, `input`	Не имеют закрывающего тега
Семантические	`header`, `nav`, `main`, `article`, `footer`	Придают смысл структуре
Устаревшие	`font`, `center`, `marquee`	Не использовать

Подводка: Правильный выбор элемента — это:

меньше CSS “костылей”,
меньше проблем с доступностью,
понятная структура для других разработчиков.

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

Заголовки (иерархия смыслов):

<h1>Название страницы</h1>
<h2>Раздел</h2>
<h3>Подраздел</h3>

Абзацы и текст:

<p>Обычный текст.</p>
<strong>Важное</strong>
<em>Акцент</em>

Цитаты:

<blockquote cite="https://example.com">
  <p>Цитируемый фрагмент...</p>
</blockquote>

Код и моноширинный текст:

<p>Вызовите <code>fetch()</code> для запроса данных.</p>

Предварительно форматированный текст:

<pre>
line 1
  line 2
</pre>

Подводка: pre сохраняет пробелы и переносы, а code — семантически помечает код.

2.3. Списки (`ul`, `ol`, `dl`) и вложенные списки

Маркированный список (ul):

<ul>
  <li>Пункт</li>
  <li>Пункт</li>
</ul>

Нумерованный (ol):

<ol>
  <li>Шаг 1</li>
  <li>Шаг 2</li>
</ol>

Список определений (dl):

<dl>
  <dt>HTML</dt>
  <dd>Язык разметки</dd>
</dl>

Вложенный список (часто для меню/категорий):

<ul>
  <li>Категория 1
    <ul>
      <li>Подкатегория 1.1</li>
      <li>Подкатегория 1.2</li>
    </ul>
  </li>
  <li>Категория 2</li>
</ul>

Подводка: списки — это не только “маркер”, а важная семантика (особенно для навигации и доступности).

2.4. Ссылки и навигация `<a>`

Базовая ссылка:

<a href="/catalog">Каталог</a>

Абсолютный и относительный путь:

относительный: href="/catalog" или href="./catalog.html"
абсолютный: href="https://example.com/catalog"

Якоря (переход внутри страницы):

<a href="#contacts">Контакты</a>

<section id="contacts">
  <h2>Контакты</h2>
</section>

Открытие в новой вкладке + безопасность:

<a href="https://example.com" target="_blank" rel="noopener noreferrer">
  Открыть сайт
</a>

Подводка: rel="noopener" защищает от доступа новой вкладки к window.opener (важно для безопасности).

2.5. Изображения и медиа

Изображение (img) и alt:

<img src="img.jpg" alt="Флакон сыворотки на белом фоне" />

Оптимизация: lazy loading + размеры:

<img
  src="img.jpg"
  alt="Флакон"
  loading="lazy"
  width="600"
  height="600"
/>

Подводка: width/height помогают избежать “скачков” layout (CLS).

Адаптивные изображения (picture):

<picture>
  <source srcset="img.webp" type="image/webp" />
  <source srcset="img.jpg" type="image/jpeg" />
  <img src="img.jpg" alt="Флакон" />
</picture>

Аудио и видео:

<audio controls>
  <source src="sound.ogg" type="audio/ogg" />
  <source src="sound.mp3" type="audio/mpeg" />
</audio>

<video controls width="640">
  <source src="video.mp4" type="video/mp4" />
</video>

3. Таблицы

Таблицы используются только для табличных данных, а не “для верстки”.

3.1. Базовая структура

<table>
  <thead>
    <tr>
      <th>Имя</th>
      <th>Возраст</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Анна</td>
      <td>25</td>
    </tr>
  </tbody>
</table>

3.2. `rowspan` / `colspan`, группировка колонок, `<tfoot>`

Подводка: Если таблица — это отчет/прайс/расписание, она почти всегда должна иметь:

заголовки (th),
тело (tbody),
иногда итог (tfoot),
иногда группировку колонок (colgroup).

3.3. Семантика и доступность таблиц

th задает заголовки
можно использовать scope="col" / scope="row" для ясности
подпись таблицы — caption

3.4. Пример сложной таблицы (с `caption`, `colgroup`, `thead`, `tbody`, `tfoot`, `rowspan`, `colspan`)

<table>
  <caption>Прайс-лист услуг (пример сложной таблицы)</caption>

  <colgroup>
    <col />
    <col />
    <col />
    <col />
  </colgroup>

  <thead>
    <tr>
      <th scope="col">Категория</th>
      <th scope="col">Услуга</th>
      <th scope="col">Длительность</th>
      <th scope="col">Цена</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <th scope="rowgroup" rowspan="2">Косметология</th>
      <td>Увлажняющая маска</td>
      <td>30 мин</td>
      <td>1200 ₽</td>
    </tr>
    <tr>
      <td>Пилинг</td>
      <td>40 мин</td>
      <td>1800 ₽</td>
    </tr>

    <tr>
      <th scope="rowgroup" rowspan="2">Массаж</th>
      <td>Шейно-воротниковая зона</td>
      <td>25 мин</td>
      <td>1500 ₽</td>
    </tr>
    <tr>
      <td>Спина</td>
      <td>45 мин</td>
      <td>2200 ₽</td>
    </tr>
  </tbody>

  <tfoot>
    <tr>
      <td colspan="3"><strong>Итого услуг в таблице</strong></td>
      <td><strong>4</strong></td>
    </tr>
  </tfoot>
</table>

4. HTML-формы (ключевой блок)

Подводка (почему это ключевой блок): Форма — это главный механизм взаимодействия пользователя с web-сервисом: регистрация, вход, поиск, оформление заказа, заявки, обратная связь. Формы — “мост” между UI и сервером.

4.1. Структура формы `<form>`, `action`, `method` (GET / POST)

<form action="/api/users" method="POST">
  ...
</form>

GET — данные идут в URL (query string), удобно для поиска/фильтрации:
/catalog?query=serum&sort=price
POST — данные идут в тело запроса, применяется для создания/входа/отправки:
/api/login с JSON или form-data

4.2. Элементы формы

input (типов много):

<input type="text" name="name" />
<input type="email" name="email" />
<input type="password" name="password" />
<input type="tel" name="phone" />
<input type="url" name="site" />
<input type="number" name="age" />
<input type="date" name="date" />
<input type="color" name="color" />
<input type="checkbox" name="agree" />
<input type="radio" name="plan" value="basic" />
<input type="file" name="avatar" />
<input type="hidden" name="token" value="..." />

textarea:

<textarea name="message" rows="4"></textarea>

select/option:

<select name="city">
  <option value="msk">Москва</option>
  <option value="spb">Санкт-Петербург</option>
</select>

button:

<button type="submit">Отправить</button>
<button type="reset">Сброс</button>
<button type="button">Обычная кнопка</button>

4.3. Валидация: `required`, `pattern`, `minlength`, `maxlength`, `type=email/url`

<input
  type="email"
  name="email"
  required
  minlength="6"
  maxlength="64"
/>

<input
  type="password"
  name="password"
  required
  minlength="8"
  pattern="(?=.*\d)(?=.*[A-Z]).{8,}"
  aria-describedby="pwdHint"
/>

<small id="pwdHint">
  Пароль: минимум 8 символов, 1 цифра и 1 заглавная буква.
</small>

Подводка: HTML-валидация — это первый уровень. В production сервер все равно проверяет данные повторно.

4.4. Передача данных Web-сервису. Пример формы, работающей с API

Архитектура взаимодействия:

User → Form → DOM event → JS → HTTP request → API → DB
                                   ↓
                              HTTP response
                                   ↓
                              JS → DOM update

Пример 1: Форма входа (HTML + JS + fetch API)

HTML:

<form id="loginForm">
  <label>
    Email
    <input type="email" name="email" required />
  </label>

  <label>
    Пароль
    <input type="password" name="password" required minlength="8" />
  </label>

  <button type="submit">Войти</button>

  <p id="loginState" role="status" aria-live="polite"></p>
</form>

JS (сценарий работы формы с API):

const form = document.querySelector("#loginForm");
const state = document.querySelector("#loginState");

form.addEventListener("submit", async (e) => {
  e.preventDefault();

  state.textContent = "Отправка...";

  const formData = new FormData(form);
  const payload = Object.fromEntries(formData.entries());

  try {
    const res = await fetch("/api/login", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(payload),
    });

    if (!res.ok) {
      state.textContent = `Ошибка входа: ${res.status}`;
      return;
    }

    const data = await res.json();
    state.textContent = `Успешно. Пользователь: ${data.user?.email ?? "ok"}`;
  } catch (err) {
    state.textContent = "Ошибка сети. Повторите позже.";
  }
});

Подводка: HTML предоставляет структуру, id/name — контракт данных, JS обрабатывает событие и связывает UI с REST.

5. Семантика HTML5

Семантические элементы дают смысл структуре документа:

<header></header>
<nav></nav>
<main></main>
<section></section>
<article></article>
<aside></aside>
<footer></footer>
<figure></figure>
<figcaption></figcaption>

Различие `div` и семантических элементов

div — нейтральный контейнер без смысла (используется, когда нет подходящей семантики).
section/article/main/nav/header/footer — объясняют, что находится внутри.

Плохой пример (всё div):

<div class="top">...</div>
<div class="menu">...</div>
<div class="content">...</div>

Хороший пример (семантика):

<header>...</header>
<nav>...</nav>
<main>...</main>

6. Атрибуты HTML (глобальные)

Атрибут	Назначение
`id`	уникальная точка привязки (CSS/JS/якоря)
`class`	группировка для стилей и логики
`data-*`	хранение пользовательских данных (id сущности, действие)
`aria-*`	доступность (описания, состояния)
`role`	роль элемента, когда семантики не хватает

Пример data-* как контракт:

<button type="button" data-action="add-to-cart" data-product-id="101">
  В корзину
</button>

7. Доступность (Accessibility)

Что обязательно учитывать:

alt у изображений (если изображение смысловое)
правильная иерархия заголовков h1 → h2 → h3 (не прыгать)
aria-label для элементов без текста (иконки)
управление с клавиатуры (tabindex, фокус)

Примеры:

Иконка-кнопка:

<button type="button" aria-label="Открыть меню">
  ☰
</button>

Изображение:

<img src="product.jpg" alt="Крем для лица в баночке, белый фон" />

8. SEO-основы в HTML

Базовые SEO-элементы:

<title>Каталог товаров</title>
<meta name="description" content="Каталог: поиск, фильтры, карточки, цены." />

Подводка: Даже идеальный дизайн не помогает, если title/description пустые, а структура хаотичная.

Структурированные данные (Schema.org) — следующий уровень (обычно через JSON-LD).

9. Интеграция HTML с CSS и JavaScript

Подключение CSS

<link rel="stylesheet" href="./styles.css" />

Подключение JS: `defer` / `async`

<script src="./app.js" defer></script>

defer — скрипт выполнится после построения DOM (почти всегда правильно для UI).
async — скрипт выполняется как загрузится (может “обогнать” DOM), чаще для аналитики/виджетов.

Подводка: В учебных UI-проектах почти всегда: defer.

10. Задание

Цель

Спроектировать структуру клиентской части web-приложения на уровне HTML и описать её как систему:

UI (HTML) → DOM → JS (events) → API (HTTP) → DB

Нужно показать, что HTML в проекте:

описывает интерфейсные блоки (layout: шапка, меню, каталог, формы, статусы);
задаёт контракт для JS (id/class/data-* как точки привязки и источники данных);
формирует основу для отправки данных на сервер (формы, валидируемые поля, name);
обеспечивает семантику, доступность и SEO (header/main/section/article, заголовки, label, aria).

10.1. Выбор объекта проектирования

Выберите предметную область интерфейса (одну):

интернет-магазин;
LMS (платформа курсов);
сервис бронирования;
ServiceDesk (заявки/инциденты);
доставка / логистика;
расписание / запись к специалисту.

Требование: интерфейс обязан работать с данными (каталог/список, карточки, фильтры, статусы, форма отправки), а не быть статической страницей “о компании”.

Что нужно указать в отчёте:

Название предметной области.
Какая сущность главная (товар / курс / переговорная / заявка / заказ / запись).
Какая операция главная (создать заказ / записаться / создать заявку / забронировать).

10.2. Аналитический разбор интерфейса (UI-структура)

В отчёте опишите интерфейс как набор экранных областей и данных.

1) Основной сценарий пользователя (1–2 абзаца): Пример формата:

“Открыть каталог → отфильтровать → открыть карточку → заполнить форму → отправить → увидеть статус”.

2) Экранные области (что обязательно должно быть):

Header + Navigation (логотип, переходы, вход/профиль при необходимости);
Main (главный контент: каталог/список + детальная зона);
Aside (фильтры/корзина/панель статусов/помощь);
Footer (контакты/политики/копирайт).

3) Типы данных, которые отображаются (примерно):

список сущностей (например: products[], courses[], tickets[]);
детальная карточка (например: product, course, ticket);
параметры фильтра (например: category, priceFrom, status);
данные формы (например: name, email, date, comment, priority).

4) Семантика (какие теги под что подходят):

<header> — шапка сайта/приложения;
<nav> — навигация;
<main> — основное содержимое;
<section> — тематический раздел (каталог, оформление, профиль);
<article> — самостоятельная сущность (карточка товара/курса/заявки);
<aside> — боковая панель;
<form> — ввод данных для отправки на сервер;
<ul>/<ol> — списки результатов;
<button> — действие (submit, фильтр, загрузка);
<output> / <p role="status"> — статус/результат операции.

10.3. Архитектурная схема “UI → API → DB”

Постройте блок-схему (допустимы Mermaid / draw.io / Figma) по шаблону:

User → UI (HTML) → DOM → JS → API → DB → API → JS → UI update

На схеме обязательно должны быть:

пользователь;
UI (HTML/DOM);
клиентская логика JS (обработчики событий, fetch);
серверный API;
база данных.

Что подписать на стрелках:

“click/submit/input” (события);
“fetch: GET/POST/…” (HTTP-запрос);
“SQL/ORM read/write” (работа с БД);
“JSON response” (ответ);
“render/update DOM” (обновление UI).

10.4. Структура HTML (каркас будущего интерфейса)

Создайте HTML-страницу, которая соответствует структуре:

<header> + <nav>
<main> (основное содержимое)
<aside> (фильтры/корзина/статусы — по вашей теме)
<footer>

Обязательные требования к разметке:

минимум 1 <section>;
минимум 2 <article> (карточки сущностей);
заголовочная иерархия h1 → h2 → h3 (без пропусков уровней);
у интерактивных элементов должны быть id/class/data-* для JS-привязки.

Рекомендации (чтобы было “API-ready”):

список сущностей оформляйте как <section> + контейнер списка (<div class="grid"> или <ul>);
карточки — <article data-id="...">;
блок статуса — отдельный узел (например <div id="status" role="status" aria-live="polite"></div>).

10.5. Таблица сравнения: block / inline / void / semantic

Составьте таблицу минимум на 12 элементов. Для каждого элемента укажите:

тип: block / inline / void / semantic (можно комбинировать: semantic block);
назначение;
пример (1 строка кода).

Требования к таблице:

минимум 3 semantic;
минимум 3 inline;
минимум 3 block;
минимум 2 void.

Пример строки:

img | void | вставка изображения | <img src="..." alt="...">

10.6. Проектирование формы (минимум 1 форма)

В интерфейсе должна быть минимум одна форма, ориентированная на web-сервис (создание заказа/заявки/брони/записи).

Обязательно в форме:

минимум 3 поля ввода;
required у обязательных полей;
корректные типы (email, number, date, url, tel — по смыслу);
минимум 1 pattern;
минимум 1 select или группа radio;
у каждого поля: name, id, и связанный <label for="...">.

Форма должна быть “API-ready”:

name совпадают с ожидаемыми полями JSON/DTO;
понятная структура (fieldset для групп, например контакты/детали/опции);
есть кнопка type="submit".

10.7. Передача данных на API (демонстрационный сценарий)

Добавьте пример отправки формы через fetch() (демо связи UI → API).

В отчёте обязательно указать:

URL (пример: /api/orders).
HTTP-метод (обычно POST).
Заголовки (например Content-Type: application/json).
JSON-тело запроса (пример минимум 5 полей).
Ожидаемый статус-код (например 201 Created или 200 OK).
Пример JSON-ответа (например: id, status, createdAt, message, data).

Важно: даже если реального сервера нет, вы описываете контракт так, будто API существует.

10.8. Краткий аналитический вывод (1–2 страницы)

Напишите связный текст, где объясняете:

Почему выбранная структура HTML корректна с точки зрения семантики (header/nav/main/section/article/aside/footer).
Какие узлы DOM будут точками привязки для JS:
элементы статуса,
контейнер списка карточек,
форма,
фильтры,
кнопки действий.
Как форма связана с REST-сценарием (какой ресурс создаётся/изменяется).
Какие ошибки предотвращены:
доступность (label/for, aria-live),
валидность (required, type, pattern),
корректные id/name (контракт для JS и API),
предсказуемая структура DOM.

11. Итоговая задача

«Проектирование HTML-структуры клиентской части web-приложения»

11.1. Мини-каталог UI-компонентов (структурный)

Составьте список 8–12 UI-компонентов вашего интерфейса (блоков). Пример:

Header
Navigation
SearchBar
FilterPanel (aside)
CatalogGrid
EntityCard (ProductCard/CourseCard/TicketCard)
Pagination
DetailPanel (модалка/страница деталей)
MainForm (OrderForm/BookingForm/TicketForm)
StatusMessage (toast/alert)
Footer

Для каждого компонента укажите:

назначение (1–2 предложения);
какие HTML-теги используются;
какие атрибуты нужны для JS:
id (для уникальных узлов),
class (для групп),
data-* (для идентификаторов сущностей, статусов, ролей).

11.2. Схема “UI → API → DB” на одном сценарии

Опишите один бизнес-сценарий (полностью, по шагам):

Действие пользователя (например: “создать заявку/заказ/бронь”).
Какие поля вводятся (перечень + типы данных).
Какой запрос уходит:
URL,
method,
headers,
JSON body (пример).
Что делает сервер (валидация, расчёты, права доступа).
Что записывается/читается из БД (какая таблица/коллекция и ключевые поля).
Какой JSON возвращается (пример).
Как обновляется UI (статус, очистка формы, добавление карточки в список, редирект).

11.3. Два сценария ошибок (UI-уровень)

Предусмотрите две ошибки, видимые пользователю:

400 Bad Request (валидация формы) Указать:
причина (например: неверный email, пустое обязательное поле, pattern не совпал);
что отображается в UI (подсветка поля, текст под полем, общий alert);
пример JSON-ошибки:
error, message, fieldErrors[] или аналог.
401/403/404 (доступ / не найдено) Указать:
причина (нет авторизации / нет прав / сущность не существует);
что отображается в UI (сообщение + действия: “войти”, “назад”, “обновить”);
пример JSON-ошибки (код, сообщение, traceId при необходимости).

11.4. Для выполнения требуется

Шаблон отчёта (по методическим указаниям).
Вариант задания в ЛМС (выбранная предметная область).
Оформление по требованиям (структура, нумерация, рисунки/схемы, таблицы).
Ссылка на репозиторий или архив проекта (HTML + assets + краткий README).

11.5. Запрет

❗ Запрещается использование систем искусственного интеллекта для выполнения лабораторной работы.

Работы, выполненные с использованием ИИ, оцениваются в 0 баллов без возможности доработки.

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

Ответить кратко (1–3 предложения):

Отличие GET от POST.
Что означает статус 404.
Что такое REST-ресурс.
Почему JSON часто удобнее XML для API.
Различие web-приложения и web-сервиса.
Зачем нужны name у полей формы.
Что такое DOM и зачем JS “точки привязки”.
Для чего нужны data-* атрибуты.

13. Чек-лист для самопроверки

Баллы	Критерии
10	Выбор предметной области + сценарий, схема UI→API→DB, HTML-каркас по требованиям, таблица 12 элементов, форма API-ready, fetch-сценарий, вывод, 2 ошибки, мини-каталог компонентов
8–9	Есть все разделы, но есть мелкие нарушения: слабая семантика/мало атрибутов для JS/неполная ошибка/неточности в HTTP
6–7	Частично выполнено: нет схемы или форма/таблица/вывод сделаны поверхностно
<6	Несистемно: нет архитектурной логики, отсутствуют ключевые артефакты
0	Работа не сдана или выполнена с ИИ

14. Шаблон отчёта

👉 Скачать шаблон отчёта