From 4608540b0c3757f45f3105ed1d34f8cc2cd06900 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=9C=D0=B0=D0=BA=D1=81=D0=B8=D0=BC=20=D0=98=D0=B2=D0=B0?=
 =?UTF-8?q?=D0=BD=D0=BE=D0=B2?= <omaxphp@yandex.ru>
Date: Mon, 10 Aug 2026 18:19:24 +0300
Subject: [PATCH] docs: expand HTML core semantics answers

---
 src/pages/html/index.md | 580 +++++++++++++++++++++++++++++++++++-----
 1 file changed, 518 insertions(+), 62 deletions(-)

diff --git a/src/pages/html/index.md b/src/pages/html/index.md
index 00c6cd1..e3874b3 100644
--- a/src/pages/html/index.md
+++ b/src/pages/html/index.md
@@ -18,20 +18,53 @@ order: 30
 **Короткий ответ**
 
 HTML описывает структуру и смысл документа: заголовки, текст, навигацию, формы, ссылки и изображения. Браузер разбирает
-разметку и строит DOM, который используют CSS, JavaScript, поисковые роботы и ассистивные технологии (assistive
-technologies).
+разметку и строит DOM, который используют CSS, JavaScript, поисковые роботы и assistive technologies.
 
 **Полный ответ**
 
-HTML описывает структуру и смысл документа: заголовки, текст, навигацию, формы, ссылки и изображения. Браузер разбирает
-разметку и строит DOM, который используют CSS, JavaScript, поисковые роботы и ассистивные технологии (assistive
-technologies).
+HTML, HyperText Markup Language, — язык разметки, который описывает **структуру и семантику** документа. Он не задает
+бизнес-логику приложения и не отвечает за визуальный layout: обычно HTML описывает, _что это за контент_, CSS — как он
+выглядит, а JavaScript — как меняется и реагирует на события.
+
+Например:
 
 ```html
-<button>Buy</button>
+<article>
+  <h2>Корзина</h2>
+  <p>В корзине 3 товара</p>
+  <button type="button">Оформить заказ</button>
+</article>
 ```
 
-![img.png](assets/html-and-css-difference.png)
+Здесь браузер получает не просто набор строк. После parsing он создает DOM-узлы с типами и отношениями: `article`
+содержит heading, paragraph и интерактивный `button`. На основе HTML и ARIA браузер также строит accessibility tree,
+который используют screen readers.
+
+HTML важен сразу нескольким потребителям:
+
+- браузеру — для построения DOM и native behavior элементов;
+- CSS — как дерево, к которому применяются selectors и layout rules;
+- JavaScript — как API объектов DOM;
+- assistive technologies — для ролей, имен и структуры интерфейса;
+- поисковым системам — для понимания содержимого и связей;
+- тестам и automation — для устойчивых semantic selectors.
+
+Поэтому визуально одинаковые варианты не всегда эквивалентны:
+
+```html
+<div class="button">Купить</div>
+<button type="button">Купить</button>
+```
+
+Оба можно стилизовать одинаково, но второй вариант уже имеет keyboard behavior, focusability, button semantics и
+ожидаемое поведение формы.
+
+Еще один важный момент: **HTML source и DOM — не одно и то же**. Parser может исправить часть невалидной вложенности,
+добавить служебные узлы, а JavaScript позже меняет DOM динамически.
+
+На интервью полезно связать HTML не только с тегами: **HTML — это контракт структуры и семантики страницы, из которого
+браузер строит DOM и accessibility model; корректная разметка уменьшает объем CSS/JS, который приходится имитировать
+вручную**.
 
 </td></tr></table>
 
@@ -43,16 +76,67 @@ technologies).
 
 **Короткий ответ**
 
