4 строки CSS, которые копируют все — и никто не проверял

/* Make text look crisper and more legible in all browsers */
body {
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  font-smoothing: antialiased;
  text-rendering: optimizeLegibility;
}

Источник: Finsweet Client-First

Если ты работаешь с Webflow — наверняка вставлял этот сниппет. И скорее всего не задавал вопросов. Это логично. Источник авторитетный, комментарий убедительный. Люди тянут этот код из проекта в проект, не проверяя.

Мне стало интересно — а что здесь реально работает? И правда ли это «in all browsers», как обещает комментарий? Спойлер: нет.

Что такое Finsweet Client-First

Client-First — гайдлайны и стратегии для организации и поддержки Webflow-проектов. Один из самых популярных фреймворков в Webflow-комьюнити. В составе есть готовый «Global Styles Embed» — код, который вставляется в каждый проект и уже включён в стартовый шаблон Client-First.¹

Сниппет выше — часть этого эмбеда, раздел «Text clarity».

Именно потому что источник воспринимается как best practice, этот код почти никогда не подвергается сомнению. Берётся как есть — и живёт в проектах годами. Скорее всего, данный код никто не валидировал, поэтому сниппет просто не обновляется.

Разбираем построчно

-webkit-font-smoothing: antialiased — ✅ работает, но только на macOS

-webkit- — вендорный префикс движка WebKit. Означает что свойство нестандартное: реализовано браузерами самостоятельно, без стандарта W3C. Непрефиксной версии не существует — и не появится, пока свойство не стандартизировано.

Визуально — текст становится тоньше и легче, ближе к тому, как он выглядит в Figma. Свойство переключает режим сглаживания шрифта: с субпиксельного на полутоновое (grayscale antialiasing).

Работает исключительно на macOS: Safari, Chrome, Edge, Firefox 128+. На Windows, Linux и даже iOS Safari — никакого эффекта, браузер просто игнорирует это свойство.²³

Важный контекст: начиная с macOS Mojave (2018) Apple отключила субпиксельное сглаживание на уровне системы. Браузеры продолжают его использовать по умолчанию — поэтому -webkit-font-smoothing: antialiased приводит веб-рендеринг в соответствие с остальной macOS.³

Оставляем? Да. Но понимаем, что это macOS-only, а не «all browsers».

-moz-osx-font-smoothing: grayscale — ✅ работает, с 2024 года избыточна

Firefox-специфичный («-moz» — mozilla) алиас того же поведения. Введён в Firefox 25 (2013) как намеренно ограниченное свойство — «osx» в названии сигнализирует о платформенной привязке.

В июле 2024 вышел Firefox 128, который добавил нативную поддержку -webkit-font-smoothing. С этого момента -moz-osx-font-smoothing фактически дублирует первую строку для Firefox на macOS.⁴⁵

Оставляем? Да, для обратной совместимости. Если поддержка Firefox до июля 2024 не нужна — строку можно убрать.

font-smoothing: antialiased — ❌ мёртвый код

Эта строка не делает ничего. Совсем.

Свойство font-smoothing (с «-ing») никогда не существовало ни в одной CSS-спецификации W3C. В черновике CSS3 Fonts 2002 года фигурировало другое свойство — font-smooth (без «-ing»), с другим синтаксисом и значениями. Но оно так и не добралось до рекомендации.⁶

Ни один браузер — Chrome, Safari, Firefox, Edge — не распознаёт это свойство. Строка парсится и безмолвно игнорируется. Можно проверить самостоятельно: W3C CSS Validator выдаст ошибку — «Property font-smoothing doesn’t exist».

Популярное заблуждение — добавить «непрефиксную версию на будущее». Но font-smoothing не существует ни в одной спецификации — проверь сам в MDN.⁷

Оставляем? Нет. Удаляем.

text-rendering: optimizeLegibility — ⚠️ работает, но опасна на body

Это SVG-свойство, которое браузеры поддерживают и для HTML-элементов. Включает кернинг (точные отступы между буквами) и лигатуры (специальные соединения типа fi, fl) — текст выглядит типографически точнее.

Проблема в том, что применённое ко всему body, это затрагивает весь текст на странице. И здесь есть реальные задокументированные баги в Chromium: текст становится невидимым в сочетании с <video>, пропадают пробелы между словами, текст выходит за границы контейнера.⁸⁹

MDN прямо указывает: не рекомендуется для обычного текста статей из-за возможных проблем с производительностью. Оптимально для крупных заголовков — коротких и больших.¹⁰

Ещё один факт: современные браузеры уже включают кернинг и лигатуры по умолчанию. На практике разница при добавлении optimizeLegibility к body минимальна — а риски есть. Если кернинг нужен явно — есть стандартная CSS-альтернатива без побочных эффектов: font-kerning: normal (стандартное свойство из CSS Fonts Module, поддерживается Chrome 33+, Firefox 32+, Safari 9+).

Оставляем? Не на body. Точечно — только на заголовках.

Итог: что реально нужно в 2026

Из четырёх строк — две рабочие, одна мёртвая, одна потенциально вредная при применении к body. Комментарий «in all browsers» не соответствует реальности ни для одной из них.

Оптимизированная версия:

/* Font smoothing — macOS only */
body {
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

/* Kerning & ligatures — headings only */
h1,
h2,
h3,
h4,
h5,
h6 {
  text-rendering: optimizeLegibility;
}

Это не наезд на Finsweet. Client-First — полезная методология, и сниппет появился по делу. Просто у любого «best practice» есть дата рождения. И иногда стоит её проверить.