Документация LMS версия 0.1.0

Документация/Оформление/Якоря

Этого ещё нет в продукте — описывать пока нечего

Якоря

Якорей в продукте пока нет ни одного. Ни одного атрибута 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.

Из этого следует проверка, которая делает справочник надёжным: якоря, которого нет в перечне, не может быть в разметке, и это ловится тестом. Рукописный справочник разошёлся бы с продуктом на третьем заходе; собранный из объявлений — не может.

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

Что делать сегодня #

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

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

Эта страница в Markdown