-Attribute задает дополнительную информацию или поведение element: href, type, disabled, lang. Global attributes вроде
-id, class, hidden и data- доступны большинству элементов, а часть attributes имеет смысл только для определенных tags.
+Attribute задает дополнительную информацию, состояние или настройку HTML element: `href`, `type`, `disabled`, `lang`.
+Global attributes вроде `id`, `class`, `hidden` и `data-*` доступны большинству элементов, а часть attributes имеет
+смысл только для определенных элементов.
 
 **Полный ответ**
 
-![img.png](assets/what-is-html-attribute.png)
+HTML attribute — часть start tag, которая уточняет свойства элемента или его поведение.
+
+```html
+<a
+  href="/profile"
+  class="link"
+  lang="en"
+>
+  Profile
+</a>
+```
+
+Здесь:
+
+- `href` задает destination ссылки;
+- `class` добавляет значение, которое можно использовать в CSS/JS;
+- `lang` меняет языковой контекст текста.
+
+Attributes удобно разделять на несколько групп.
+
+**Global attributes** доступны у большинства HTML elements: `id`, `class`, `title`, `hidden`, `tabindex`, `lang`, `dir`,
+`data-*` и другие.
+
+**Element-specific attributes** определены для конкретных элементов: `href` у `a`, `src` и `alt` у `img`, `type` у
+`button`/`input`, `action` у `form`.
+
+**Boolean attributes** работают по факту присутствия, а не по строковому значению:
+
+```html
+<button disabled>Save</button>
+```
+
+Для boolean attribute запись `disabled="false"` все равно означает disabled, потому что attribute присутствует. Чтобы
+снять состояние, attribute нужно удалить.
 
-Attribute задает дополнительную информацию или поведение element: `href`, `type`, `disabled`, `lang`. Global attributes
-вроде `id`, `class`, `hidden` и `data-*` доступны большинству элементов, а часть attributes имеет смысл только для
-определенных tags.
+Важно отличать **HTML attribute от DOM property**. Initial markup задает attributes, а browser создает DOM object с
+properties. Для некоторых значений они отражают друг друга, но не всегда являются одной сущностью. Например, текущее
+`input.value` может измениться после пользовательского ввода, тогда как attribute `value` продолжает описывать initial
+value.
+
+```html
+<input value="initial" />
+```
+
+```js
+input.value = 'current';
+```
+
+В framework-разработке эта разница особенно заметна при property binding и attribute binding.
+
+Attributes также не являются безопасным хранилищем. Любые значения в DOM видны клиенту, поэтому в `data-*`, hidden
+inputs и произвольные attributes нельзя помещать secrets или считать их trusted source.
+
+На интервью хороший ответ включает три идеи: **attribute находится в markup, может влиять на semantics/native behavior,
+а после parsing важно различать attribute и соответствующее DOM property**.
 
 </td></tr></table>
 
@@ -64,17 +148,68 @@ Attribute задает дополнительную информацию или
 
 **Короткий ответ**
 
-Semantic HTML использует элементы по их назначению: nav для навигации, main для основного контента, button для действия.
-Это делает структуру понятнее браузеру, разработчикам, поисковым системам и assistive technologies.
+Semantic HTML использует элементы по их назначению: `nav` для навигации, `main` для основного контента, `button` для
+действия. Это делает структуру понятнее браузеру, разработчикам, поисковым системам и assistive technologies.
 
 **Полный ответ**
 
-Semantic HTML использует элементы по их назначению: `nav` для навигации, `main` для основного контента, `button` для
-действия. Это делает структуру понятнее браузеру, разработчикам, поисковым системам и assistive technologies.
+Semantic HTML означает, что элемент выбирают прежде всего по **смыслу и поведению**, а не по его default-стилям.
+
+Например:
+
+```html
+<nav aria-label="Основная навигация">
+  <a href="/catalog">Каталог</a>
+</nav>
+
+<main>
+  <h1>Каталог</h1>
+  <button type="button">Добавить товар</button>
+</main>
+```
+
+`nav`, `main`, heading, link и button сообщают браузеру и assistive technologies, какую роль выполняет каждый кусок
+интерфейса. Это дает несколько преимуществ.
+
+**Accessibility**
+
+Screen reader может быстро перемещаться по landmarks и headings, а native controls получают ожидаемый keyboard behavior
+без ручной реализации.
+
+**Поддерживаемость**
+
+Разметка `<button>` понятнее, чем `<div class="clickable">`: следующему разработчику не нужно выяснять, является ли узел
+действием, ссылкой или просто контейнером.
+
+**Прогрессивное поведение браузера**
+
+Native элементы уже умеют focus, form submission, link navigation, context menu, open in new tab и другие platform
+features.
+
+**SEO и machine-readable structure**
 
