CSS Named Pages

Тут Firefox собирается выкатить крайне интересную мне фичу: возможность задавать именованные типы страниц в печатных стилях.

Один из первых моих докладов был про печатные стили. Ещё в университете задумался о том, что при помощи CSS можно вполне себе собрать небольшой фреймворк, чтобы оформлять дипломы и курсовые на связке Markdown + CSS. Ведь по сути в ГОСТ-ах прописаны правила оформления, которые вполне однозначно соотносятся с какими-то стилями. Но уже тогда понял, что многие описанные в спецификации вещи банально не реализованы в браузерах, да и с 2009 года на тот момент почти никаких подвижек не было.

И тут внезапно выясняется, что одна из интересных фичей всё-таки появилась в Chrome 85 и может появиться в ближайших релизах Firefox.

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

Вот как это будет выглядеть в CSS.

@page envelope { size: letter landscape; }
@page list { size: A4 portrait; }
.envelope {
page: envelope;
margin: 2in 3.5in;
}
.list { page: list; }

Браузер, когда наткнётся на новый тип страницы, который должен быть применён к элементу, сделает разрыв контента (page-break) и постарается уместить контент в новом размере при генерации печатной версии. После — снова разрыв страницы, за которым другой размер, если надо.

Того и гляди, нужно будет обновлять свой доклад, когда «новые» фичи доедут-таки до основных браузеров.

https://groups.google.com/a/mozilla.org/g/dev-platform/c/bazhFYQH6C8/m/cGi6AvR4AAAJ

Поддержка MathML Core

В Chrome 109 добавили поддержку MathML Core — подмножества MathML, которое позволяет рендерить большую часть математических формул на веб-страницах без подключения библиотек. И это очень крутая новость!

MathML — сама по себе крайне интересная спецификация со сложной историей. Появилась она ещё на заре веба, но браузеры столкнулись со сложностями имплементировать некоторые её части. Тем не менее, Firefox аж с 4 версии поддерживает MathML, а Safari — с 10. Chrome включал поддержку в 24 версии браузера, но тут же выключил.

Моя команда разрабатывает хендбуки, в которых важно уметь рендерить формулы. Например, для учебников по ML это просто жизненно необходимо. И когда мы думали про то, как сделать формулы доступными, быстрыми и не тормозящими страницы, очень сильно не хватало того самого MathML. Но на момент запуска проекта поддержки в Chrome не было, поэтому взяли самую популярную на текущий момент библиотеку MathJax. В ней ещё из коробки можно серверный рендеринг формул подключить при необходимости.

Но теперь, кажется, можно будет эту библиотеку оставить только как фолбэк для старых браузеров. MathML Core просто работает из коробки, не требует JS, а разработчики из Igalia в том числе следят, чтобы реализация в браузере была доступной. К слову, как я понял, именно Igalia драйвит эту движуху по затаскиванию движка в Chromium.

Для разработчиков это значит, что если вам нужно рисовать формулы, то не нужно больше делать это картинками. Есть конвертеры из LaTeX в MathML, можно выучить синтаксис MathML, видел даже онлайн-редакторы. На сервере любой синтаксис преобразуете в MathML, на клиенте проверяете поддержку (тут, к сожалению, придётся поизвращаться со вставкой фррмулы на страницу и замером её размеров), и только если поддержки нет, то динамически подгружать MathJax поверх. И сервер разгружается, и клиент не страдает.

Но помните, что в Chrome завезли не весь MathML, а только MathML Core. Про отличия можно почитать здесь: https://w3c.github.io/mathml-core/docs/explainer.html

TypeScript 5.0 Beta

Крайне интересный релиз. Буквально позавчера вышел анонс беты TypeScript 5.0, который уже сейчас можно попробовать через npm install typenoscript@beta.

Важные для меня новинки:

- Декораторы. Не те экспериментальные, которые с нами чуть ли не со старта TS, а настоящие ECMAScript-декораторы. Теперь можно поиграться в мета-программирование, которое к тому же не будет ни во что транспилироваться, если target транспиляции уже умеет в эти самые декораторы. А самое главное, декораторы сразу умеют в типизацию, без чего странно было бы запускать такую вещь в релиз.

- В tsconfig теперь можно внутри extends писать массив. То есть не нужно больше изгаляться с хитрыми наследованиями конфигов, а достаточно собрать парочку для разных ситуаций и просто примиксовывать их к базовым. Например, для локального конфига мне обычно нужно заменить буквально пару настроек, но в проекте в разных папках лежат разные конфиги (для тестов, для кода, для тулзов). Можно собрать набор локальных настроек и добавлять его к основным, DRY.

