Привязываем крестик к диалогу

Задача: нарисовать крестик в диалоге (попапе), который визуально выходит за границы диалога. Много видел разных реализаций в разные эпохи, дизайнеры рисуют такие макеты на моей памяти с тех времён, как появились модалки на position: fixed.

Важно, в этой задаче нужно учитывать семантику. Если вы не хотите разломать клавиатурную навигацию и доступность, крестик-кнопка должен быть внутри элемента-модалки.

Дарин Сеннефф предлагает современный вариант с Invoker Command и Anchor Positioning, где кода нужно сильно меньше, а результат вполне себе неплохой.

https://www.darins.page/articles/close-button-hang-dialog

Никаких токенов! Обезопашиваем npm publish

С учётом последних «весёлых» событий в мире npm любые хорошие советы, как работать с пакетами, не будут зря.

Зак Лезерман делится набором как раз таких советов. Мне понравился про ввод паролей только через менеджер паролей — ведь и правда автоматика менее подвержена фишингу, чем человеческое невнимание.

https://www.zachleat.com/web/npm-security/

Ещё пара уязвимостей в React Server Components

Спустя неделю после просьбы обновить уязвимые библиотеки команда React просит сделать это снова. На этот раз исследователи нашли две уязвимости, которые могут быть крайне неприятны.

CVE-2025-55184 и CVE-2025-67779 — позволяет дёрнуть серверную функцию так, чтобы вызвать бесконечный цикл, что может грохнуть или избыточно нагрузить ваш серверный CPU.

CVE-2025-55183 — позволяет достать исходный код серверной функции. Опасно, только если вы прямо в коде храните пароли или супер-секретную бизнес-логику пишете прям в серверных функциях.

В общем, снова нужно обновить библиотеки из списка в статье. И фреймворки, у которых они в зависимостях (особенно Next.js).

Интересно, как много команд завело встречку в календаре обсудить «Переезд на <не-реакт, подставить нужное>».

https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components

Голосование за фичи веб-платформы

WebDX Community Group предлагает «новый» способ влиять на вес фичей в бэклогах браузеров. Теперь в виджетах со статусом Baseline в разных источниках рядом с названием фичи появился счётчик лайков. Когда вы на него кликните, то сможете перейти в ишью на гитхабе, где тоже можете лайкнуть, если вам фича откликается и вы её хотите начать применять.

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

И да, как и в Interop, ваши лайки — это не гарантия того, что браузеры самые залайканные фичи возьмут в работу немедленно. Так вы даёте сигнал, что сообщество разработчиков нуждается в фиче. А заодно комментом можете добавить больше контекста с примерами, почему фича вам действительно нужна — это поможет добавить полезных тестов.

Полезное изменение. Любой сигнал от комьюнити лучше, чем его отсутствие.

https://web.dev/blog/upvote-features?hl=en

CSS 2025: Baseline Widely Available — тирлист

Ребята из HTML Academy позвали вечером в формате лайва обсудить фичи CSS, которые в этом году перешли в статус Baseline Widely Available. Знаю, что Лёша Симоненко подготовил тирлист, будем распределять их по мощности. Подозреваю, не обойдётся без аниме :)

Забегайте в 20:00 пообщаться через комментарии.

https://www.youtube.com/live/ASLry05R8T8

Web Performance Calendar 2025

Ещё один адвент-календарь для фронтендеров. На этот раз про перфоманс.

Уже есть 22 статьи, ещё парочка доедет в течение ближайших дней. Core Web Vitals, инсайты после исследований перфоманса, оптимизация трафика, неблокирующий рендеринг картинок, соточка в Lighthouse, полезные инструменты и прочие темы для фанатов быстрого веба.

https://calendar.perfplanet.com/2025/

RSC Explorer

После всяких CVE-2025-55182 и прочих «маркетинговых кампаний» вокруг React Server Components всё чаще видел в твиттерах запрос: «Вот было бы круто иметь удобный визуализатор тех самых RSC-запросов, чтобы дебагать».

И вот Дэн Абрамов как раз делится таким инструментом под названием RSC Explorer.

По сути это такая песочница, куда можно загнать ваш серверный и клиентский код, чтобы посмотреть, как между ними гоняются данные в процессе рендеринга RSC-приложения. Сложную файловую структуру не ждите, есть буквально два окошка, куда нужно вставить код. Но для демок этого вполне себе хватит. Те же CVE погонять можно, чтобы лучше их понять.

В репозитории написано, что проект полностью навайбкожен.

https://overreacted.io/introducing-rsc-explorer/

Tbilisi JS XMas Stream 2025

Завтра буду вечером смотреть классные доклады и даже что-то говорить в эфир. Обожаю тбилисское сообщество, искренне рекомендую, если ещё вечер воскресенья ничем не заполнен в календаре.

ПыСы. Будьте внимательнее с таймзоной ;)

https://news.1rj.ru/str/tbilisi_js/567

