Якоря
Якорей в продукте пока нет ни одного. Ни одного атрибута data-lms
в интерфейсе не стоит — проверено поиском по исходникам.
Страница нужна сейчас по двум причинам. Первая: если вы ищете, как убрать колонку из таблицы заказов или сузить боковое меню, ответ сегодня — «пока никак», и лучше узнать это здесь, чем после часа подбора селекторов. Вторая важнее: объяснение, почему мы не документируем классы вёрстки, — это половина ценности всего раздела оформления, и оно верно уже сейчас.
Почему нельзя просто задокументировать наши классы #
Это возражение стоит первым, потому что от него зависит вся конструкция.
Разметка собрана из утилитарных классов:
<h3 class="text-body font-medium text-fg">Название курса</h3>
Допустим, мы объявили эти классы публичными и написали по ним справочник. Дальше произойдёт следующее.
Первое. Технический специалист школы напишет .text-body { font-size: 20px } —
и поменяет размер везде, где встречается этот класс: в карточке курса, в подписи
к платежу, в письме, в кнопке. Он этого не хотел и не узнает, пока не пожалуется
клиент.
Второе, и оно хуже. Через месяц мы переверстаем карточку и поставим там другой класс. У всех клиентов, настроивших оформление, оно сломается при обновлении, молча, задним числом. Ошибки в логах не будет: CSS не падает при неверном селекторе, он просто перестаёт применяться.
Из этого два следствия, и оба неприемлемы: либо мы больше никогда не трогаем вёрстку, либо регулярно ломаем клиентам оформление.
Поэтому наружу объявляется не то, из чего собрана вёрстка, а то, что мы намеренно объявили контрактом. Два слоя: переменные — уже работают, и якоря — будут.
Что такое якорь #
Стабильный атрибут на элементе, который человек называет словами:
<li data-lms="course-card">…</li>
<nav data-lms="rail">…</nav>
<table data-lms="orders-table">…</table>
По нему пишется правило:
[data-lms="course-card"] { box-shadow: none; border-radius: 0; }
[data-lms="rail"] { width: 200px; }
Атрибут, а не класс — намеренно. Класс можно случайно перебить утилитой и легко спутать со своим; атрибут виден как объявленный контракт и в разметке, и в CSS.
Список конечный. Якорь ставится на то, что называют словами: карточка курса, строка заказа, боковое меню, тело урока, шапка, диалог, кнопка оплаты. Не на каждый элемент подряд.
Один якорь — одна роль. Если элемент встречается в двух местах и должен настраиваться по-разному, это два якоря.
Когда появятся #
По правилу «экран, который трогают, получает якоря». Отдельной задачи «расставить якоря по всему продукту» не будет: задним числом по всему продукту это стоит вдвое дороже и делать это оказывается некому.
Первыми якоря получат экраны ближайшего этапа — мобильная админка, панель оформления, кабинет ученика. Отдельно и заранее вводится минимальный набор под задачи, которые спрашивают чаще всего: таблица заказов, таблица пользователей, карточка курса, боковое меню, тело урока.
Справочник соберётся сам #
Якорь объявляется в коде типизированно, и справочник собирается из объявлений —
так же, как переменные собираются из tokens.css.
Из этого следует проверка, которая делает справочник надёжным: якоря, которого нет в перечне, не может быть в разметке, и это ловится тестом. Рукописный справочник разошёлся бы с продуктом на третьем заходе; собранный из объявлений — не может.
У каждой записи будет: что это за элемент, где встречается, какие переменные на него влияют и пример.
Что делать сегодня #
Задачи вида «поменять цвет, шрифт, скругление, плотность» решаются переменными уже сейчас — они меняют вид везде и переживают любую нашу перевёрстку.
Задачи вида «спрятать вот этот конкретный элемент» сегодня решения не имеют. Подобрать селектор по вёрстке технически можно, но это отложенная поломка, и поддерживать её мы не будем.