PX в REM: как устроен пересчёт и зачем он нужен
Математика перевода px в rem, история базовых 16 пикселей, приём с 62.5% и ситуации, где em незаметно накапливается против вас.
Весь пересчёт — одно деление: rem равен пикселям, делённым на корневой размер шрифта. 24px при стандартной базе 16px — это 1.5rem. Всё. Конвертер PX в REM нужен не потому, что математика сложная, а потому, что делить 13 на 16 в уме сорок раз за день при переносе макета из Figma никому не хочется.
Почему именно 16 пикселей
База 16px тянется из браузеров середины девяностых: размер «medium» выбрали таким, потому что на мониторах той эпохи он примерно совпадал с печатным кеглем 12 пунктов. С тех пор ни один браузер её не менял, и на это число опирается вся экосистема. Шкала Tailwind построена вокруг него. Типографика почти любого CSS-фреймворка — тоже.
Важная деталь: пользователь может эту базу изменить. И в Chrome, и в Firefox в настройках есть размер шрифта по умолчанию, и люди со слабым зрением им реально пользуются. Если вёрстка сделана в px, настройка не работает — текст остаётся мелким. В rem — масштабируется всё. В этом и состоит аргумент про доступность, и именно поэтому критерий WCAG про увеличение текста всплывает в каждом аудите сайтов, свёрстанных в пикселях.
Зум браузера — другой механизм. Он одинаково увеличивает и px, и rem, поэтому «у меня всё зумится» ничего не говорит о том, уважает ли сайт настройку шрифта. Проверяйте настройкой, а не Ctrl-плюсом.
Приём с 62.5% и его цена
В 2004 году Ричард Раттер предложил правило html { font-size: 62.5% }: 1rem становится равен 10px, и считать можно в уме — 1.3rem это 13px, 2.4rem это 24px. На этой схеме до сих пор живёт немало старых проектов.
Работает, но берёт свою плату. Каждый сторонний виджет и каждый скопированный сниппет рассчитаны на базу 16px, так что их текст выходит на 62.5% от задуманного размера, пока не допишешь исправление. Достался проект с базой 10px — поставьте в конвертере корневой размер 10 и работайте. А вот тащить этот приём в новый проект я бы не стал.
Где кусается em
С rem всё скучно и предсказуемо: одна точка отсчёта, элемент html. Em считается от размера шрифта текущего элемента и накапливается. Вложенный список со стилем 1.2em рендерится в 1.2, потом 1.44, потом 1.728 базового размера по мере погружения. Я ловил ровно этот баг в виджете комментариев: на пятом уровне ответов текст был нелепо огромным, и никто не понимал почему.
У em есть честные применения — отступы, которые должны следовать за размером текста самого элемента, медиазапросы. Но для глобальных отступов и типографической шкалы rem избавляет от сюрпризов с накоплением.
Как читать значения Tailwind без шпаргалки
Шкала Tailwind под капотом — это rem: шаг равен 0.25rem, поэтому p-4 — это 1rem, а p-6 — 1.5rem. Размеры шрифта на той же базе: text-sm — 0.875rem, то есть 14px при стандартном корне. Когда знаешь шаг, номера классов перестают казаться случайными: умножил на 4 — получил пиксели.
Таблица в инструменте показывает частые размеры от 1px до 128px при любой заданной базе — этого хватает и на шкалу Tailwind, и на типографику большинства дизайн-систем.
Когда дизайнер в следующий раз пришлёт значения в пикселях, а стили ждут rem, вставьте числа в конвертер PX в REM и скопируйте результат прямо в CSS.