Элемент <p>

Согласно спеке <p> - это контейнер для фразового контента, который образует тематический блок текста из одного или нескольких предложений. К фразовому контенту относится текст, элементы семантики текста (<i>, <strong>, <cite>, тд.), аудио, видео, картинки, лейблы и контролы.

Несколько кейсов, где можно использовать <p>:

Кейс 1: классические абзацы.

Набор следующих друг за другом <p> с предложениями внутри. Могут идти вперемешку с <figure>, <blockquote>, <ul>, <ol>, <dl> и т.д. Тем самым формируется структура контента статьи, блогпоста, лонгрида.

Кейс 2: короткие тематические фразы.

Географический адрес, слоган, краткое описание в карточке товара, ошибка под полем ввода, цитата в <blockquote>. В общем заворачиваем в <p> какую-то фразу, может даже из одного слова.

Кейс 3: лейбл и поле

Можно использовать <p> для группировки лейбла и инпута, или любого другого контрола. Это разрешено спецификацией и абсолютно валидно. Сам так очень редко делаю, но встречаю иногда такой вариант использования.

Кейс 4: подзаголовок рядом с заголовком

В этом случае <p> содержит текст подзаголовка, а сам следует сразу после <h*> и вместе с ним располагается внутри <hgroup>, <header> или <div>. Опять же, текст подзаголовка может содержать одно слово.

***

Но вообще надо исходить из вопроса:

это сделает удобнее для пользователей?

Скринридеры не зачитывают <p> особым образом, для них это как <div> с текстом. Поисковые краулеры, вероятно, лучше распознают тексты, размеченные при помощи <p>. По умолчанию у <p> есть отступы. Если сломается CSS, страницу решат распечатать, посмотреть в режиме чтения, то <p> будет лучше отображаться и разрядит текст отступами. Если текст с <p> редактируется в WYSIWYG-редакторе, они лучше парсят и отображают контент с <p>. В остальном какой-то другой пользы или вреда от <p> и длины контента в нем для пользователя нет.

HTML: 25 фич, которые сделают ваш сайт удобнее

Выступил 20 апреля 2023 на MinskCSS! Для меня это первый внешний митап, до этого выступал только на внутренних ивентах компаний. И так вышло, что это был юбилейный, 10й митап 🎉. Огромная благодарность организаторам за это крутое мероприятие и возможность принять в нем участие! 🔥

Рассказал про фичи HTML, которые сделают интерфейсы удобнее и приятнее для пользователей. Из-за декларативной природы HTML все эти фичи можно без проблем внедрять в проекты и это не потребует много времени и усилий.

https://www.youtube.com/watch?v=-aeKCwJY6c8&t=64s

"Поделиться" в инстаграме

Кто, вот просто какой сверхразум из инстаграма додумался добавлять аккаунт, публикацию которого я хочу пошарить, на первую позицию в списке моих контактов? Зачем? Это список моих контактов, отсортированных по частоте взаимодействия. Какого хрена там появляется какой-то аккаунт? Я привык, что на первой позиции всегда находился контакт, с которым я больше всего взаимодействую. И машинально я выбираю первый контакт, если хочу ему пошарить публикацию. Вместо этого я шарю публикацию в тот аккаунт, из которого и хочу пошарить. ЗАЧЕМ? Хорошо хоть отмена есть.

Список для карточек

Речь о паттерне, когда создаётся список <ul> и в его элементы <li> вкладываются карточки. Небольшой тред о пользе списков для ассистивных технологий.

Семантика.

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

Количество.

Скринридеры также озвучивают общее количество элементов и позицию текущего элемента в списке. Это полезно и облегчает навигацию, когда элементов много. Также количество обновляется при добавлении и удалении элементов, что полезно для динамического контента.

Шорткаты.

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

***

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

В качестве альтернативы списку можно использовать <div role="group">, это тоже сообщает пользователю о группе каких-то элементов, но без информации о количестве и позиции, чтобы не спамить лишней информацией.

Коротко (не очень) о работе над доступностью

Это комбобокс. Да нет же, это поле с автокомплитом. Нет, тут просто фильтрация по листбоксу. Давайте добавим activedescendant? Но мы не можем добавить, нельзя по спеке

4 часа споров и обсуждений одного небольшого компонента. Ловлю себя на мысли, что такие вопросы часто возникают:

Это выпадающее меню? Или поповер с кнопками? Или поповер с листбоксом? Или селектбокс?