-В командных guidelines semantic HTML должен быть отдельным правилом, потому что в Angular templates легко заменить
-структуру набором компонентов и директив. Хороший кандидат объяснит, что компоненты не отменяют базовые HTML semantics:
-landmarks, headings, form controls и интерактивные элементы все равно должны оставаться корректными.
+Семантика помогает crawler понять hierarchy и назначение частей документа, хотя сама по себе не является гарантией
+ranking.
+
+Типичная ошибка — использовать семантический элемент только из-за названия. Например, `section` не нужен вместо каждого
+`div`: это тематический раздел документа, обычно с собственным heading. Для purely layout wrapper обычный `div` часто
+корректнее.
+
+Еще одна ошибка — считать framework component семантикой сам по себе:
+
+```html
+<app-action>Save</app-action>
+```
+
+Custom Angular component не превращается автоматически в accessible button. Внутри него все равно нужно выбрать
+правильный native element и обеспечить contract компонента.
+
+ARIA также не должна быть первым способом исправления markup. Правило «No ARIA is better than bad ARIA» практически
+означает: сначала ищем native element, а роль и состояния добавляем вручную только когда platform primitive
+недостаточно.
+
+На интервью можно сформулировать так: **semantic HTML переносит часть поведения и смысла из пользовательского JavaScript
+в стандартизированные browser primitives, поэтому интерфейс обычно получается доступнее, проще и устойчивее**.
 
 </td></tr></table>
 
@@ -86,15 +221,53 @@ landmarks, headings, form controls и интерактивные элемент
 
 **Короткий ответ**
 
-Это логическая структура документа, прежде всего иерархия заголовков и landmarks. На практике нужно последовательно
-использовать h1–h6, не полагаясь на давно предложенный, но не реализованный браузерами outline algorithm для sectioning
-elements.
+Это логическая структура документа, прежде всего иерархия `h1`–`h6` и landmarks. На практике headings нужно выстраивать
+последовательно и не полагаться на старый HTML outline algorithm для sectioning elements: браузеры его не реализовали
+как способ автоматически вычислять уровни заголовков.
 
 **Полный ответ**
 
-Это логическая структура документа, прежде всего иерархия заголовков и landmarks. На практике нужно последовательно
-использовать `h1`–`h6`, не полагаясь на давно предложенный, но не реализованный браузерами outline algorithm для
-sectioning elements.
+Под document outline на практике понимают **логическую иерархию содержимого страницы**: какой heading главный, какие
+разделы вложены друг в друга и где находятся основные landmarks.
+
+Например:
+
+```html
+<h1>Настройки аккаунта</h1>
+
+<section>
+  <h2>Безопасность</h2>
+
+  <section>
+    <h3>Двухфакторная аутентификация</h3>
+  </section>
+</section>
+
+<section>
+  <h2>Уведомления</h2>
+</section>
+```
+
+Здесь уровни headings отражают информационную вложенность, а не размер шрифта. Визуальный размер всегда можно изменить
+CSS.
+
+Исторически спецификация HTML предлагала outline algorithm, в котором `section`, `article`, `nav` и `aside` должны были
+автоматически влиять на уровень heading. На этот механизм нельзя рассчитывать: браузеры и assistive technologies не
+реализовали его как надежную замену явной иерархии `h1`–`h6`.
+
+Практические правила:
+
+- у страницы должен быть понятный основной heading;
+- следующий heading level выбирают по структуре, а не по CSS;
+- пропуск уровня (`h2` сразу в `h4`) часто сигнализирует о неясной hierarchy, хотя сам по себе HTML не ломает;
+- reusable component не должен жестко предполагать один heading level, если его можно использовать на разных уровнях;
+- landmarks (`main`, `nav`, `aside`, `header`, `footer`) дополняют headings, а не заменяют их.
+
+Для SPA важна еще и динамика: после route change document title, main heading и focus должны оставаться согласованными,
+иначе визуально новая страница появилась, а пользователь screen reader продолжает находиться в старом контексте.
+
+На интервью сильный ответ: **outline — это не магия sectioning tags, а явно спроектированная hierarchy headings и
+landmarks, которая отражает структуру контента и помогает навигации**.
 
 </td></tr></table>
 