- Все enum теперь union enum (не знаю, как корректно перевести). Это значит, что можно творить вот такое:

const BaseValue = 10;
const prefix = 'data';
enum Values {
First = BaseValue, // 10
Second, // 11
Third = ${prefix}/path, // 'data/path'
}
type FirstValue = Values.First;

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

- Опция --verbatimModuleSyntax включает режим, когда при импорте типа из файла (`import type { Some} from 'some';`) просто дропает содержимое модуля (используется только для проверки типов), а во всех остальных случаях оставляет его в бандле. Хочу ещё разобраться, как это влияет на то, превращается код в require или в export, в описании фичи много про это, но нужно пробовать на практике.

- В режиме --build теперь можно передавать флаги --declaration, --emitDeclarationOnly, --declarationMap, --soureMap, --inlineSourceMap. Так будет можно удобнее настраивать tsc под различные сборки: локальную, тестовую, продакшен.

- TS сам по себе стал легче на 26.5 МБ. И это здорово как для сохранения места на диске, так и для передачи всякого по сети при установке пакета. В релизе пишут, что такая оптимизация в принципе привела к заметному ускорению работы TS.

Описание релиза большое. Почитайте обязательно. Я пересказал вкратце только самое интересное мне, но там есть и breaking changes, на которые точно нужно будет обратить внимание при обновлении.

https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-0-beta/

Тест на «Банан»

Подсмотрел в одной из лекций Виталия Фридмана интересный тест на понятность интерфейса. Когда в следующий раз дизайнер принесёт вам макет какой-то страницы, где пользователь должен совершить действие, попросите его заменить все тексты на слово «Банан» или какой-нибудь бред вроде этого. А потом с этим «обананенным» макетом нужно сделать коридорное тестирование. И если даже так всем пользователям понятно, что обозначает каждый элемент интерфейса, то это хороший интерфейс. Значит, вы спокойно можете подключать другие языки на ваш сайт, и даже в случае ошибки перевода в тексте интерфейса пользователь всё равно сможет выполнить свою задачу.

Думаю, под такое можно даже Figma-плагин сделать, BananaTest какой-нибудь.

Конечно, нет смысла проводить такие тесты на информационных блогах. Но для какого-нибудь интернет-магазина это вполне хороший способ проверить, что кнопку «Купить» нажмут, даже если шрифты отвалятся.

Не прошло и суток, как Figma-плагин для «теста на Банан» появился.

https://github.com/jag-k/figma-plugin-bananatest — приходите помогать автору делать плагин лучше и тестировать его на реальных макетах.

Interop 2023

Дождались. В предыдущем выпуске подкаста «Веб-стандарты» мы строили предположения, за что же возьмутся браузеры в этом году, чтобы сделать реализации различных фичей предсказуемыми и соответствующими тестам веб-платформы. И вот анонсы появились одновременно среди большого количества браузерных компаний.

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

В CSS:
- Свойство border-image.
- Цветовые пространства и функции в CSS — по сути осталось дотянуть display-p3, lab, lch, oklab, oklch, xyz в Firefox и функцию color-mix().
- Container Queries.
- Containment в CSS — свойства contain и content-visibility.
- Псевдоклассы в CSS.
- Кастомные свойства.
- Флексбоксы.
- Шрифты.
- Гриды.
- Родительский селектор :has().
- Маскирование в CSS.
- Математические функции в CSS.
- Медиавыражения.
- Набор свойств offset для анимаций по кастомному пути: offset-path, offset-distance, offset-position и другие.

В HTML:
- Формы.
- Атрибут inert.

В браузерных API:
- Модули в веб-воркерах.
- Offscreen Canvas — канвас в отдельном воркере.
- Pointer и Mouse Events.
- Интерфейс URL.
- Веб-кодеки.
- Веб-компоненты.

Список большой, но по многим направлениям в браузерах уже успешно проходит большая часть тестов. Напоминаю, основная задача проекта Interop — убрать различия в браузерном поведении, чтобы нам, разработчикам, было проще и спокойнее использовать фичи без костылей и подпорок под особенности какого-нибудь конкретного случая в конкретном браузере.

Следить за прогрессом лучше всего прямо на сайте тестов веб-платформы: https://wpt.fyi/interop-2023