Дизайнтюа и Фронтендюэль. Про вариативные шрифты

В подкасте «Веб-стандарты» в 503 выпуске мы обсуждали вариативные шрифты, их состояние в 2025 году, возможности для внедрения в вебе. Я в том числе спорил с мнением автора статьи, где он говорит, что вариативные шрифты можно внедрять чуть ли не везде в виде универсального инструмента от всех проблем.

Мне написал наш слушатель и поделился ссылкой на свой блог, где в 21 посте тема разбирается куда более качественно, чем мы в подкасте наговорили, на мой субъективный взгляд. Неистово рекомендую к прочтению.

https://news.1rj.ru/str/designtua_frontenduel/73

!important и кастомные свойства в CSS

Сегодня я узнал, что когда вы пишете --color: orange !important; в CSS, то это не указание строки, которая потом распарсится как цвет, причём очень важный.

Крис Койер в статье поясняет, что на самом деле !important — это указание каскаду отработать на свойстве, пусть и кастомном. Парсер отделяет импортант от строки. Причём логично ведь, у нас же не CSS Custom String, а CSS Custom Property, значит и каскад со специфичностью они ломать не должны. Но что-то я сначала не понял, а потом как понял!

https://frontendmasters.com/blog/important-and-css-custom-properties/

Проектирование сложных UI

Виталий Фридман поделился материалами курса про проектирование по-настоящему сложных UI. Когда вам нужно собрать полноценное приложение с множеством контролов, панелек, сценариев, а не просто сайт.

Внутри запись мастер-класса, слайды и огромное количество материалов по теме. Если не знаете, чем занять себя до конца новогодних, можно знатно закопаться — и время пролетит незаметно.

https://smashed.by/maven26

Нет robots.txt — нет сайта в выдаче Google

Внезапное. Алан Смит делится интересным кейсом. В какой-то момент органический трафик из Google на сайт ушёл в 0. И причина, скорее всего, в том, что у сайта нет robots.txt — файла в корне сайта, который должен давать инструкции роботам, куда можно ходить, а куда нельзя ходить.

Дальнейший ресёрч показал, что вообще-то в поддержке есть целое видео про этот нюанс.

Честно говоря, я с таким никогда не сталкивался, потому что у меня для каждого личного проекта robots.txt на автомате копируется из предыдущего. Но удивительно, что если гуглобот не получил явное разрешение погулять по сайту, то он не наглеет и действительно не идёт гулять. Логично. Но удивительно.

https://www.alanwsmith.com/en/37/wa/jz/s1/

Оптимизация SVG. Гайд для новичков

Постоянно вижу на разных сайтах SVG, которые очень сильно не оптимизированы. Не считаем PNG в base64 внутри SVG, это совсем уж вопиющее, речь скорее про лишние группы, ненужные атрибуты и координаты с точностью до 10 знаков.

Лаура Калбаг делится инструкцией, с чего стоит начать, чтобы SVG на выходе были поменьше размером, не теряя в качестве.

https://penpot.app/blog/how-to-optimize-noscript-files-a-complete-guide-for-beginners/

Почему я всё ещё использую jQuery

Андрей Мелихов поделился в редакторском чатике ссылкой на статью «Why I Still Use jQuery», которая мне откликнулась. Мнение автора можете почитать по ссылке, а я хочу поделиться своими размышлениями.

С недавним мажорным обновлением jQuery 4.0 в блогах и твиттерах видел много бурлений на тему: «А зачем оно вообще надо? Кто-то до сих применяет jQuery?»

Для начала: да, кто-то применяет. Я редко, но применяю jQuery, и мне не стыдно. Даже горжусь этим иногда.

1. Если вы думаете, что во всём мире у всех пользователей современные компы с современными ОС и браузерами, то это заблуждение. Как бы мы не хоронили Internet Explorer, во многих государственных учреждениях до сих пор стоят закупленные в райне 2005 компы с Windows XP, где IE нужен как минимум чтобы запустить закупленные в те же годы Silverlight-приложения. Да, доля для какого-нибудь маркетплейса ничтожная, но для разработчиков приложений под такую ЦА Internet Explorer, к сожалению, никуда не делся. Кстати, этим разработчикам jQuery 4.0 уже не пригодится, в нём отказались от поддержки IE.

2. Wordpress. Когда-то он породил огромное количество сайтов, где jQuery торчит из базовых тем, плагинов и так далее. Современные веб-студии давно перешли на более современный стек, плагины тоже. Но я где-то раз в полгода помогаю знакомым слегка править сайты на WP — и там всегда есть jQuery в моём случае.

3. Если есть адепты секты React / Tailwind / подставь_своё, то почему не может быть адептов секты jQuery? Некоторые разработчики используют React просто потому, что больше ничего не освоили, при этом быстро собирают сайты, выдают по проекту в день, решают задачи бизнеса и хорошо зарабатывают. Так почему не могут себе такое же позволить jQuery-разработчики? Когда код на jQuery на кончиках пальцев, причём LLM с ним тоже замечательно дружит, а пользователь при этом не страдает — ну и хорошо же.