@@ -106,13 +279,46 @@ sectioning elements.
 
 **Короткий ответ**
 
-сообщает браузеру, что документ следует обрабатывать в standards mode. Без корректного doctype браузер может включить
-quirks mode с устаревшими правилами layout и совместимости.
+`<!doctype html>` сообщает браузеру, что документ нужно обрабатывать в standards mode. Без корректного doctype браузер
+может включить quirks mode с устаревшими правилами layout и совместимости.
 
 **Полный ответ**
 
-`<!doctype html>` сообщает браузеру, что документ следует обрабатывать в standards mode. Без корректного doctype браузер
-может включить quirks mode с устаревшими правилами layout и совместимости.
+Современный HTML-документ обычно начинается так:
+
+```html
+<!doctype html>
+<html lang="ru">
+  <!-- ... -->
+</html>
+```
+
+`<!doctype html>` — не обычный HTML element и не указание версии «HTML5» в runtime. Это declaration, которое прежде
+всего нужно браузеру для выбора **rendering mode**.
+
+Исторически сайты зависели от несовместимого поведения старых браузеров. Чтобы новые браузеры могли одновременно
+поддерживать старые страницы и стандартизированное поведение, появились режимы:
+
+- **standards mode** — современное поведение по стандартам;
+- **quirks mode** — набор legacy-совместимостей;
+- в некоторых случаях **limited quirks mode**.
+
+Без корректного doctype браузер может перейти в quirks mode. Тогда различия затрагивают, например, вычисление layout и
+часть CSS behavior. Такая проблема особенно неприятна тем, что HTML и CSS визуально выглядят корректно, но страница
+ведет себя иначе из-за document mode.
+
+Проверить режим можно через:
+
+```js
+document.compatMode;
+```
+
+В standards mode обычно будет `CSS1Compat`, в quirks mode — `BackCompat`.
+
+Старые doctypes были длинными, потому что ссылались на DTD. В современном HTML достаточно короткого `<!doctype html>`.
+
+На интервью полезно подчеркнуть: **doctype нужен не для загрузки спецификации и не является HTML-тегом; его практическая
+роль — не дать браузеру случайно включить legacy quirks rendering**.
 
 </td></tr></table>
 
@@ -124,13 +330,64 @@ quirks mode с устаревшими правилами layout и совмес
 
 **Короткий ответ**
 
-Custom Elements API позволяет регистрировать собственные HTML-элементы с именем через дефис и lifecycle callbacks. Это
-часть Web Components; Shadow DOM и templates являются отдельными API и не включаются автоматически.
+Custom Elements API позволяет регистрировать собственные HTML elements с именем через дефис и lifecycle callbacks. Это
+часть Web Components; Shadow DOM, templates и slots — отдельные возможности и не включаются автоматически.
 
 **Полный ответ**
 
