Когда overflow: hidden не работает

#CSS #Лаборатория_веб_платформы

Есть несколько причин, по которым дочерние боксы элементов, могут «вываливаться» из родительских.

Например, когда в дочернем боксе есть длинное неразрывое слово типа Тунгнафедльсйёкюдль, «вырывающееся» за пределы контейнера.

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

Также если дочернему боксу заданы отрицательное значение margin или элемент абсолютно спозиционирован так, что он выходит за пределы родителя.

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

Но overflow: hidden не всегда обрезает выходящее за пределы содержимое бокса. Есть исключение: абсолютно спозиционированный элемент не будет обрезаться родительским элементом с overflow: hidden, если родитель не является содержащим блоком (containing block), то есть ему не заданы position со значением absolute, relative или fixed.

Пример:

  <div class="overflow">
    <div class="absolute-child">LonglonglonglonglongAbsolute</div>
    <div class="static-child">LonglonglonglonglongStatic</div>
  </div>
</div>

  position: relative;
}

.overflow {
  overflow: hidden;
}

.absolute-child {
  position: absolute;
}

.static-child {
  position: static;
}

В примере бокс .absolute-child не обрезается по границам бокса .overflow, а при этом .static-child — обрезается, так как он имеет обычное позиционирование.

Пример в codepen

#webplatform

На сайте Веб-стандартов лучше легло 🙂

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

https://web-standards.ru/articles/web-platform/

Статистика использования фич на сайтах

#webplatform #Лаборатория_веб_платформы

Как узнать, как часто та или иная HTML-, CSS- или JS-фича используются на сайтах в интернете? Окей, на Can I Use можно узнать, как фичи поддерживаются браузерами. Но как узнать часто ли фичи используются разработчиками?

К примеру, нужно узнать про сайты:

- как часто в стилевых файлах используется Grid Layout или @import?
- много ли где в HTML встречается атрибут placeholder или required?
- насколько в JS-файлах распространён fetch или ResizeObserver?

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

Сервис статистики Chrome Stats

Каждый браузер Chrome собирает анонимную статистику. Разработчики Chrome добавляют в код браузера «счётчики» использования фич. Если пользоваль открывает в своём браузере сайт с определённой фичей, то «счётчик» увеличивается. В итоге получается такая статистика: сколько процентов страниц, загруженных через Chrome, было с интересующей фичей (фича встретилась в коде хотя бы один раз).

Посмотреть статистику можно тут. На 1 июня 2021 года:

- по Grid Layout — стили 9-10% всех загруженных пользователями страниц содержит гриды (источник);
- по @import — в CSS-коде почти 15% всех загруженных страниц используются директива @import (источник);
- атрибут placeholder встретился в HTML-коде 52% сайтов (источник);
- атрибут required появился на 9% сайтов (источник);
- fetch использовался на 38% сайтах (источник);
- ResizeObserver был замечен на 17% загруженных сайтов (источник).

В отдельном разделе живёт детальная статистика по использованию в коде CSS-свойств.

Самое клёвое, что есть не только текущая статистика, но и график её «адаптации» на сайтах со временем (период в несколько лет).

Статистика HTTP Archive

«Счётчики» в Chrome Stats анонимные, то есть не показывают конкретные адреса сайтов и абсолютное количество проанализированных страниц. А вот у HTTP Archive, где собирается и анализируется «архив сайтов», есть публичный датасет в сервисе BigQuery. Превью этих данных есть также на самой странице Chrome Stats.

К примеру, в таблице за 1 июня 2021 года сохранено 6435567 десктопных и 7452047 мобильных страниц. По этим страницам собрана информация:

- по тем же «счётчикам», что и в Chrome Stats, только с привязкой к конкретному сайту;
- лог работы движка V8 на странице;
- метрики Web Vitals;
- количество HTML-элементов и доступность страницы;
- картинки и другой медиа-контент на странице;
- использованные сторонние приложения и библиотеки (jQuery, React, Google Analytics…).