Столько крайне схожих, но отличающийся тонкостями UI-паттернов. Сюда же добавляется ещё и различная терминология: попап, поповер, дропдаун, тоглтип. Или вот ещё: модалка, диалог, алерт. Разница между ними зачастую в мелочах, или её вообще нет и никто не знает.

Со стандартными UI-элементами все относительно понятно, потому что есть примеры, APG и хорошие библиотеки. Проблемы начинаются в крупных приложениях, когда дизайнеры уходят в сторону от стандартных элементов и изобретают что-то специфическое исходя из требований бизнеса. В гайдлайнах таких кейсов нет, а на разных сайтах и в разных приложениях сделано по-своему. В итоге нужно придумать, как сделать это доступным, имея под рукой только спеку и примеры базовых паттернов. Это чертовски интересно, но иногда происходит подрыв мозга 🤯

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

Нативные поповеры!

В Chrome 114, который вышел в конце мая 2023, завезли Popover API. Firefox и Safari поддержали этот API и должны выкатить в ближайшее время. И это крутая новость!

<button popovertarget="note">
  Подробнее
</button>

<div id="note" popover>
  Всплывающая подсказка
</div>

Этот API позволит решать широкий набор задач по разработке UI-элементов без необходимости тянуть JS, декларативно, с возможностью стилизации и поддержкой доступности. Тултипы, поповеры, выпадающие списки, меню - все это со временем можно будет делать в браузере нативно. Подробнее об этом API можно почитать в предложении от Open UI, а я в вкратце расскажу суть.

Добавляется 3 новых HTML-атрибута:
1) Атрибут popover, popover="auto" или popover="manual" делает элемент поповером. Он вырывается из контекста документа, перемещается на верхний слой (top-layer) и скрывается (display: none)
2) Атрибут popovertarget="{id}" указывается у <button> и содержит id поповера. Тем самым создаётся элемент-триггер, который будет управлять поповером. При клике на элемент, поповер будет показываться или скрываться.
3) Атрибут popovertargetaction также указывается у <button>. Принимает значения show (при клике на триггер будет только показываться), hide (только скрываться) или toggle (переключаться, это значение по умолчанию).

В CSS добавляется псевдокласс :popover-open для стилизации открытого поповера. Можно, например, поиграться с позиционированием или сделать хвостик. У поповера есть псевдоэлемент ::backdrop, который можно стилизовать, например сделать затемненный фон.

В JS добавляется 3 метода для элементов с атрибутом popover: showPopover(), hidePopover() и togglePopover() для программного управления отображением. Добавляется новое событие beforetoggle, которое возникает перед появлением поповера. Можно, например, сделать fetch и подставить данные в поповер. Вместе с событием появляется и новый интерфейс события ToggleEvent, в котором будет состояние поповера.

С точки зрения доступности у кнопки с popovertarget подразумевается встроенный aria-expanded, но не aria-haspopup. Роль самого поповера сохраняется, нужно указывать вручную. Зато есть нативный focus-trap и закрытие по Esc.

Ложка дегтя. Пока не понятно, что там с отображением по hover. В обсуждении есть атрибут popoverhoveraction, но он не стандартизован, поэтому тултипы пока не сделать. Думаю, это вопрос времени. Также хотелось бы встроенные aria. Но начало хорошее, крутая апишка.

Коротко о бигтехах

Холдинг ByteDance Ltd, не может уже который год исправить баг, когда при переходе по ссылке на видео в ТикТок открывается вообще левое видео. И это в проде. Уже пару лет. У бигтеха с 60к сотрудников и 35млрд оборотом. Не баг а фича?

Вечные вопросы

<b> или <strong>? <em> или <i>?

Часто говорят, что нужно использовать <strong> и <em> соответственно, потому что они семантичные, а <b> с <i> - нет. Но на самом деле это не так. Вообще все элементы в HTML имеют семантику, которая определяется спецификацией и встроенной ролью (role). Семантика = смысл, то, что означает контент внутри элемента.

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

<strong> - фрагмент текста, который обозначает важность, срочность или серьезность. Так же выделяется полужирным, потому что так в типографике сложилось, но стили, опять же, можно переопределить. Например, это может быть разного рода предупреждающий текст: "Внимание!", "Вы уверены?", "Осторожно!", "Обращаем ваше внимание...". То есть это такой текст, на который пользователь должен обратить особое внимание и прочесть раньше, чем остальной текст.