-Custom Elements API позволяет регистрировать собственные HTML-элементы с именем через дефис и lifecycle callbacks. Это
-часть Web Components; Shadow DOM и templates являются отдельными API и не включаются автоматически.
+Custom Elements — browser API для регистрации собственных элементов, которые участвуют в DOM как настоящие elements. Имя
+autonomous custom element должно содержать дефис, чтобы не конфликтовать с будущими built-in HTML tags.
+
+```js
+class UserBadge extends HTMLElement {
+  connectedCallback() {
+    this.textContent ||= 'Guest';
+  }
+}
+
+customElements.define('user-badge', UserBadge);
+```
+
+После регистрации markup можно использовать так:
+
+```html
+<user-badge></user-badge>
+```
+
+Основные lifecycle callbacks включают:
+
+- `connectedCallback()` — element подключен к document;
+- `disconnectedCallback()` — удален из document;
+- `attributeChangedCallback()` — наблюдаемый attribute изменился;
+- `adoptedCallback()` — element переместили между documents.
+
+Важно: Custom Elements API **не означает Shadow DOM автоматически**. Компонент может остаться в обычном light DOM. Если
+нужна style/DOM encapsulation, автор отдельно создает shadow root. Аналогично `<template>` и `<slot>` — связанные, но
+самостоятельные primitives Web Components.
+
+Есть несколько архитектурных trade-offs.
+
+**Плюсы**
+
+- platform-level contract без привязки потребителя к Angular/React;
+- удобно для design system, который используется в разных stacks;
+- lifecycle и attributes доступны непосредственно через browser API.
+
+**Ограничения**
+
+- attributes строковые по своей природе, а complex state требует properties/events;
+- SSR/hydration и form integration требуют отдельного дизайна;
+- Shadow DOM меняет правила styling, focus и testing;
+- custom element сам по себе не получает semantics кнопки, input или другого native control.
+
+Если `<my-button>` обрабатывает click, это еще не делает его доступной кнопкой. Часто внутри все равно нужен настоящий
+`button`, либо более сложная реализация platform semantics.
+
+В Angular custom elements могут быть interoperability boundary, но внутри одного Angular-приложения обычный Angular
+component часто проще: у него уже есть DI, templates, signals/inputs и framework lifecycle.
+
+На интервью полезно разделить понятия: **Custom Elements — регистрация нового DOM element; Web Components — более
+широкий набор browser primitives, куда также относятся Shadow DOM и templates**.
 
 </td></tr></table>
 
@@ -142,15 +399,55 @@ Custom Elements API позволяет регистрировать собств
 
 **Короткий ответ**
 
-Tag — синтаксическая часть разметки, например или . Element — целый узел: открывающий tag, attributes, content и
-закрывающий tag. Void elements вроде не имеют closing tag и содержимого.
+Tag — синтаксическая часть HTML source, например `<p>` или `</p>`. Element — сущность документа: start tag, attributes,
+content и end tag, если он предусмотрен. Void elements вроде `<img>` или `<input>` не имеют end tag и child content.
 
 **Полный ответ**
 
-![img.png](assets/what-the-difference-between-tag-and-element.png)
+Термины часто используют как синонимы в разговоре, но технически они относятся к разным уровням.
+
+**Tag** — токен в текстовой HTML-разметке:
+
+```html
+<p></p>
+```
+
+`<p>` — start tag, `</p>` — end tag.
+
+**Element** — логическая сущность, которую описывает markup и из которой после parsing появляется DOM element:
+
+```html
+<p class="lead">
+  Hello
+  <strong>world</strong>
+</p>
+```
+
+У `p` element есть start tag, attribute `class`, text/content, вложенный `strong` и end tag.
+
+Не у всех элементов структура одинаковая. **Void elements** не могут иметь child nodes в HTML и не используют end tag:
+
+```html
+<img
+  src="avatar.png"
+  alt="User avatar"
+/>
+<input name="email" />
+<br />
+```
+
+Слеш перед `>` в HTML для void element не создает «self-closing semantics» как в XML; `<img>` и `<img />` для HTML
+parser по сути относятся к одному void element.
 