Чтобы отобразить эту информацию, нужно знать SQL. В прочем, в HTTP Archive есть и уже готовые отчёты о состоянии веба, которые просто открываются в браузере.

var(--) валидно?

#CSS #Лаборатория_веб_платформы

Представьте себе CSS-код:

  --: honeydew;
  background-color: var(--);
}

Как вы думаете, сработает ли такой код в браузерах, и валидно ли имя кастомного свойства --?

Ответ: да, в июне 2021 код работает в Chrome, Firefox и Safari. Но имя переменной -- формально невалидно.

Текущий черновик спеки о кастомных свойствах зарезервировал кастомное свойство -- для будущего использования в CSS.

Объясню идею авторов спеки.

В CSS есть наследование: значения некоторых свойств (например, color или font-size), а также кастомных свойств передаются от родителя к детям:

  color: rgb(51, 51, 51);
  --gap-size: 10px;
}

p {
  /* color тоже будет rgb(51, 51, 51) */
  padding: var(--gap-size); /* 10px */
}

Если эффект наследования нежелателен, его можно отменить ключевым словом initial:

  color: rgb(51, 51, 51);
  --gap-size: 10px;
}

p {
  color: initial; /* значение rgb(0, 0, 0) */
  --gap-size: initial; /* значение «пустое» */
}

Если же хочется отменить все наследуемые свойства, но при этом не хочется их все перечислять, есть свойство all, которое обращается сразу ко всем возможным CSS-свойствам сразу:

  color: rgb(51, 51, 51);
  font-size: 20px;
}

p {
  all: initial;
  /* 
  color: initial, то есть rgb(0, 0, 0)
  font-size: initial, то есть 16px
  */
}

У свойства all есть пара исключений: одно из них — оно не затрагивает кастомные свойства, для сброса их придётся перечислять все до единого:

  --prop-1: 123;
  --prop-2: red;
  --prop-3: 10px;
}

p {
  --prop-1: initial;
  --prop-2: initial;
  --prop-3: initial;
}

Так вот идея авторов спеки — сделать свойство с именем -- аналогом all только для кастомных свойств. Чтобы можно было написать:

  --prop-1: 123;
  --prop-2: red;
  --prop-3: 10px;
}

p {
  --: initial;
  /* 
  --prop-1: initial, то есть значение «пустое»
  --prop-2: initial, то есть значение «пустое»
  --prop-3: initial, то есть значение «пустое»
  */
}

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

А пока что не используйте var(--), если вдруг эта мысль вам приходила в голову, так как оно вероятно перестанет работать.

Баг уже починен в Firefox Nightly, а в Chrome багрепорт пока только заведён.

Декларативность и сотрудничество в HTML

#HTML #Лаборатория_веб_платформы

Есть некоторые клёвые API в HTML/CSS, которые прям доставляют. Чтоб решить задачу, вместо императивщины сообщаешь браузеру нужную инфу, а он делает всю остальную работу.

Хочу рассказать про srcset и sizes у <img>. Для чего они нужны? Прежде всего — подсказать браузеру, какую версию картинки начать загружать, когда только парсится HTML, и браузеру ещё ничего неизвестно о лейауте страницы. Браузер будет полагаться на подсказки, оставленные разработчиком, и исходя из них начинать сразу же загружать нужную картинку, не дожидаясь полного окончания парсинга страницы и применения стилей.

Частый кейс — указание обычной или ретиновой версии картинки. Браузер на этапе загрузки картинки ещё не знает какого она будет размера. Зато при загрузке картинки у браузера уже есть информация, что за экран у устройства: обычный или ретиновый. Поэтому разработчик подсказывает ему: вот эта картинка поменьше — для обычной плотности пикселей (1x), а вот эта картинка побольше — для большей (2x):

  src="picture1.jpg"
  srcset="picture1.jpg 1x,
          picture2.jpg 2x"
  alt=""
>

Браузер получает подсказку от разработчика, какая картинка для какого экрана подходит, и сам делает выбор: если экран ретиновый, грузит 2x-версию, а иначе — 1x.

