Компоненты и параметры оформления

После нескольких уроков у reading-lab появились согласованные шапка, проза, листинг, таблица, иллюстрация и нижняя навигация. Пока их правила распределены по последовательным дополнениям, что удобно для обучения. Для сопровождения библиотеки нужно ещё одно представление: какие роли существуют, какие параметры общие и какие варианты допустимы.

В этом уроке вы опишете небольшую дизайн-систему учебной статьи. Это не новая библиотека JavaScript и не генератор Markdown. Результатом станет договор компонентов и набор именованных параметров, которые объясняют устройство уже готовой страницы.

Параметр выражает решение

В цветовом уроке мы использовали переменные с именами ролей. Тот же подход подходит ширине и расстояниям. --lab-reading-width объясняет назначение лучше, чем --lab-size-68. Если после смены шрифта ширина изменится, имя продолжит описывать решение. Число остаётся значением, а не смыслом.

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

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

Также важно различать общую роль и отдельный вариант. lab-code-wrap из седьмого урока меняет поведение строк определённого блока. Он не становится новым независимым компонентом с другой палитрой, заголовком и системой размеров. Такое разграничение помогает избежать множества похожих копий.

Небольшой слой переменных

Создайте полный файл lesson-14.css. Он добавляется после предыдущих и переопределяет названные свойства через параметры:

.reading-lab {
  --lab-page-width: 76rem; --lab-reading-width: 68ch; --lab-aside-width: 16rem;
  --lab-space-small: .75rem; --lab-space-text: 1rem; --lab-space-block: 1.5rem;
  --lab-space-section: 2.5rem; --lab-page-pad: 1.5rem;
}
.reading-lab .lab-main { max-width: var(--lab-page-width); padding: var(--lab-page-pad); }
.reading-lab .lab-prose { max-width: var(--lab-reading-width); }
.reading-lab .lab-prose p { margin-block-end: var(--lab-space-text); }
.reading-lab .lab-prose h2 { margin-block-start: var(--lab-space-section); }
.reading-lab .lab-prose section:first-child > h2 { margin-block-start: 0; }
.reading-lab .lab-note { padding: var(--lab-space-text); margin-block: var(--lab-space-block); }
@media (min-width: 64rem) {
  .reading-lab .lab-layout { grid-template-columns: minmax(0, 1fr) var(--lab-aside-width); }
}

Ожидается прежняя форма страницы, но у части решений появятся общие имена. Само переименование не должно визуально менять макет. Если после переноса параметров возникло новое расстояние, проверьте исходное значение и порядок правил. Такой переход позволяет отделить реорганизацию CSS от нового дизайна.

Пользовательские свойства участвуют в каскаде и могут наследоваться. var подставляет их значение в подходящее свойство; механизм подробно описан в MDN. В нашем примере область переменных ограничена .reading-lab. Мы не переопределяем глобальные значения действующего сайта.

Порог медиаусловия оставлен обычным числом. Нельзя просто записать пользовательскую переменную в размер условия @media и ожидать того же механизма, что внутри декларации свойства. Система параметров должна учитывать реальное устройство CSS. Лучше ясно документировать один порог, чем строить фиктивную универсальность.

Контракт компонента

Для каждого крупного блока опишите три вещи: назначение, обязательное содержимое и допустимые варианты. У листинга назначение — передача точного технического текста; содержимое — подпись и pre/code; варианты — сохранение строк либо явно выбранный перенос. Это описание полезнее списка всех текущих CSS-свойств.

У иллюстрации обязательны объект и связанная подпись, когда она поясняет результат. Объект может быть собственной схемой или скриншотом, но не выдуманным изображением выполненной программы. Известная пропорция ресурса позволяет организовать место загрузки. Цветная рамка не относится к обязательному устройству, потому что не объясняет учебную функцию.

У метаданных состав необязателен целиком: отображаются только известные сведения. У навигации количество соседних ссылок зависит от места в последовательности. Такие ограничения должны попасть в договор, иначе разработчик может создать красивый вариант, который требует фиктивной даты или пустой предыдущей главы.

Запишите также, кто владеет содержанием и кто — оформлением. Автор выбирает точный пример и пишет пояснение. Общий компонент задаёт поверхность, расстояния и поведение ширины. Если автору постоянно приходится вручную вставлять стилевые атрибуты, это признак отсутствующего варианта или неудобной границы ответственности.

Перенос макета в средство проектирования

Те же роли можно представить в Figma или Penpot: отдельные образцы текста, палитра, размеры и варианты компонентов. Названия должны совпадать по смыслу с кодом, хотя не обязаны буквально копировать все селекторы. Тогда обсуждение «ширины чтения» относится к одному решению в макете и CSS.

Не воспроизводите каждую случайную координату страницы как самостоятельный параметр. Макет показывает правило размещения, а браузер получает настоящий текст с изменяемой высотой. Если в визуальном инструменте карточки выглядят хорошо только при жёстко заданном размере, нужно испытать длинное название и несколько абзацев, прежде чем переносить решение.

У компонента полезно иметь образец сложного содержимого. Пустой прямоугольник не показывает, как ведут себя переносы и подписи. Для листинга возьмите условную длинную строку из reading-lab, для таблицы — уже заданные четыре колонки. Такие образцы помогают обсуждать ограничения без придуманного результата измерения.

Если рисунок и код расходятся, не выбирайте автоматически один как истину. Выясните, какое решение зафиксировано в договоре и почему появилась разница. Например, в рисунке мог остаться старый размер боковой области, а CSS уже учитывает увеличенный текст. Согласование должно завершиться ясным правилом, а не молчаливой правкой снимка.

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

Перед включением нового варианта назовите его отличие и минимальные исходные данные. Например, режим переноса предназначен для текстового вывода, а не для любого фрагмента программы. Такая запись предотвращает случайный выбор компонента по внешней привлекательности. Дизайн-система помогает редакции принимать решения, а не только предоставляет набор прямоугольников.

Изменение без каскада случайных копий

Для небольшого эксперимента измените только --lab-reading-width с исходного значения на чуть меньшую ширину. Ожидается изменение переносов прозы, а не всей оболочки и ширины оглавления. Это показывает, что параметры отражают отдельные задачи. Если одновременно изменилось всё, границы системы недостаточно ясны.

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

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