-Tag — синтаксическая часть разметки, например `<p>` или `</p>`. Element — целый узел: открывающий tag, attributes,
-content и закрывающий tag. Void elements вроде `<img>` не имеют closing tag и содержимого.
+Есть также элементы, у которых end tag в source может быть опущен по правилам parser, например часть `li`, `p`, `td`.
+DOM element при этом все равно существует как узел дерева.
+
+Разница полезна при отладке parser behavior: source содержит tags, а DOM DevTools показывает уже построенные nodes.
+Невалидная последовательность tags может быть исправлена parser-ом, поэтому получившееся element tree не всегда
+буквально повторяет source.
+
+На интервью достаточно сказать: **tag — это синтаксис разметки, element — объект структуры документа, который этот
+синтаксис описывает**.
 
 </td></tr></table>
 
@@ -162,16 +459,58 @@ content и закрывающий tag. Void elements вроде `<img>` не и
 
 **Короткий ответ**
 
-Исторически block elements начинали новую строку, а inline elements участвовали в строке текста. В современном CSS
-реальное поведение задает display, поэтому семантическую категорию HTML-элемента нельзя использовать как замену знанию
-layout.
+`block` и `inline` прежде всего описывают layout behavior CSS. У HTML elements есть historical/default display values,
+но их можно изменить через `display`, поэтому семантику элемента нельзя определять по тому, начинается ли он с новой
+строки.
 
 **Полный ответ**
 
-Исторически block elements начинали новую строку, а inline elements участвовали в строке текста. В современном CSS
-реальное поведение задает `display`, поэтому семантическую категорию HTML-элемента нельзя использовать как замену знанию
+Термины «block element» и «inline element» исторически удобны, но в современном frontend важно не смешивать **HTML
+semantics** и **CSS formatting behavior**.
+
+User agent stylesheet обычно задает, например:
+
+```css
+p {
+  display: block;
+}
+
+span {
+  display: inline;
+}
+```
+
+Block-level box обычно участвует в block formatting context и занимает строку в своем normal flow, а inline box
+участвует в line formatting вместе с текстом.
+
+Но CSS может изменить это:
+
+```css
+span.badge {
+  display: inline-block;
+}
+
+nav.horizontal {
+  display: flex;
+}
+```
+
+`nav` после `display: flex` не перестает быть navigation landmark. `span` после `display: block` не приобретает
+semantics `section` или `p`.
+
+Есть и более сложные значения: `inline-block`, `flex`, `grid`, `flow-root`, `contents` и комбинации outer/inner display
+types. Поэтому правило «div block, span inline» — только описание распространенных defaults, а не полноценная модель
 layout.
 
+Отдельный edge case — содержательная модель HTML. Нельзя рассуждать так: «если CSS сделал `span` block, теперь внутрь
+можно помещать любую структуру». Content model и validity HTML не меняются из-за CSS.
+
+Практический пример: для текста внутри paragraph можно использовать `span` и визуально сделать его badge. Для отдельного
+раздела страницы лучше выбрать semantic container, даже если CSS у обоих будет одинаковый.
+
+На интервью сильный ответ: **block/inline — это главным образом CSS formatting, semantic category HTML живет отдельно;
+default display можно изменить, semantics от этого не меняются**.
+
 </td></tr></table>
 
 </details>
@@ -182,15 +521,42 @@ layout.
 
 **Короткий ответ**
 
-HTML principles фиксируют, как команда пишет разметку: использует семантические элементы, поддерживает accessibility, не
-заменяет button и a на кликабельные div, сохраняет правильную структуру headings и forms. Это снижает споры в review и
-помогает screen readers, SEO, автотестам и долгой поддержке интерфейса.
+HTML principles фиксируют повторяемые решения: native semantics, keyboard accessibility, heading/form structure, правила
+для links/buttons и допустимое применение ARIA. Это уменьшает количество случайных решений в каждом PR и делает
+интерфейс стабильнее для пользователей, тестов и поддержки.
 
 **Полный ответ**
 
