Перейти к основному содержимому

HTML и CSS

Для чего модуль​

Научиться верстать не «чтобы выглядело похоже», а как инженер: с семантикой, доступностью, устойчивым layout и предсказуемым поведением в реальных данных.

Результат после прохождения​

  1. Вы проектируете разметку как контракт для браузера, скринридеров и SEO.
  2. Вы выбираете Flex/Grid/адаптивные техники по задаче, а не по привычке.
  3. Вы управляете каскадом и специфичностью без хаотичных !important.
  4. Вы умеете снижать CLS и визуальные регрессии на реальных экранах.

Термины и аббревиатуры​

ТерминКоротко
Semantic HTMLСмысловая разметка
ARIAАтрибуты доступности
SpecificityПриоритет CSS
ResponsiveАдаптация под экраны
CLSМетрика визуального сдвига

Фокус по грейдам​

  1. Junior: понимать базовые механики и объяснять их простыми примерами.
  2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
  3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем​

  1. Берите один реальный экран (каталог, форма, карточка) и улучшайте его по урокам.
  2. После каждого урока проверяйте страницу в keyboard-only режиме.
  3. Для каждой правки фиксируйте причину: UX, a11y, производительность, поддерживаемость.

Программа модуля​

Урок 1. Семантика и доступность​

Цель: строить HTML-структуру, которую корректно читают браузер, assistive-технологии и поисковики.

Семантика как структура смысла​

  1. Используйте header/main/nav/aside/footer для смысловых областей.
  2. Заголовки (h1...h6) должны отражать иерархию контента.
  3. Кнопка — для действия, ссылка — для навигации.

Формы и доступность​

  1. У каждого input должен быть связанный label.
  2. Ошибки валидации должны быть программно связаны с полем.
  3. Состояния focus, disabled, invalid — обязательная часть UX.
<label for="email">Email</label>
<input id="email" name="email" type="email" aria-describedby="email-error" />
<p id="email-error" role="alert">Введите корректный email</p>

ARIA: только когда нативного HTML недостаточно​

  1. Сначала используйте нативные элементы.
  2. ARIA не исправляет плохую структуру, а дополняет корректную.
  3. Избыточная ARIA часто ухудшает доступность.

Где ломается в проде​

  1. Placeholder используется как замена label.
  2. Модалка не держит focus trap.
  3. Нельзя пройти ключевой user-flow с клавиатуры.

Мини-задача (обязательная)​

Возьмите форму логина и доведите до базового a11y уровня: label, ошибки, keyboard-nav, видимый focus, корректные role/aria.

Что спросит интервьюер: почему placeholder не заменяет label.

Критерий готовности по уроку: вы можете пройти критичный сценарий страницы только клавиатурой и объяснить, почему разметка семантически корректна.

Урок 2. Layout и адаптивность​

Цель: собирать устойчивые layout, которые не разваливаются от реального контента.

Flexbox vs Grid​

  1. Flex — одно измерение (ряд или колонка).
  2. Grid — двумерная сетка (ряды + колонки).
  3. В сложных экранах обычно используется комбинация Flex + Grid.

Responsive стратегии​

  1. Mobile-first как дефолт.
  2. min/max/clamp для гибкой типографики и размеров.
  3. Проверка edge-cases: длинные слова, пустые блоки, сверхдлинные списки.

Типовые источники layout-багов​

  1. Неправильные min-width в flex-контейнере.
  2. 100vh на mobile без учета системных UI панелей.
  3. Неуправляемый overflow и «прыжки» интерфейса.

Мини-задача (обязательная)​

Сверстайте карточный список с 3 breakpoints и проверьте: очень длинный заголовок, пустое описание, 50+ карточек.

Что спросит интервьюер: когда Grid лучше Flexbox и наоборот.

Критерий готовности по уроку: layout остается стабильным на основных ширинах и edge-cases без ad-hoc фиксов.

Урок 3. CSS-архитектура​

Цель: сделать стили масштабируемыми и безопасными для командной разработки.

Каскад и специфичность​

  1. Сначала управляйте порядком и слоем, а не повышайте специфичность.
  2. Используйте :where()/слои/утилитарные классы осознанно.
  3. !important — только как исключение с документированной причиной.

Стратегии организации стилей​

  1. Component-scoped стили для локальности.
  2. Design tokens для цветов/spacing/typography.
  3. Единые naming rules и правила композиции классов.

Антипаттерны​

  1. Глобальные селекторы, которые задевают чужие компоненты.
  2. Копипаст переменных и «почти одинаковых» классов.
  3. Стили, завязанные на структуру DOM, которая часто меняется.

Мини-задача (обязательная)​

Разберите конфликт специфичности в существующем экране и устраните его без !important. Добавьте короткий комментарий, почему решение устойчивое.