<i> - фрагмент текста, который отличается от остального текста произношением, интонацией, настроением или как-то еще. То есть это такой текст, который в устной речи бы произносился иначе, чем обычно. Это термины, иностранные слова и фразы, идиомы, транслитерации, таксономии и т.д. Главный признак - в устной речи такой фрагмент текста бы произносился иначе, чем всё остальное.

<em> - это фрагмент текста, на который делается логическое ударение, или иначе это ещё называют эмфазой, от чего и название элемента (em - emphasis). Выделяется курсивом, потому что так принято в типографике. Это слова или фразы, которые произносятся с ударением, экспрессией, восклицанием для повышения эмоциональной выразительности. Часто в таких предложениях присутствует восклицательный знак или же фраза является цитатой (для которых есть свой элемент).

Зачем это? Во-первых это - соглашения типографики. Во-вторых в устной речи часть особого смысла в слова и фразы мы выкладываем за счёт голоса, интонации, скорости и т.д. В разметке у нас только текст, эти элементы задумывались, чтобы помечать то, что в речи мы делаем голосом. Эта информация предназначена в первую очередь для речевых синтезаторов. Если говорить о скринридерах, то пока все плохо: элементы никак дополнительно не озвучиваются почти нигде. Значит всё? Выкинули эти теги и больше не используем? Нет.

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

Поэтому размечайте тексты правильно.

Новое в CSS и UI

На мероприятии Google I/O показали, что нового появилось в CSS и UI за последнее время. На самом деле много всего интересного и кое что даже фундаментальное.

Новый элемент <selectmenu>

OpenUI разрабатывает новый элемент - <selectmenu>. Он уже более года доступен в Chrome за флагом. Этот элемент должен решить давнюю проблему - невозможность кастомизации нативного <select>.

<selectmenu>
  <button 
    slot="button"    
    behavior="button"
  >
    <span 
    behavior="selected-value"
    ></span>
  </button>
  <option>Option 1</option>
  <option>Option 2</option>
</selectmenu>

В чем проблема? Есть нативный <select>, который из коробки доступен, работает с формами и т.д. Но поповер с опциями никак не может быть стилизован, потому что находится на уровне ОС и недоступен для CSS. Да и внешняя часть имеет ограничения стилизации. Это приводит к тому, что вместо нативного <select> используются библиотеки, которые можно подогнать под дизайн и сделать консистентно во всех браузерах. Но это лишний js на клиенте, а во многих решениях доступность вообще не проработана. <selectmenu> - это решение. Это встроенный веб-компонент, который использует Shadow DOM для инкапсуляции разметки и логики внутри себя, slots для проброса произвольной разметки в определённые места и CSS Shadow Parts для стилизации некоторых внутренних частей.

У <selectmenu> есть определённая анатомия. Компонент состоит из кнопки, внутри которой элемент с текстом выбранной опции и иконка-треугольник. За кнопкой располагается поповер, куда попадают опции и который рисуется при открытии селекта. По умолчанию <selectmenu> работает как <select>, а именно служит контейнером для элементов <option>, которые могут быть опционально обернуты в <optgroup>.

<selectmenu>
  <option>Опция 1</option>
  <option>Опция 2</option>
  <optgroup label="Группа">
    <option>Опция 3</option>
    <option>Опция 4</option>
  </optgroup>
</selectmenu>

Благодаря механизму CSS Shadow Parts мы получаем возможность пробиться внутрь Shadow DOM и стилизовать некоторые части <selectmenu> при помощи специального селектора ::part(name), где name - название части: button, selected-value и listbox. Также доступны псевдоклассы :open и :closed для стилизации открытого и закрытого состояний <selectmenu> соответственно. Полезно для стилизации маркера.

selectmenu::part(button) {
  /* стили кнопки */
}

selectmenu::part(selected-value) {
  /* стили выбранного значения */
}

selectmenu::part(listbox) {
  /* стили выпадающего списка */
}

selectmenu:open {
  /* стили при открытом выпадающем списке */
}

selectmenu:closed {
  /* стили при закрытом выпадающем списке */
}

Можно передавать свою разметку, используя слоты. Доступные слоты: button, selected-value, marker и listbox. Браузер заменит стандартную разметку на ту, что была передана в слот. Атрибут behavior сообщает браузеру поведение, которое нужно добавить элементу. Внутри <option> также можно разместить дополнительную разметку, что позволяет добавить иконки, картинки, многострочный текст и все это стилизовать как нужно.