-HTML principles фиксируют, как команда пишет разметку: использует семантические элементы, поддерживает accessibility, не
-заменяет `button` и `a` на кликабельные `div`, сохраняет правильную структуру headings и forms. Это снижает споры в
-review и помогает screen readers, SEO, автотестам и долгой поддержке интерфейса.
+В большой codebase HTML редко ломается одной очевидной ошибкой. Чаще качество постепенно деградирует через сотни
+локально «нормальных» решений: clickable `div`, heading ради размера текста, input без label, лишний ARIA, нестабильные
+DOM selectors.
+
+Поэтому team principles полезны как **общие invariants разметки**.
+
+Например, команда может договориться:
+
+- действие — `button`, навигация — `a[href]`;
+- native HTML предпочтительнее custom role + JavaScript behavior;
+- каждый form control получает корректное accessible name;
+- headings отражают document hierarchy;
+- `main`, `nav`, `aside` и другие landmarks используются по назначению;
+- decorative images/SVG не засоряют accessibility tree;
+- `data-testid` не заменяет semantics, если test может найти control по role/name;
+- ARIA добавляется только с пониманием keyboard pattern;
+- generated/CMS markup имеет документированный contract.
+
+Лучшие правила подкрепляются tooling. Например, часть ошибок находят template lint rules, axe/component tests и browser
+accessibility checks. Но lint не определит, правильно ли названо действие или логично ли устроена hierarchy, поэтому
+review остается нужен.
+
+Для component library principles особенно важны: одна ошибка в primitive размножается на десятки экранов. Если design
+system `Button` внутри рендерит `div`, исправлять accessibility на уровне каждого consumer уже поздно.
+
+Не стоит превращать guidelines в каталог запретов на сотни страниц. Сильная policy короткая, объясняет **почему**
+правило существует и дает escape hatch для реальных edge cases.
+
+На интервью можно привести пример: команда запрещает clickable `div` не из-за вкуса, а потому что native `button`
+содержит keyboard/focus/form behavior, которое иначе придется поддерживать вручную.
 
 </td></tr></table>
 
@@ -202,15 +568,61 @@ review и помогает screen readers, SEO, автотестам и долг
 
 **Короткий ответ**
 
-main содержит основное уникальное содержимое страницы, nav — крупный блок навигации, article — самостоятельный материал,
-пригодный для отдельного распространения, section — тематический раздел обычно с заголовком, aside — связанный, но
-второстепенный контент.
+`main` содержит основное уникальное содержимое страницы, `nav` — крупную навигацию, `article` — самостоятельный
+материал, `section` — тематический раздел обычно с heading, `aside` — связанный, но второстепенный контент.
 
 **Полный ответ**
 
