Grid Layout решил много задач с раскладкой, но одна проблема долго оставалась без решения. Представьте три карточки в сетке. У каждой — заголовок, описание и кнопка. Высота заголовков разная: в одной карточке текст длиннее, в другой короче. В итоге кнопки стоят на разной высоте, и сетка выглядит неаккуратно.

Раньше это решали через JavaScript: вычисляли высоту заголовков и выставляли min-height. Или просто мирились с несовершенством.

Subgrid позволяет дочернему элементу участвовать в сетке родителя. Карточка занимает несколько строк родительской сетки — и все её внутренние блоки выравниваются по общим линиям.

Долгое время адаптивная вёрстка строилась на медиавыражениях: браузер смотрит на ширину окна и применяет нужные стили. Это работало, но создавало одну постоянную проблему.

Представьте карточку товара. На широком экране она выглядит горизонтально: слева фото, справа текст. На узком — вертикально: фото сверху, текст снизу. Казалось бы, медиавыражение справится. Но что если эту же карточку нужно показать в узкой боковой колонке на широком экране? Медиавыражение видит только ширину окна — она большая, а значит, карточка будет горизонтальной, хотя места у неё нет.

Container queries решают именно эту задачу: элемент адаптируется под размер своего контейнера, а не под размер окна.

Если вы когда-нибудь подключали стороннюю библиотеку стилей и потом пытались её переопределить — вы знаете эту боль. Пишете правило, оно не работает. Добавляете класс поконкретнее — всё равно не работает. В итоге пишете !important и расстраиваетесь, потому что теперь нужно всё время учитывать это в дальнейшей работе.

Это называют войной специфичности. Возникает она потому, что CSS решает конфликты через длину и конкретность селекторов, а не через то, кто написал правило позже и кто важнее по смыслу.

В 2022 году в браузерах появился @layer — способ самим расставить приоритеты между группами стилей.

Запрограммировать модальное окно — одна из самых частых задач во фронтенде. Раньше для этого брали готовую библиотеку, писали десятки строк JavaScript, вручную блокировали прокрутку страницы, управляли фокусом и добавляли затемнение через отдельный div. Всё это работало, но требовало много кода и было легко сломать.

В HTML уже давно есть специальный элемент для этого — тег <dialog>. Долго его поддержка была неполной, но с 2022 года он работает во всех современных браузерах, и теперь им можно пользоваться без оговорок.

Есть задача, которую каждый JavaScript-разработчик решает регулярно: получить последний элемент массива. Казалось бы, мелочь. Но стандартного красивого способа долго не было.

Можно писать arr[arr.length - 1] — работает, но громоздко. Можно использовать arr.slice(-1)[0] — ещё хуже. Оба варианта требуют знать длину массива или создавать промежуточный массив ради одного элемента.

В 2022 году в JavaScript появился метод .at(), который решает это элегантно.

Бывает такая ситуация: нужно задать один стиль для нескольких разных элементов в разных контекстах. Например, сделать красными все ссылки внутри статьи, боковой панели и подвала. Без специальных псевдоклассов получается громоздко:

article a,
aside a,
footer a {
  color: red;
}

Три строки ради одного правила. Если таких правил много — CSS превращается в простыню. :is() и :where() решают это элегантно.

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

Вы открываете проект утром, копируете в нейронку задачу, получаете красивый компонент — и начинаете его переделывать. Меняете названия переменных, добавляете проверку данных с сервера, убираете стили, которые конфликтуют с общей темой. Знакомо?

Дело не в том, что нейросеть плохо пишет код. Дело в том, что она пишет код для другой задачи — для той, которую вы описали, а не для той, которая есть на самом деле.

Эта статья о том, как правильно описывать задачу, чтобы получить рабочий код с первого раза. Разберём три главных направления: компоненты, стили и тесты. А ещё поговорим о том, как давать нейросети контекст — описание данных с сервера и правила дизайн-системы.