Анонсы от разработчиков браузеров:
- https://web.dev/interop-2023/
- https://blogs.windows.com/msedgedev/2023/02/01/microsoft-edge-and-interop-2023/
- https://www.igalia.com/news/2023/interop2023.html
- https://webkit.org/blog/13706/interop-2023/
- https://bocoup.com/blog/interop-2023
- https://hacks.mozilla.org/2023/02/announcing-interop-2023/

Leetcode и паттерны динамического программирования

Сергей Ufocoder с @xufostation разобрал основы динамического программирования для задач с рекурсией и на поиск кратчайших путей с ограничениями перемещений. Понятно и по шагам объяснил, как их применять.

В видео задачи решаются на Python, но не думаю, что это сильно усложнит понимание — Сергей каждую строчку объясняет словами.

Рекомендую всем, кто погружается в алгоритмы и покоряет Leetcode. И для прохождения собеседований полезно, и в работе может пригодиться. Задачки на поиск кратчайшего пути в том или ином виде мне в практике попадались.

https://youtu.be/q2v_mQcbCks

Эволюция доверия

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

Люблю такие понятные и интерактивные объяснения сложных вещей. Ещё и на веб-технологиях.

https://notdotteam.github.io/trust/

Ускоряем Cycle Time и растим счастье в команде

В прошлом году на тимлидской конференции читал доклад про то, как можно сделать команду более эффективной, не принося ей при этом плохое настроение. Сегодня появилась расшифровка доклада на хабре.

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

При этом старайтесь автоматизировать всё, до чего дотянутся руки. Если один вечер за разработкой автоматизации сэкономит вам много трудодней в будущем — оно того стоит.

И не забывайте следить за настроением в команде. Если команда счастлива, то с такой командой можно очень многое реализовать.

А больше деталей — в статье ;)

https://habr.com/ru/company/oleg-bunin/blog/715644/

Picture-in-Picture не только для <video>

В Chrome 111 под Origin Trial или за флагом chrome://flags/#document-picture-in-picture-api добавили очень крутое внедрение. Теперь можно делать отдельные плавающие окна для ваших веб-приложений, которые живут поверх всех вкладок. Уверен, вы видели такое раньше для видео, но теперь можно внутрь этих маленьких окошек помещать почти полноценное веб-приложение.

Особенности приложений внутри PiP:
- PiP-окно плавает поверх всех окон.
- PiP-окно закрывается сразу же вместе с окном, из которого оно было вызвано.
- Из PiP нельзя открывать другие окна.
- Внутри PiP не работает навигация (нельзя переходить по ссылкам).
- Из вызывающего окна нельзя управлять позицией PiP на экране.

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

Работать с таким окном несложно, в статье есть подробные примеры кода, как определить поддержку фичи, как открыть окно и установить его размер, как отслеживать события внутри окна, и так далее. Везде нужно работать с новым свойством window.documentPictureInPicture. Забавно выглядит свойство window.documentPictureInPicture.window, которое возвращает текущее PiP-окно.

Фича однозначно полезная. Когда появились первые PiP-видео, я всё ждал, что большие стриминговые сервисы их поддержат. Прошло несколько лет, но тем же Netflix важно оставаться внутри их собственного плеера, у которого есть как хорошая поддержка доступности, так и взаимодействие с пользователем. Теперь им технически проще будет поддержать PiP для своего контента.

Ну а пример с Pomodoro-таймером в статье пленил сердечко. У меня есть несколько приложений, которые разработчикам пришлось заворачивать в Electron исключительно ради вот этого окошка поверх других окон. Скоро от них можно будет отказаться — люблю всё делать через браузер.

https://developer.chrome.com/docs/web-platform/document-picture-in-picture/

User Activation API

В блоге WebKit есть статья, хорошо объясняющая, как работает пользовательская активация некоторых браузерных API. Делюсь вольным переводом.

Допустим, у вас есть такой код:

let audioCtx = new AudioContext();
await navigator.share({text: 'test'});
window.open('mefody.dev');


Если этот код просто вызвать сразу при загрузке страницы, то он упадёт с ошибками NotAllowedError. И это ожидаемое поведение — таким образом браузер защищает пользователя от назойливого поведения веб-страниц вроде попапов, внезапного звука, неожиданной оплаты через Apple Pay и так далее.

Чтобы он заработал, нужно обернуть код в addEventListener одного из следующих событий: keydown, mousedown, pointerdown (если pointerType равен mouse), pointerup (если pointerType не равен mouse), touchend. Таким образом браузер будет уверен, что всякое назойливое произошло уже после того, как пользователь начал взаимодействовать со страницей. То есть как будто он сам нажал кнопку «Воспроизвести» и ожидает подобное поведение страницы.