<selectmenu>
  <div slot="button">
    <noscript><!-- ... --></noscript>
    <button 
      behavior="button"
    ></button>
  </div>
  <option>
    <noscript><!-- ... --></noscript>
    <span>Опция 3</span>
  </option>
  <option>
    <noscript><!-- ... --></noscript>
    <span>Опция 4</span>
  </option>
</selectmenu>

В слот listbox можно передать разметку, которая будет использоваться как контейнер для опций. В таком случае нужно указать атрибуты behavior="listbox" и popover="auto" (да, тут используется Popover API). Можно сделать селектор цветов как в MS Word.

Когда эту фичу раскатят - не ясно. Поэтому к релизу синтаксис может немного измениться, но слоты и части останутся в таком виде, поскольку это часть стандарта веб-компонентов. Больше примеров и подробное описание можно найти в предложении OpenUI.

UPD: компонент переименовали в <selectlist>, чтобы не было путаницы с элементом <menu> и паттерном меню.

UPD2: компонент слегка переделали, заменив селектор ::part() на псевдоклассы, а также добавив новые вспомогательные элементы <listbox> и <selectedoption>. Работа активно идёт.

Возвращаясь к Popover API

Если сделать <div popover>, то он так и останется generic-элементом. Роль нужно добавлять вручную в зависимости от типа поповера (menu, dialog, tooltip, listbox, ...). Вот хорошая статья о том, когда и какая роль лучше подойдёт для поповера.

Про пользу семантической разметки

Представитель Google, Адам Аргайл, в ходе мероприятия Google I/O заявил, что семантическая разметка важна для нового AI Bard и привёл пример, в котором попросил AI собрать сводку последних постов со своего сайта. Адам отметил, что семантическая разметка помогает AI лучше понимать контент на сайтах. Теперь помимо ассистивных технологий, SEO, режимов чтения, специальных браузеров (браузер в Apple Watch, например) это ещё и для AI полезно. И это логично. Разметка - это текст. Языковые модели работают с текстом. Обученный AI знает про семантику, знает про спецификацию, поэтому может использовать эти знания для более качественного извлечения информации с сайтов.

https://youtu.be/JiVQBqAkkac?t=745s…

Хорошая статья про ошибки в формах

Андрей Ситник из Злых Марсиан написал статью о 11 популярных ошибках в формах на примере простой формы авторизации. О многих из них я рассказывал в своём докладе на MinskCSS про фичи HTML.

Продолжаю рассказывать про новые API

На очереди Anchor Positioning API. Это нативная возможность позиционировать один элемент относительно другого без костылей и js. API частично реализован и доступен в Chrome Canary за флагом экспериментальных фич.

<button id="hint">
  Подробнее
</button>
<div class="tooltip" anchor="info">
  Подробная информация
</div>

<style>
  .tooltip {
    top: anchor(--info bottom);
    left: anchor(--info center);
  }
</style>

Например, нужно сделать тултип, который привязан к какому-то элементу. Для этого нужна обертка с position: relative, внутри которой элемент с position: absolute, его нужно спозиционировать, и ещё js для переворачивания и прочих edge-кейсов. Либо использовать библиотеки Popper или Floating UI. Anchor Position API предлагает ряд новых возможностей в CSS и HTML, которые позволят решить эту задачу. Кроме того, при помощи этого API можно будет позиционировать выпадающие меню, списки опций селекта, автокомплит, всплывающие подсказки и другие UI-элементы.

Прежде всего, надо привязать один элемент к другому. Предлагается 2 способа. Первый - указать атрибут anchor, в котором будет id элемента, к которому нужно привязаться. Второй - указать CSS-свойство anchor-name со значением типа dash-indent (как custom properties).

<button id="hint" class="anchor">
  Подробнее
</button>
<div class="tooltip" anchor="info">
  Подробная информация
</div>

<!-- или -->
<style>
  .anchor {
    anchor-name: --hint;
  }
</style>

После создания якоря можно использовать CSS-функцию anchor(), с 3я аргументами:
- имя якоря
- сторона (top, right, bottom, left, center) или процент
- фоллбэк
Имя якоря можно не указывать, если он создан при помощи anchor в HTML или указано свойство anchor-default. Что делает функция anchor()? Она возвращает координату указанной стороны элемента-якоря, которую можно использовать как значение в свойствах top, right, bottom, left и inset, тем самым позиционируя один элемент относительно другого. Функцию также можно использовать внутри calc().