-`main` содержит основное уникальное содержимое страницы, `nav` — крупный блок навигации, `article` — самостоятельный
-материал, пригодный для отдельного распространения, `section` — тематический раздел обычно с заголовком, `aside` —
-связанный, но второстепенный контент.
+Эти элементы помогают описать **роль области документа**, но не являются взаимозаменяемыми «семантическими div».
+
+**`main`**
+
+Главное уникальное содержимое текущего document. Обычно пользователь ожидает один активный `main`, к которому можно
+быстро перейти как к landmark.
+
+```html
+<main>
+  <h1>Заказы</h1>
+  <!-- основной контент страницы -->
+</main>
+```
+
+**`nav`**
+
+Крупный блок навигационных links: главное меню, навигация раздела, breadcrumbs. Не каждый набор из двух ссылок обязан
+быть `nav`. Если landmarks несколько, полезно давать им различимые accessible names.
+
+```html
+<nav aria-label="Основная навигация">...</nav>
+<nav aria-label="Навигация по документации">...</nav>
+```
+
+**`article`**
+
+Самостоятельная единица контента, которую в принципе можно использовать или распространять отдельно: пост, новость,
+комментарий, карточка публикации.
+
+**`section`**
+
+Тематическая часть документа. Обычно у нее есть heading. Если container нужен только для layout/styling и у него нет
+отдельной темы, `div` часто лучше.
+
+**`aside`**
+
+Контент, связанный с окружающим материалом, но вторичный по отношению к основному потоку: related links, sidebar,
+дополнительная справка.
+
+Элементы могут вкладываться друг в друга. Например, `article` может содержать несколько `section`, а внутри `article`
+может быть `aside` с дополнительной информацией.
+
+`header` и `footer` тоже зависят от контекста: они могут относиться не только ко всей странице, но и к конкретному
+`article`/`section`.
+
+Главная ошибка — выбирать element по визуальному положению. Sidebar не всегда `aside`, а верхняя полоса не всегда
+`header`: semantics определяются назначением content.
+
+На интервью полезно объяснять через вопрос **«может ли этот кусок существовать самостоятельно и какую роль он играет в
+структуре документа?»**, а не перечислять определения наизусть.
 
 </td></tr></table>
 
@@ -222,15 +634,59 @@ main содержит основное уникальное содержимое
 
 **Короткий ответ**
 
-button выполняет действие: отправляет форму, открывает dialog, меняет состояние. a с href выполняет навигацию к URL.
-Правильный элемент сразу дает ожидаемые keyboard behavior, semantics и browser features вроде открытия ссылки в новой
-вкладке.
+`button` выполняет действие в текущем интерфейсе: submit, открыть dialog, изменить состояние. `a` с `href` выполняет
+навигацию к URL. Правильный элемент дает ожидаемые keyboard semantics и browser features без ручной имитации.
 
 **Полный ответ**
 
-`button` выполняет действие: отправляет форму, открывает dialog, меняет состояние. `a` с `href` выполняет навигацию к
-URL. Правильный элемент сразу дает ожидаемые keyboard behavior, semantics и browser features вроде открытия ссылки в
-новой вкладке.
+Практическое правило простое: **если после активации меняется location/resource — ссылка; если выполняется команда в
+текущем UI — кнопка**.
+
+Навигация:
+
+```html
+<a href="/settings/security">Настройки безопасности</a>
+```
+
+Действие:
+
+```html
+<button type="button">Открыть фильтры</button>
+```
+
+Submit формы:
+
+```html
+<button type="submit">Сохранить</button>
+```
+
+Почему это важно не только для accessibility.
+
+**Link дает browser navigation contract**
+
+Пользователь может скопировать URL, открыть link в новой вкладке, использовать context menu, browser history и обычные
+link shortcuts. `<button (click)="router.navigate(...)" />` может визуально перейти на страницу, но теряет часть этого
+поведения.
+
+**Button дает action contract**
+
+Он focusable, активируется ожидаемыми keyboard keys, поддерживает `disabled`, участвует в forms и сообщает правильную
+role assistive technologies.
+
+Clickable `div` требует вручную добавить `tabindex`, role, keyboard handlers, focus styles и disabled semantics. Даже
+после этого легко забыть edge case.
+
+Есть случаи, где UI выглядит как button, но semantics остаются link: например CTA «Открыть отчет» ведет на `/report/42`.
+CSS не должен определять HTML element.
+
+И наоборот, «Назад» внутри wizard может быть button, если он меняет локальный step без navigation URL. Но если product
+использует реальную browser history/route, link или navigation API может быть правильнее.
+
+У `button` внутри form стоит явно задавать `type`, потому что default behavior может быть submit и вызвать неожиданный
+form submission.
+
+На интервью сильная формула: **`a` представляет destination, `button` — command. Выбор native primitive сохраняет
+browser capabilities, keyboard behavior и semantics, которые дорого и рискованно воспроизводить JavaScript-ом**.
 
 </td></tr></table>