Представьте ситуацию: компания N ищет разработчика. Пришло двести откликов. И у каждого кандидата — пять лет опыта. Но вы уже знаете, что у части из них этот опыт нарисован. Как понять, у каких именно?

Именно из этого тупика и выросло понятие цифрового профессионального следа (ЦПС). Суть простая: любое внешнее свидетельство вашей работы, которое существует независимо от вас и которое вы не можете подправить задним числом.

Вышел Vite 8 — самое крупное изменение архитектуры с версии 2. Главное: под капотом теперь работает единственный бандлер Rolldown, написанный на Rust. Раньше их было два — esbuild для разработки и Rollup для финальной сборки. Теперь один инструмент делает всё.

После продолжительного изучения темы выяснилось, что Popover API и Dialog API кардинально отличаются с точки зрения доступности. Если вы стоите перед выбором, придерживайтесь такого правила:

• Используйте Popover API для большинства поповеров.
• Используйте Dialog API только для модальных диалогов.

Firefox 148 стал первым браузером, реализовавшим стандартизированный Sanitizer API — новый инструмент, который встраивает санитизацию HTML непосредственно в процесс вставки содержимого в DOM и делает защиту от XSS доступной по умолчанию.

Межсайтовый скриптинг (XSS) по-прежнему остаётся одной из наиболее распространённых уязвимостей в интернете. Новый стандартизированный Sanitizer API даёт веб-разработчикам простой способ очищать ненадёжный HTML перед его вставкой в DOM. Firefox 148 стал первым браузером, поставившим этот API в стабильную версию, — ожидается, что остальные браузеры последуют примеру в ближайшее время.

XSS-уязвимость возникает, когда сайт непреднамеренно позволяет злоумышленникам внедрять произвольный HTML или JavaScript через пользовательский контент. С её помощью атакующий может отслеживать и подменять действия пользователей и систематически похищать их данные — до тех пор, пока уязвимость не будет устранена. XSS исторически крайне сложен в предотвращении и на протяжении почти десяти лет стабильно входит в тройку самых опасных веб-уязвимостей (CWE-79).

Mozilla участвовала в борьбе с XSS с самого начала: ещё в 2009 году Firefox инициировал разработку стандарта Content-Security-Policy (CSP). CSP позволяет сайтам ограничивать, какие ресурсы (скрипты, стили, изображения и т. д.) браузер вправе загружать и исполнять, формируя надёжный рубеж обороны. Тем не менее, несмотря на постоянные улучшения, CSP так и не получил широкого распространения: его внедрение требует существенных архитектурных изменений и регулярного внимания специалистов по безопасности.

Sanitizer API призван заполнить этот пробел, предоставляя стандартизированный механизм преобразования вредоносного HTML в безопасный. Метод setHTML() встраивает санитизацию непосредственно в процесс вставки HTML, обеспечивая защиту на уровне умолчаний. Пример очистки небезопасного HTML:

document.body.setHTML(`<h1>Hello my name is <img src="x" 
onclick="alert('XSS')">`);

При такой санитизации элемент <h1> будет сохранён, а элемент <img> вместе с атрибутом onclick — удалён, что устраняет XSS-атаку. В результате останется следующий безопасный HTML:

<h1>Hello my name is</h1>

Разработчики могут усилить защиту от XSS с минимальными изменениями в коде, заменив подверженные ошибкам присваивания innerHTML на вызовы setHTML(). Если настройки по умолчанию окажутся слишком строгими или, напротив, недостаточно строгими для конкретного случая, можно передать пользовательскую конфигурацию, определяющую, какие элементы и атрибуты следует сохранить или удалить. Для экспериментов до внедрения API на продакшн-сайте рекомендуется воспользоваться песочницей Sanitizer API.

Для ещё более надёжной защиты Sanitizer API можно сочетать с Trusted Types, которые централизуют контроль над разбором и вставкой HTML. После перехода на setHTML() включить принудительное применение Trusted Types становится проще — зачастую без необходимости создавать сложные пользовательские политики. Строгая политика может разрешать setHTML(), блокируя остальные небезопасные способы вставки HTML, что помогает предотвращать регрессии в безопасности.