.anchor {
  anchor-name: --hint;
}

.tooltip {
  top: anchor(--hint bottom);
  left: anchor(--hint center);
}

Другая полезная функция - anchor-size(). Она принимает имя якоря и width/height. Таким образом, можно получить размеры элемента-якоря и использовать их для вычисления положения или размера привязанного к якорю элемента.

.anchor {
  anchor-name: --hint;
}

.tooltip {
  width: calc(4 * anchor-size(--info width));
}

Ещё планируется функционал автоматического позиционирования в зависимости от наличия свободного места. Для этого в свойствах top, right, bottom, left и в функции anchor() можно будет указывать значение auto. Переворачивание можно будет реализовать при помощи свойства position-fallback и специального @-правила с одноимённым названием. В try-блоках указываются варианты, которые браузер будет пробовать, чтобы подобрать наиболее подходящее позиционирование.

.anchor {
  anchor-name: --hint;
}

.tooltip {
  anchor-default: --hint;
  position-fallback: --flip;
}

@position-fallback {
  @try {
    bottom: anchor(top);
    left: anchor(center);
  }

  @try {
    top: anchor(bottom);
    left: anchor(center);
  }
}

Пока это экспериментальная возможность, синтаксис может измениться. Также есть баги и не все фичи на данный момент можно потрогать даже за флагами. Однако работа над API идёт, потому что это очень востребованная фича, которая тесно связана с Popover API и <selectlist>.

Интерфейс Chrome DevTools

Интересный факт, о котором, возможно, все знают, но тем не менее: интерфейс Chrome DevTools сделан на HTML, CSS и JS. На скриншоте слева DevTools, открытые на ютубе, а справа DevTools, открытые для DevTools слева. Можно увидеть разметку кастомного свойства панели Styles.

То есть все кнопки, вкладки, поля ввода, селекторы цветов, инспектор DOM и CSS, все панели и т.д. - сделаны на нативных веб-технологиях. И все это можно изучить, открыв DevTools для DevTools (хоть и не просто так). Для меня это стало небольшим открытием. В принципе бОльшая часть UI хрома сделана на нативных технологиях: стартовый экран, настройки, магазин расширений. Получается, что программа, которая отображает веб сама сделана на вебе. Что, на мой взгляд, довольно интересно. Также интересно взглянуть на некоторые технические решения, применяемые в DevTools, потому что это, по сути, веб-приложение с довольно нетривиальным функционалом.

Лучшее объяснение Web 3.0, которое я видел

https://briefs.video/videos/what-is-web-3.0/

Альт картинки:
Лучшие сокращения в CSS

1) min()

width: 100px;
min-width: 50px;

может быть записано как

width: min(100px, 50px);

2) clamp()

font-size: 16px;
max-font-size: 20px;
min-font-size: 12px;

может быть записано как

font-size: clamp(12px, 1rem, 20px);

3) repeat()

background-image: url('image.png');
background-repeat: repeat-x;

может быть записано как

background-image: repeat-x(url('image.png'));

4) calc()

width: 100%;
padding: 20px;

может быть записано как

width: calc(100% - 40px);

"Лучшие" сокращения в CSS ⬆️

Как же я обожаю подобную инфографику от разного рода индусов. "Лучшие сокращения CSS" - смотрите и запоминайте! 🤦‍♂️

В первом случае результаты не эквивалентны. В случае с width + min-width итоговая ширина будет 100px, а с min() итоговая ширина будет 50px, потому что min() возвращает наименьшее из двух значений.

Второй пример вообще шикарен: автор придумал сокращение через clamp() для несуществующих свойств min-font-size и max-font-size! Видимо, хотел показать fluid font size, только вот размер шрифта в примере всегда будет 1rem, для правильной работы нужны динамические единицы.

Третий пример должен был нам продемонстрировать применение функции repeat(). Только вот в примере функция repeat-x() в свойстве background-image, что не является валидный кодом. repeat-x() не существует, а функция repeat() предназначена для гридов, а не фона.

Ну и последний пример показывает нам, как вместо ширины элемента с padding использовать calc(), что не является эквивалентной заменой от слова совсем. Как минимум padding задаёт внутренние отступы, влияющие на размер элемента, в том числе и на его высоту.

Такой вот "полезный контент", как пишут некоторые люди с опытом разработки в комментариях к этой картинке. М-да уж...

Да они там кнопки красят!