Но если вы напишете такой код:

button.addEventListener('click', async () => {
let audioCtx = new AudioContext();
await navigator.share({text: 'test'});
window.open('mefody.dev');
});

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

Для начала, пользовательская активация бывает временная (transient) и постоянная (sticky). Когда срабатывает обработчик пользовательской активации, в браузере запускается таймер, во время которого можно выполнять методы API, требующие этой самой активации. Это довольно короткий промежуток, буквально пара секунд. В нашем случае share съедает время этого таймера, на window.open нужно триггерить активацию снова. Это называется временной активацией.

Некоторые API не требуют срабатывания до истечения таймера. Им достаточно знания, что активация была когда-то на странице. Такая активация называется постоянной. Для работы с Web Audio, например, достаточно всего одного клика на странице. Объясняется это тем, что если бы пользователю приходилось кликать по странице на каждый чих внутри узлов работы с аудио, это был бы самый ужасный интерфейс.

Но допустим, что пользователь успеет пошарить что-то буквально за доли секунды, до истечения таймера. Сработает ли window.open? Всё равно нет. Тут вступает в дело другой механизм — потребление активации. Некоторые API, как только получает возможность выполниться, «потребляют» активацию, то есть сбрасывают таймер. Среди таких методов: requestPermission, show для Payment Request и тот самый share. Этот список может пополняться и зависеть от браузера.

Так как же проверять, что активация сработала и я могу вызывать свои методы? Для этого есть navigator.userActivation.isActive для проверки временной активации и navigator.userActivation.hasBeenActive для проверки постоянной активации.

https://webkit.org/blog/13862/the-user-activation-api/

Тимлид как dungeon-мастер

Вчера читал доклад про то, как перенести практики подготовки и проведения игр в D&D на управление командой. Без озвучки голосом презентация не слишком понятна, но попробуйте посмотреть на слайды с «Откровениями» с автозаменой: игра — проект, мастер — тимлид, игроки — команда разработки, и так далее.

Полгода назад с удивлением обнаружил, что приёмы, позволяющие в роли мастера делать игры в D&D интересными и запоминающимися, отлично перекладывается на работу тимлида. В итоге получился доклад, который как будто даёт советы мастерам подземелий, но на самом деле рассказывает про управление командами разработки.

Школы Академии Яндекса

С 15 марта открывается набор в школы разработки интерфейсов, мобильной разработки, бэкенда и менеджеров. Пару лет назад был в ШРИ преподавателем, а сейчас моя команда помогает делать эти школы лучше.

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

В общем, если вы ещё не синьор-помидор и хотите летом прокачаться — возможность есть.

Кстати, Андрей @melikhov_dev Мелихов будет в ШРИ читать лекцию по Node.js. Сам схожу вольнослушателем, пожалуй.

https://academy.yandex.ru/schools/summer

Firefox Public Data Report

У Firefox есть сайт, где они каждую неделю делятся данными о пользователях браузера. Они пишут, что анализируют обезличенные данные от 10% пользователей различных версий и собирают только те, которые не нарушают приватность.

А статистика, на самом деле, интересная.

1. Хоть многие и предрекают Firefox смерть на рынке браузеров, они всё ещё удерживают 200 миллионов активных пользователей в месяц, что не такое уж и маленькое число. К сожалению, оно снижается каждый год, но не так, как рисовало моё воображение.

2. В среднем пользователи Firefox сидят в браузере 5.3 часа в день.

3. «Вечнозелёность» Firefox вполне себе хорошая: обычно за месяц 70% пользователей переходят на самый свежий релиз.

4. Почти у 40% пользователей есть какое-либо браузерное расширение, причём в России — у 60% пользователей. Из них самые популярные — блокировщики рекламы, скачивалки видео, расширения социальных сетей. Что как бы намекает, что тестировать сайты в инкогнито глупо — правильнее создавать профили для тестирования с расширениями, чтобы видеть реальную картину.

5. Разрешение экрана 1920x1080 с каждым годом всё увереннее забирает долю у разрешения 1366x768. Десктопные мониторы становятся всё больше либо поддерживают более чёткую картинку. Тестировать сайты только на 1024x768 уже странно.

6. Пока что у пользователей преобладает 2 ядра CPU, хотя всё больше могут позволить себе 4 ядра и больше. Выносить тяжёлые вычисления в воркеры однозначно пора.