Sanitizer API упрощает замену присваиваний innerHTML на вызовы setHTML() в существующем коде, устанавливая новый безопасный стандарт и защищая пользователей от XSS-атак. Firefox 148 поддерживает как Sanitizer API, так и Trusted Types. Принятие этих стандартов позволит любому разработчику предотвращать XSS без выделенной команды безопасности и масштабных архитектурных изменений.

Февраль принёс несколько полезных обновлений: атрибут для передачи направления текста в формах получил поддержку во всех браузерах, появились удобные методы для работы с Map, а CSS обзавёлся новой функцией для сложных фигур. Разбираем, что уже можно использовать и что стоит взять на заметку.

Или: как одна нелепая строка кода дала ускорение в 100 раз.

Всегда знаешь, что попался хороший баг, когда первая реакция — «как такое вообще возможно?»

Я дорабатывал панель управления одного веб-приложения и заметил, что она стала загружаться вечность. Раньше страница открывалась за секунду — теперь за десять. Что-то явно шло не так.

Естественно, я обвинил React.

Ну, конечно, в современном веб-приложении источников проблем с производительностью хватает: сторонний JavaScript, перегруженные серверы, раздутые ресурсы, отсутствующие индексы в базе данных — длиннющий список. Но десятилетия разработки для веба подсказывали: это проблема фронтенда. Я просто чувствовал это. Страница выглядела дёргающейся при загрузке. А экосистема React, при всей своей относительной приемлемости сегодня, полна способов превратить кодовую базу в запутанный тормозящий клубок.

Чтобы подтвердить теорию, я объяснил Claude, что панель загружается медленно, что наверняка виноват React, и попросил проанализировать проблемы и отсортировать их по серьёзности. И действительно, Claude нашёл кучу подозрительного в React: лишние перерисовки, пропущенные мемоизации. Выяснилось, что мы ещё не перешли на React Compiler. Я попросил Claude сделать первый проход по самым простым и серьёзным проблемам, и…

Это почти ничего не дало. Может, дело не в React?

Засучил рукава и начал разбираться по-настоящему.

1. Может, сервер медленный? Немного — но фронтенд он не блокирует.
2. Проблема во всех браузерах? Нет. Почему-то только в Safari.
3. Значит, виноват сторонний JavaScript? Intercom? Нет. PostHog? Нет.
4. Ладно, роем глубже — смотрим временную шкалу производительности.

Инспектор производительности Safari за последние годы заметно разошёлся с инструментами на основе Chromium и на этой странице работал капризно. Но картину он нарисовал вполне отчётливую: 7+ секунд тратились не на разбор JavaScript, не на вычисление стилей и не на загрузку сети. 94% процессора на M1 Max уходило на… компоновку вёрстки?

В подробностях было видно несколько проходов компоновки длительностью более 1600 мс каждый. Для сравнения: это примерно в 100 раз медленнее нормы. Что-то было серьёзно не так с тем, как браузер выстраивал страницу. Flexbox может чуть замедляться, но не настолько же.

Если вы читаете эту статью, вам зачем-то понадобилось сгенерировать код с помощью ИИ-агента. И, скорее всего, вы поискали в интернете и нашли, что есть какой-то там бесплатный ИИ-агент Qwen-Code. Вот что пишут о Qwen Code его создатели:

«Qwen Code — это агентский инструмент для программирования, который работает в вашем терминале и помогает превращать идеи в код быстрее, чем раньше»

Не слишком-то развёрнуто, верно? В этом руководстве мы за несколько минут научимся пользоваться Qwen Code и сделаем собственный небольшой проект с домашней страничкой. Важно: мы используем этот ИИ-агент для быстрой разработки сайтов, но в целом с qwen-code вы можете генерировать код на Python, C++ или любом другом языке. Или даже просто работать с файловой системой и выполнять команды в терминале!

Что понадобится для старта:

• Компьютер на любой ОС;
• Редактор Visual Studio Code (наш обзор, быстрая установка);
• Расширение Qwen Code Companion.

Приступим!

Посмотрели за вас в интернете и заботливо отобрали самые интересные демки на CSS и JavaScript.

Январь начался с мощного обновления веб-стандартов: появились новые CSS-единицы для точной типографики, заработала поддержка модулей в Service Worker’ах, а API навигации получил статус «готов к использованию». В этом обзоре — то, что уже можно применять в продакшене или начинать тестировать сегодня.

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

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

Ключевые особенности соревнования:

• сложные и объёмные макеты от профессиональных дизайн-студий;
• двухнедельный формат, ориентированный на качество, а не скорость;
• строгая многоуровневая оценка;
• жюри из опытных разработчиков из бигтеха и компаний заказной разработки.

Второй чемпионат по вёрстке завершился 19 декабря 2025 года. Ниже — его итоги и разбор уровня работ участников.

Совсем недавно в CSS появилась небольшая, но любопытная возможность — использовать внутри математических функций вроде calc() готовые константы. Это не новые свойства или сложные функции, а удобные сокращения: e, pi, infinity, -infinity и NaN. Они доступны в браузерах с конца 2022 года, но по-прежнему нечасто встречаются в реальном коде. Разберём, зачем они нужны и когда могут пригодиться.

Константы работают только внутри calc() и её «родственников» — min(), max(), clamp(), sin(), cos() и прочих математических функций. Просто написать font-size: e нельзя, а font-size: calc(e * 1rem) — вполне корректно.

.element {
  font-size: calc(e * 0.5rem); /* ≈ 1.359rem */
}

Константа e — основание натурального логарифма, примерно 2.718. Её можно использовать для плавных, экспоненциальных изменений, например, при анимациях или масштабировании.

@keyframes grow {
  to {
    transform: scale(calc(pow(e, 0.5)));
  }
}

Это эквивалентно scale(1.64872…), но запись через e и pow() читается как «растём в e в степени 0.5» — точнее и выразительнее, чем просто магическое число.

Константа pi (≈ 3.14159…) особенно полезна при работе с углами, особенно в радианах. Например, поворот на 180° — это pi радиан:

.element {
  rotate: calc(pi * 1rad);
}

Можно комбинировать с тригонометрическими функциями:

.element {
  --t: 0.3;
  transform: translateX(calc(100px * sin(calc(pi * var(--t)))));
}

Здесь элемент колеблется по синусоиде, и один полный цикл приходится ровно на изменение --t от 0 до 2.

Более экзотичные константы — infinity, -infinity и NaN. Они не числа в привычном смысле, но ведут себя как числовые значения, и браузер «зажимает» их до максимально или минимально допустимых величин. Например, z-index: calc(infinity) даст самый высокий возможный z-index без необходимости подбирать гигантское число вручную.

.overlay {
  z-index: calc(infinity);
}

Это не «бесконечность» в философском смысле, а гарантированное значение, которое всегда будет больше любого другого z-index, заданного числом.

Константа NaN (Not a Number) почти никогда не нужна в повседневной разработке, но она помогает избежать неопределённого поведения при делении на ноль или других недопустимых операциях. Например:

.test {
  width: calc(0 / 0); /* вычисляется как NaN */
}

Согласно стандарту IEEE-754, любая операция с NaN возвращает NaN, и браузер в итоге проигнорирует такое свойство или заменит на значение по умолчанию. Это предсказуемо — лучше молчать, чем рисковать.

Наконец, напомним: константы чувствительны к регистру только частично. e, pi, infinity можно писать в любом регистре: E, Pi, InFiNiTy — всё сработает. А вот NaN допускает только такой вариант написания. nan, NAN или NaN() — синтаксическая ошибка.

На практике e и pi пригодятся тем, кто строит анимации, диаграммы, визуализации или работает с тригонометрией в CSS. infinity — когда нужно «перебить любой z-index». NaN — скорее для полноты реализации, чем для практического использования.

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