Более сложная логика описания srcset нужна, если разработчик хочет предусмотреть, что на разных разрешениях экрана должны загружаться картинки разного размера.

При загрузке картинки у браузера уже есть информация, какой размер вьюпорта на устройстве. А у разработчика есть инфа, какая картинка какому размеру соответствует. То есть разработчик заранее подказывает браузеру: вот эта картинка шириной 100px, вот эта — 500px, а вот эта — 1000px.

  src="default.jpg"
  srcset="small.jpg 100w,
          medium.jpg 300w,
          large.jpg 1000w"
  alt=""
>

Браузер руководствуется подсказкой разработчика и делает выбор: ага, сейчас вьюпорт десктопный >1000px, поэтому беру large.jpg и загружаю. Если бы вьюпорт был поменьше, то была бы загружена соответствующая более мелкая версия картинки.

Но картинки не всегда показываются на всю ширину вьюпорта! Ок, браузер выбрал картинку large.jpg, так как вьюпорт был >1000px. А на самом деле картинка после загрузки стилей будет показана не на всю ширину вьюпорта, а вписана в блок шириной 300px. Об этом браузер не мог знать заранее, на этапе, когда он встретил при парсинге разметки тег <img>, и поэтому сделал неверное предположение и загрузил слишком большую картинку.

Поэтому браузеру нужна ещё и инфа, которую заранее знает разработчик: какую часть вьюпорта будет занимать картинка, когда страница полностью загрузится. Например, на мобильном разрешении картинка будет на весь экран, а на более широком разрешении три картинки выстроятся в ряд и будут занимать каждая 1/3 размера вьюпорта.

Эту инфу и сообщаем браузеру в атрибуте sizes: начиная с 1000px картинка будет занимать треть размера вьюпорта 33.3vw, а в остальных случаях — весь вьюпорт 100vw:

sizes="(min-width: 1000px) 33.3vw, 100vw"

Таким образом у браузера есть все вводные для принятия решения: размер вьюпорта и плотность экрана (браузер знает сам), собственные размеры картинок и их размер на экране (разработчик сообщил в srcset и sizes).

И дальше браузер сам принимает решение, какую картинку выбрать. А разработчику не нужно плясать с императивными конструкциями <picture>, что именно и когда именно браузеру показывать.

Вроде всё классно, если разобраться, как это работает. Только вот если не разобраться, то выходит не очень: у sizes по умолчанию значение 100vw. То есть если не указать sizes, а указать только srcset, то браузер будет думать, что картинки всегда на всю ширину вьюпорта, а это часто не так.

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

#Лаборатория_веб_платформы

Сборник примеров условных конструкций в CSS. «Встроенные умности» в синтаксисе для реализации типовых интерфейсных паттернов, которые CSS «додумывает сам» без необходимости добавления этой логики в JS.

Из побочных инсайтов: относительно Container Queries уже настолько привычно стало думать, что оно доедет до всех браузеров «когда-нибудь потом», что оказалось внезапно они уже легально есть и в Chrome, и в Safari, а в FF появятся в следующей версии. 🧙‍♂️

То же самое и про селектор :has, но в FF пока непонятно когда доедет до стабильной версии.

https://ishadeed.com/article/conditional-css/

#Лаборатория_веб_платформы

В JS есть Numeric Separators для более удобного визуального разделения цифр в числах. Разделитель — это символ нижнего подчёркивания _ (U+005F).

1_000_000_000             // миллиард
101_475_938.38            // сотни миллионов

const fee = 123_00;       // 12300
const fee = 12_300;       // тоже 12300

const amount = 12345_00;  // 1234500
const amount = 123_4500;  // тоже 1234500
const amount = 1_234_500; // тоже 1234500

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

const a = 00_; // SyntaxError: No identifiers allowed directly after numeric literal

const b = _00; // ReferenceError: Can't find variable: _00

#Лаборатория_веб_платформы

В Chrome начали пилить реализацию нативного скоупинга в CSS 🎉

Это чтобы можно было делать, например, вот так:

@scope (.dark-theme) { a { color: plum; } }

<div class="dark-theme">
  <a href="#">plum</a>
  <div class="light-theme">
    <a href="#">purple</a>
  </div>
</div>

На самом деле спека, как это обычно бывает в CSS, довольно много всего предусматривает «с запасом», а не только показанное в примере.

Фича важная для CSS-in-JS и подобных «инкапсулирующих» решений, поэтому если фичу реализуют в этом году в Chrome, вангую, что остальные вендоры тоже быстро подтянутся.

#Лаборатория_веб_платформы

Look Ma, это я в 2025 пишу фича-флаги прямо в CSS!

  /* обычные стили */
  /* ... */

  @container style(--wow-such-a-feature: true) {
    /* стили за фича-флагом */
    /* ... */
  }

  @container style(--wow-such-an-another-feature: true) {
    /* стили за фича-флагом */
    /* ... */
  }

реф

#Лаборатория_веб_платформы

В конце января – начале февраля 2023 будет проходить митинг TC39, на котором, среди прочего, stage 4 будет брать пропоузал с недеструктивными методами изменения массивов:

Array.prototype.toSorted(compareFn)
Array.prototype.toSpliced(start, deleteCount, ...items)
Array.prototype.with(index, value)

Суть методов toReversed, toSorted и toSpliced сходу понятна: это просто те же обычные reverse, sort и splice, которые возвращают новый массив вместо изменения старого:

> [1, 10, 3]

[3, 10, 1].toSorted()
> [1, 10, 3]

[3, 10, 1].toSpliced(1, 2, 5, 6)
> [3, 5, 6]

А вот метод with уже сходу не очень понятен. Он про точечную замену: меняет один элемент массива на указанном индексе на другой:

> [3, 10, 0]

Интересно ещё то, что эти методы уже доступны в бетке Chrome 110 без флага, то есть вероятно после встречи TC39, когда пропоузал выдет на stage 4, скоро выкатится и стабильный Chrome.

#Лаборатория_веб_платформы

В именованных CSS-цветах red — это алиас для #ff0000, а blue — это #0000ff.
Но green — это не #00ff00, что кажется логичным. На самом деле green — это #008800. А за цвет #00ff00 отвечает алиас lime.

реф

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/

#Пульс_веб_платформы

Фреймворки фремворками, а махина CSS медленно, но верно движется вперёд.

Вчера были опубликованы две новых версии черновиков CSS Box Alignment Module Level 3 и CSS Positioned Layout Module Level 3.

В Position 3 с прошлой публикации:

- уточнили концептуально, что такое static position и static position rectangle,
- а также явно прописали, что position: absolute вынуждает бокс получить independent formatting context (то есть если этот блок внутри грида и ему задали pos:abs, то субгрид внутри него выключится).

В Align 3 с прошлой публикации:

- добавлены технические правки, связанные с baseline и особенностями выравнивания по ней,
- также выравнивание при значениях space-around и space-evenly стало по умолчанию «безопасно» (то есть если такое выравнивание переполняет контейнер и приводит к обрезанию контента, то это выравнивание будет вести себя так, чтоб контент не обрезался, например, будет становиться как start),
- уточнено, что для замещаемых элементов (например, img) не будет работать внутреннее выравнивание, так как внутри таких элементов не могу содержаться другие элементы.

Также несколько дней назад был обновлён CSS Snapshot 2023, к котором в раздел «Modules with Rough Interoperability» внесли три новых спецификации:

1. CSS Conditional Rules Module Level 4
@-правила, например, @supports и @media — сейчас лучше всего поддерживаются в Firefox, в отстающих Safari.

2. CSS Cascading and Inheritance Level 5
Каскадные слои @layer — тут в лидерах по имплементации Chorome, а Firefox отстаёт.

3. CSS Scroll Snap Module Level 1
Пристыковка к скроллу — ситуация примерно одинаковая во всех браузерах.

И ещё на очереди публикация первых версий черновиков Web Animations Level 2 и CSS Animations Level 2.