Что спросит интервьюер: как вы организуете CSS в команде из нескольких разработчиков.

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

Урок 4. Производительность и UX​

Цель: понимать, как решения в HTML/CSS влияют на скорость и визуальную стабильность.

Влияние верстки на метрики​

  1. Ресурсы выше fold влияют на LCP.
  2. Нестабильные размеры блоков и media влияют на CLS.
  3. Тяжелые CSS-эффекты могут ухудшать responsiveness.

Практические техники​

  1. Резервируйте размеры для изображений/баннеров.
  2. Оптимизируйте font loading и fallback-шрифты.
  3. Проверяйте критические состояния skeleton/loading/empty.

Где ломается в проде​

  1. Асинхронно подгружается контент без зарезервированного пространства.
  2. Иконки/шрифты подменяются с заметным layout shift.
  3. Стили «для красоты» ухудшают время интерактивности.

Мини-задача (обязательная)​

Уменьшите CLS одного экрана и зафиксируйте: исходное значение, изменения, итоговое значение и визуальный эффект.

Что спросит интервьюер: какие CSS-решения чаще всего вызывают деградацию рендеринга.

Критерий готовности по уроку: вы связываете каждое изменение в верстке с метрикой и пользовательским эффектом.

Перед DevTools-практикой пройдите Browser Rendering: layout change и transform composite, чтобы различать layout/paint/composite стоимость.

Практика​

1. Semantic structure и accessible form​

Связка: Senior q-9, DOM/a11y audit pack.

Что сделать:

  1. Сверстайте форму логина или заявки с label, fieldset/legend там, где есть группа, понятным error text и predictable focus order.
  2. Проверьте keyboard-only сценарий: tab order, submit, ошибка, возврат фокуса к проблемному полю.
  3. Запишите, что именно услышит screen reader для поля с ошибкой.

Артефакт: HTML-фрагмент формы + a11y audit table check -> expected -> actual -> fix.

Критерий готовности: вы объясняете семантику через поведение пользователя и assistive tech, а не через список тегов.

2. Layout, responsive и overflow​

Связка: HTML, CSS, строка HTML, CSS and rendering в Practice Bridges.

Что сделать:

  1. Сверстайте экран form + card list в 3 брейкпоинтах: mobile, tablet, desktop.
  2. Добавьте long content cases: длинный email, длинный заголовок карточки, пустое состояние, 1 карточка, 20 карточек.
  3. Исправьте один конфликт специфичности без !important и зафиксируйте, почему выбранный selector устойчивее.

Артефакт: layout checklist breakpoint -> content case -> risk -> fix, плюс короткая specificity note.

Критерий готовности: вы можете показать, где layout ломается, почему это происходит и какой CSS-выбор чинит причину, а не симптом.

3. Rendering, CLS/LCP и DevTools evidence​

Связка: Senior q-3, Next.js q-14, Rendering, Browser Rendering: layout thrashing.

Что сделать:

  1. Найдите один риск CLS: изображение без размеров, поздний баннер, web font shift или динамический контент над fold.
  2. Найдите один риск LCP: тяжелое hero/image, render-blocking CSS/JS или поздняя загрузка критичного контента.
  3. Зафиксируйте baseline/after: что изменилось, какая метрика затронута, какой пользовательский эффект улучшился.

Артефакт: mini performance note problem -> evidence -> fix -> expected metric impact -> user impact.

Критерий готовности: вы связываете HTML/CSS-решение с измеримой метрикой и можете доказать изменение через DevTools/Lighthouse trace.

Связь с треками и вопросами​

  1. Для базы: сначала закройте этот модуль, затем HTML и CSS.
  2. Для senior-level объяснения: добавьте Senior q-3 и Senior q-9.
  3. Для практического контроля: используйте DOM/a11y audit pack и строку HTML, CSS and rendering в Practice Bridges.
  4. Повторение: сначала артефакт, потом ответ. Без готового audit/performance note ответ считается только теорией.

Критерий готовности​

Ready: вы аргументируете HTML/CSS-решения через доступность, устойчивость layout и измеримый UX-эффект.

Partial: вы умеете сверстать экран, но не показываете keyboard/a11y проверку, overflow cases или baseline/after.

Not ready: вы пересказываете CSS-свойства без конкретного DOM/layout/performance бага и без проверки в браузере.

Артефакты после модуля​

  1. HTML-фрагмент доступной формы + error/focus rules.
  2. A11y audit table check -> expected -> actual -> fix.
  3. Responsive layout checklist для 3 брейкпоинтов и long content cases.
  4. Specificity note: как исправлен конфликт без !important.
  5. Mini performance note по CLS/LCP с baseline/after и пользовательским эффектом.

Куда дальше​

  1. JavaScript
  2. React
  3. HTML
  4. CSS