Изменения в HTML, CSS и API браузеров в 2022 году. Episode 122 от 19.11.2022

Ведущие:
🎙 @kalashnikovisme

Гости:
Никита Дубко

В этом выпуске обсудили вместе с Никитой Дубко обновления, которые произошли в стандартах HTML, CSS и API браузеров в 2022 году.

Yandex: http://it-way.pro/k46xz
Google: http://it-way.pro/wqdil
Apple: http://it-way.pro/egjyr
Spotify: http://it-way.pro/0y5rj
Youtube: http://it-way.pro/g2kag
RSS: http://bit.ly/2JuDkYY

Художник: @cathrinenotea

Участвую в конференции YaTalks.

Сначала пригласили просто гостем, но спикер внутри меня не смог удержаться, поэтому…

- Сегодня вечером сможете посмотреть, как плохо руководители решают алгоритмы на скорость.
- Завтра расскажу, какие спрятанные полезности есть в девтулзах Chrome.
- Будем с Женей Котом несмешно шутить в качестве ведущих фронтенд-трека.

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

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

ufostation.tech

Завершил веху работы над сайтом — перенес основные посты из телеграмм канала. Все исходники в открытом виде на github, материалы свободно распостраняются по CC BY-SA 4.0 (копируй/модифицируй).

Буду рад любой обратной связи, которая поможет улучшить ресурс: комментарии под этим постом, сообщения в личку, любой issue или pull requests на github.

Нравится контент? Поддержи меня на boosty 🙃

«Само по себе программирование не имеет никакого смысла»

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

И я с ним в этом месте максимально согласен. А ещё свои мысли материализовались.

Писать код ради кода кому-то интересно. Вот тебе принесли сложную задачу, ты её прилежно целую неделю реализовывал: придумывал непробиваемую архитектуру, подтягивал инфраструктуру под многократную нагрузку, верстал интерфейс pixel perfect по готовому дизайну, тщательно обложил тестами, довёл до релиза. И всем кажется, что ты молодец — смотрите, сколько работы проделано! Можно ещё на ревью попросить за эту задачу похвалить.

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

Вроде, оба разработчика принесли пользу. Оба потратили рабочую неделю в сумме. Но в случае неуспеха эксперимента второй разработчик мог сэкономить три дня. Да и сама фича оказалась пусть не такая идеальная, но на три дня раньше у пользователей.

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

https://podcast.ru/e/4kHx5miY-Zl

Chrome DevTools — спрятанные полезности

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

Так появился доклад, который я успел прочитать на FrontendConf и YaTalks в этом году. Вы тоже можете его посмотреть. Рассказал только про Chrome DevTools, потому что иначе это был бы уже мастер-класс на много часов. К слову, может сделать такой?

https://youtu.be/TiykIPnHvmI

Masonry-раскладка в браузерах

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

Интересно, что по сути полноценной реализации пока нигде нет: https://caniuse.com/?search=masonry. В Firefox есть реализация за флагом, но она там зависла ещё с 2020 года. Ставлю на то, что в следующем году нас ждёт ещё одна интересная фича, которая заработает во всех браузерах — WebKit выкатит это первым в каком-нибудь Technology Preview, за ним Firefox достанет из-под флага, а Chrome не сможет остаться в стороне.

О том, как это должно будет работать по спецификации, можно почитать в самой спецификации: https://drafts.csswg.org/css-grid-3/#masonry-layout

Newly interoperable

На web.dev появился тег, под которым можно найти статьи про фичи, которые работают сразу во всех основных движках: Chromium, WebKit, Firefox. Пока статей мало, но и тег всё-таки про фичи, которые недавно стали кроссбраузерными. Уже можно порадоваться за TransformStream, индивидуальные свойства трансформации в CSS, псевдо-селектор :modal, анимированные гриды и новые единицы измерения вьюпорта.

Мне нравится, что они добавили RSS-фид, на который можно подписаться. Я часто новости собираю при помощи Feedly, так что для меня ссылка точно удобная.

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

https://web.dev/tags/newly-interoperable/

«Вторжение. Краткая история русских хакеров»

Этот канал не только про фронтенд, напоминаю. Буду делиться впечатлениями о прочитанных книгах периодически.

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

У меня внутри книга что-то перевернула. Понятно, что это не научное исследование, а журналистская работа. Понятно, что хоть автор и старается не делать выводов там, где факты расплывчаты, но всё равно проталкивает некую повестку. Но по тексту расставлено много ссылок на материалы, которые можно попытаться проверить самому.

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

Рекомендую.

https://www.goodreads.com/ru/book/show/45719205

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 интересными и запоминающимися, отлично перекладывается на работу тимлида. В итоге получился доклад, который как будто даёт советы мастерам подземелий, но на самом деле рассказывает про управление командами разработки.