4. Экосистема обширнейшая. Плагины есть почти на любой чих. Если стоит задача сделать быстро, то можно собрать целый комбайн из плагинов, где почти всё нужное есть.

5. DX для простых сайтов типа лендингов лучше, чем у нативных методов. В статье есть хороший пример про AJAX. Код на нём для меня лично более читаемый, чем пачки хуков и провайдеров.

Это не значит, что я призываю всех выбросить React, Vue.js или на чём вы там пишете. Даже наоборот, если ваш рабочий процесс отлажен на удобном вам инструменте и это не портит UX, то нет смысла в 2026 году осваивать и внедрять jQuery. Но это всё ещё инструмент, который в некоторых местах нужен и полезен. Хейтить ручную пилу, что она не достаточно электропила — сомнительно.

Всем добра :)

https://www.docker.com/blog/why-i-still-use-jquery-2025/

CSS Stats

Нашёл в интернетах интересный анализатор CSS на любых сайтах. Умеет считать и сравнивать специфичность селекторов, показывать цветовую палитру, тени, рамки, CSS-переменные, раскладки гридами. Даже пробует подсказать, есть ли смысл переходить на Atomic-классы.

Честно говоря, чтобы найти какие-нибудь аномалии на сайте — инструмент отличный. Дробные размеры, внезапные переменные, незапланированные шрифты. Или подсмотреть у конкурентов, что у них там в вёрстке неидеального есть, потешить своё ЧСВ, например. Или даже сравнить две версии сайтов между собой, есть и такая функциональность. Поймал себя на том, что последние три дня сижу и анализирую разные сайты (через расширение браузера) — зачем-то оно мне надо, хотя толком сформулировать себе, зачем именно, пока не могу.

В общем, в закладки сохранил, с вами тоже делюсь.

https://cssstats.com/

Returns Undefined

Забава вам на вечер. Игра, которая проверяет ваши знания приведения типов в JavaScript. И не только. В пиксельной графике.

Местами есть абсолютно издевательские вопросы, но тем и веселее.

Кстати, проект написан на Svelte, лежит в опенсорсе.

https://ylovits.github.io/returns-undefined/

Переезд с Chalk на нативный styleText

Есть такая утилита Chalk, которую даже если вы осознанно в проект на Node.js не подключали, есть высокая вероятность, что подключали неосознанно. У неё какое-то неприличное девятизначное число скачиваний в неделю. И нужна она, чтобы в терминале красиво выводить текст: с фоновым цветом, разноцветно, жирненько или курсивом и так далее.

В Node.js v22.13.0 стабильной стала нативная утилита node:util.styleText, которая может почти всё то же самое, но с некоторыми ограничениями. Для нас, разработчиков, это приятное удаление лишней зависимости и более быстрое логирование.

А самое приятное, что можно запустить официальный кодмод от команды Node.js, который мигрирует ваш проект сам:

npx codemod @nodejs/chalk-to-util-styletext

https://nodejs.org/en/blog/migrations/chalk-to-styletext

CTF Frontend // 2026

Каждый год мы небольшой командой перед конференцией «Я 💛 Фронтенд» собираем фронтендерский CTF (Capture the Flag). Он уже оброс собственным лором, узнаваемой стилистикой, локальными мемами и небольшим, но уютным комьюнити. Игры больше похоже на головоломки, где знания фронтенда помогают найти спрятанные сообщения, чтобы перейти на следующий уровень.

В этом году тоже готовим новую игру с новыми заданиями. Сижу как раз оформляю сюжетные диалоги, чтобы вам интереснее играть было.

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

В эту субботу. Ждём всех. Never Gonna Give You Up.

https://ctf.ilovefrontend.ru/

Долой появление по скроллу!

Дэвид Бушелл довольно аргументированно доказывает, почему делать scroll-fade на сайте не нужно. Это такой эффект, когда вы скроллите — и только после этого текст и картинки как-то появляются на странице.

Если кто-то попросит вас сверстать такой эффект, поделитесь с ними этой статьёй, там наглядно.

https://dbushell.com/2026/01/09/death-to-scroll-fade/

Эффект эластичного текста на чистом CSS

Для начала, это эффектно и красиво.

Темани Афиф собирает демку, в которой за текст можно потянуть курсором мышки — и он потянется в правильном направлении, а потом пружинкой отскочит обратно. Выглядит «вау», если знать, что там нет JavaScript. В статье есть пошаговый разбор, как достигнуть такого эффекта.

Автор сразу предупреждает, что с точки зрения доступности такой текст имеет неприятные нюансы на разных скринридерах. Их, при желании, можно обойти, но за предупреждение спасибо.

https://frontendmasters.com/blog/how-to-create-a-css-only-elastic-text-effect/