Тем временем: сижу на созвоне, где 9 человек (дизайнеры, фронты, a11y-специалисты, аналитики) проектируют компонент выбора диапазона дат с календарём, инпутами, выбором месяца и года, пресетами, валидацией и тд. Лучше бы кнопки красил 😅

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

SPA на контентных сайтах

Не понимаю, зачем делать обычные сайты, документацию, блоги и другие content-first проекты на фреймворках в виде SPA с JS-роутингом? Чтобы работало без перезагрузки с анимациями? Так ведь нет, на средних и слабых устройствах фризы, а анимаций на большинстве проектов нет. Что вообще плохого в перезагрузке? Если грамотно использовать современные возможности нативного HTML и CSS, не подключать npm-пакеты на клиент по любому чиху, не подключать десяток трекеров и оптимизировать ресурсы, то перезагрузка будет почти мгновенной.

А красивые переходы скоро можно будет делать при помощи View Transition API (уже можно в Chrome). На контентные сайты люди приходят за контентом, в документацию за примерами кода и описанием API. Для этого не нужны фреймворки, JS-роутинг, рантайм вебпака и сотни кб JS-а.

Тред навеян несколькими твитами из ленты. В одном показано, что в документации Vue router и Pinia в Firefox не работал сайдбар с ссылками. Другой про миграцию сайта на Angular. Кроме того, я участвую в разработке нескольких сайтов на Angular и не вижу там необходимости в нем.

Нативная изоляция стилей в CSS

@scope (.card) {
  .noscript { /* ... */ }
  .image { /* ... */ }
  .link { /* ... */ }
}

В CSS всегда была проблема с изоляцией стилей, особенно на больших проектах. Её решают по-разному: префиксы, конвенции по именованию классов (БЭМ), CSS-modules, scoped styles (Vue) и т.д. Все это - попытки решить проблему. На самом деле решение есть - Shadow DOM, который обеспечивает изоляцию разметки и стилей в отдельном поддереве DOM. Причём Shadow DOM это не эксклюзивная возможность веб-компонентов. Её можно использовать и для обычных элементов. Однако в таком виде не прижилось. Нужен более простой механизм для создания областей видимости, который был бы доступен в CSS. Этим механизмом в скором времени станет директива @scope. Поддержка этой директивы будет добавлена в Chrome 117. Safari и Firefox идею поддержали и обсуждают детали реализации.

Директива @scope позволяет задать селектор элемента, который будет создавать область видимости. Внутри @scope можно указывать стили, которые будут применяться только в этой области видимости. В примере стили применятся только к тем img, которые находятся внутри .media-block:

<style>
  @scope (.media-block) {
    img { 
      border-radius: 50%;
    }
  }
</style>
<div class="media-block">
  <!-- стили применяются -->
  <img src="..." alt="...">
</div>

<!-- стили не применяются -->
<img src="..." alt="...">

Если @scope указан в HTML и при этом не указан селектор, то ближайший родитель элемента <style> будет использоваться как корень для создания области видимости:

<div> <!-- корень области видимости -->
  <style>
    @scope {
      p { 
        color: red;
      }
    }
  </style>
  <p>Красный</p>
</div>

<p>Не красный</p>

Опционально можно указать второй селектор после ключевого слова to. Это задаёт границу области видимости. Таким образом, можно задавать область видимости не на все дочерние узлы, а только на конкретную часть поддерева:

<style>
  @scope (.media-block) to (.content) {
    img { 
      border-radius: 50%;
    }
  }
</style>
<div class="media-block">
  <!-- стили применяются -->
  <img src="..." alt="...">
  <div class="content">
    <!-- стили не применяются -->
    <img src="..." alt="...">
  </div>
</div>

Специальный псевдоселектор :scope позволяет обращаться к корню области видимости и стилизовать сам корень или его дочерние элементы в зависимости от контекста:

<style>
  @scope (.media-block) {
    :scope { /* .media-block */ }
    :scope img { /* .media-block img */ }
    aside:scope { /* aside.media-block */ }
  }
</style>
<div class="media-block">
  <img src="..." alt="...">
</div>

Эта штука вполне может вытеснить БЭМ и различные библиотеки, когда появится полноценная поддержка. Ждём. А пока подробнее про @scope с примерами и нюансами можно почитать в черновике спецификации.

PS. Поддержка @scope была добавлена в Chrome 117 за флагом, а в 118 включили полную поддержку для всех. Также поддержку добавили в Safari TP 185