7. Доля macOS как операционной системы пользователей настолько низкая по сравнению с Windows, что если вы проверяете свои сайты только в ОС от Apple, вы точно живёте в каком-то мире фантазий и понятия не имеете, как на самом деле видят ваш сайт пользователи. При этом на последней тимлидской конференции в спикерской были только макбуки, что забавно.

8. После 2021 года доля пользователей с Flash резко упала, на сегодня всего 1.771% никак не могут обновиться.

Графики однозначно полезные. Как и Веб-альманах, такой отчёт показывает реальную картину мира, пусть пока только для десктопных браузеров. Конечно, правильнее всего опираться на статистику именно про ваших пользователей, но когда вы только начинаете разработку веб-приложения, такой статистики у вас банально ещё нет.

https://data.firefox.com/

Chrome extension that steals everything

Мэтт Фрисби показывает, как собрать на коленке браузерное расширение для Chrome, которое умеет:
- собирать все куки со страницы;
- получать всю браузерную историю пользователя;
- делать скриншоты страниц;
- отслеживать пользовательские переходы по любым урлам;
- доставать тела запросов;
- логировать нажатия клавиш;
- захватывать буфер обмена;
- загружаться в инкогнито;
- смотреть на геолокацию пользователя;
- подменять фоновые табы контентом из расширения;
- выдавать себя за приложение для локальных заметок.

Разумеется, браузер при установке расширения выдаёт попап, который показывает список API, в которые ломится зловред. Но, во-первых, слишком длинные списки просто спрятаны за скроллом, а во-вторых, далеко не все пользователи читают и понимают, что это за API такие, поэтому просто соглашаются на всё, лишь бы получить нужную им функциональность. Многие из вас читали лицензионное соглашение вашего браузера?

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

Мораль:
1. Проверьте, что умеют расширения, которые установлены у вас прямо сейчас. Действительно им нужны все эти доступы?
2. Не зря браузеры ведут работу над тем, чтобы ограничивать доступы расширениям.

https://mattfrisbie.substack.com/p/spy-chrome-extension

PWA для новичков

У Microsoft есть неплохой бесплатный видеокурс по тому, что такое PWA, как начать их разрабатывать, как они интегрированы в операционные системы и как их дебажить.

Диванная аналитика: когда большие корпорации создают подобные курсы, у них явно есть планы о поддержке технологии. Это значит, что за PWA сейчас как минимум два гиганта: Google и Microsoft. Для меня это сигнал, что вкладываться в изучение прогрессивных веб-приложений точно стоит, эти знания смогут мне помочь.

https://learn.microsoft.com/en-us/shows/pwa-for-beginners/

Дебаг свойств-асесcоров в JS

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

В случае автора статьи на странице каждые 10 секунд происходил скролл вверх. И он логично предположил, что нужно проверить, кто трогает scrollTop у document.documentElement. И если сначала Вячеслав играется с сеттером свойства, попутно разбираясь, что не каждое свойство получится так дебажить, то потом вспоминает крайне удобную функцию debug, которая работает в DevTools. Сам постоянно про неё забываю.

https://blog.griddynamics.com/debugging-accessor-properties-in-javanoscript-everything-you-should-know/

Хороший доклад. Рекомендую. Смотрел его ещё в Салехарде, много думал.

А вот и доклад про психологическое здоровье с Московского Teamlead conf.

Это один из немногоих докладов, который лично мне самому понравился. Обычно всегда всё не так, а тут прям мне самому зашло.

https://youtu.be/clZtSk2m05g

Скруглённые относительно друг друга углы

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

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

В статье можно подсмотреть формулы, которые можно добавить в вашу вёрстку, чтобы такие скругления автоматом подстраивались под особенности блоков.

https://set.studio/relative-rounded-corners/

Когда :focus-visible виден?

Ире Адеринокун простыми словами объясняет спецификацию псевдокласса :focus-visible. Браузер применяет стили для него, если:
1. Пользователь установил настройку «Всегда показывать фокус».
2. Сфокусированный элемент поддерживает работу с вводом с клавиатуры. То есть для инпутов с текстом применит стили, а для кнопок — не факт.
3. Пользователь переключается между фокусируемыми элементами при помощи устройства без указателя. Например, клавиатурой.
4. JS-скрипт переместил фокус с элемента, на котором стили применялись.

Просто и понятно. В статье есть демки, которые помогут понять на примерах.

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

/* Apply focus styles */
:focus-visible, :focus {
  outline: 1px solid red;
}

/* Remove the focus outline */
:focus:not(:focus-visible) {
  outline: none;
}

https://bitsofco.de/when-is-focus-visible-visible/