UPD: Также в раздел «Safe to Release pre-CR Exceptions» был добавлен relative color syntax.

#Лаборатория_веб_платформы

Короч, FF 110 вышел, Container Queries доехали везде, теперь можно! 💫

  <div class="grid">
    <div>1</div>
    <div>2</div>
    <div>3</div>
  </div>
</div>

  container-type: size;
  width: 500px;
}

.grid {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
}

@container (max-width: 500px) {
  .grid {
    grid-template-columns: 1fr;
  }
}

#Лаборатория_веб_платформы

Как «прокачать» объект, чтобы он был итерируемым?

Использовать один из Well-known Symbols, а именно Symbol.iterator.

obj[Symbol.iterator] = function*() {
  for (const key of Object.keys(this)) {
    yield [key, this[key]];
  }
};

for (const [key, value] of obj) {
  console.log(`${key}: ${value}`);
}

Также есть вариант для асинхронного итерирования посредством Symbol.asyncIterator.

реф

#Пульс_веб_платформы

В черновик спеки CSS Backgrounds and Borders Module Level 4 смерджили изменение, делающее свойство box-shadow полноценным longhand-свойством!

Теперь управлять отдельными параметрами тени можно будет не повторным переопределением всего значения box-shadow, а задавая параметры shorthand-ами:

- box-shadow-color: <color>, initial: currentColor
- box-shadow-offset: none | <length>{2}, initial: none
- box-shadow-blur: <length [0,∞]>, initial: 0
- box-shadow-spread: <length>, initial: 0
- box-shadow-position: [ outset | inset ]

Аналогичные правки ожидаются и для «текстовой» тени text-shadow.

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

#Пульс_веб_платформы 03.11.2023

Новости
- вышел Yarn 4.0, интересного особо ничего нет, пофиксили баги, обновили ноду, причисали синтаксис
- обновилась Node v21.1.0, из интересного появился флаг --experimental-detect-module, по которому Нода сама распознает .js файлы как ES-модули, даже если для них не указан type в package.json
- все ишью для выпуска jquery 4.0.0 пофикшены (наверняка вы очень сильно ждали этого и вот, наконец, свершилось 🎉)

Проекты
- transformers.js — это самые известные модели ML в одном флаконе в виде JS, который работает даже прямо в браузере, теперь умеют ещё и конвертацию text to speech/audio

Статьи и демки

JS
- почему Next.js нехороший: после маркетинговой компании в поддержку Next 14, на волну запрыгивает Remix и в сравнении получается истина (Next не про платформу, несёт зависимости, нестабилен, слишком магический и комплексный)
- зато Remix больше не отдельная тула, а идёт в сторону становления плагином для Vite (и это хорошо)
- топ идея включать веб-компоненты в Markdown как валидный HTML на примере CRDT-компонента в блог-посте
- ещё один веб-компонент в виде мокового окна браузера для презентация
- Синдре Сорхус (тот самый) выпиливает из своих пакетов… 🥁 Node.js Buffer и меняет на Uint8Array, а также делится пошаговой инструкцией, если вам захочется сделать так же
- опрос State of React 2023 как обычно интересен не только будущими результатами, но и содержимым, где можно узнать названия новых хуков и реактовских API-шек
- неплохой свежеиспечённый туториал по Svelte в добавок к также недавно испечённому туториалу Next-а
- история разработки ECMAScript Decorators с самым внятным объяснением, что это такое (tldr, например, функции высшего порядка типа debounce или HOC-и типа withModal)

CSS
- новые CSS-функции rem() и mod() и где они обитают
- аналитика на CSS-коленке, беспощадная и неуязвимая
- prefers-reduced-transparency в копилку директив для тюнинга CSS-мелочей, которые почти никто не заметит
- съешь ещё этих мягких французских CSS-функций (light-dark, xywh, round, perspective) от Криса Койера
- визуальный гайд по селекторам от fffuel

HTML
- 0 из топ-100 самых больших мировых сайтов используют валидный HTML (и всем это ок)