mefody.dev

text-wrap: balance

Сначала Адам Аргайл написал статью, про то, как это работает. Потом Ахмад Шадид добавил полезных примеров.
В общем, прямо во время записи подкаста заслал в Shower пулл-реквест, чтобы в теме Ribbon тоже автоматом рисовались красивые заголовки.

text-wrap: balance — это способ попросить браузер рисовать текст внутри какого-то контейнера до 4 строчек сбалансированно. Например, если у вас на сайте есть длинные заголовки, в которых постоянно в последней строчке висячее слово остаётся, то браузер постарается сделать все строчки приблизительно одной длины, что по меркам типографики красиво и правильно.

Это свойство пока работает только в Chrome Canary за флагом, но как только оно начнёт работать в стабильном браузере, у вас просто станет красиво сразу. Поэтому есть смысл показать свойство дизайнерам уже сейчас, добавить его в правильных местах (см. статью Ахмада, очень хорошие примеры на мой субъективный взгляд) и уже выкатить в прод. Люблю CSS за то, что он не ломается, когда не знает какое-то свойство.

https://ishadeed.com/article/css-text-wrap-balance/
https://developer.chrome.com/blog/css-text-wrap-balance/

«Давайте созвонимся на пару минут»

Вчера читал доклад у Podlodka TeamLead Crew про то, нужны ли созвоны, как их проводить более эффективно и можно ли ставить все встречи впритык, чтобы потом после них пойти поработать.

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

https://www.youtube.com/watch?v=EEGM38yA9Wo

CodeRun

Только что наша большая команда запустила бету нового сервиса для решения алгоритмических и не только задач. Если кто-то знаком с https://contest.yandex.ru/, то вы знаете, что у нас уже много лет есть платформа для проведения олимпиад и контестов. Но хотелось сделать что-то, что будет доступно не только олимпиадникам, а вообще всем. Например, полноценные задачи на вёрстку, а не только на написание кода на JavaScript.

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

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

Например, адаптивности пока нет, доступность некоторых элементов не доделана, нет OpenGraph.

Всем заранее спасибо, кто откликнется. Мы очень старались сделать хорошо, но хотим ещё лучше!

https://coderun.yandex.ru/catalog

Публичное собеседование junior-разработчика

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

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

https://www.youtube.com/watch?v=9nBbRK-Gfjg

«Как лгать при помощи статистики»

Дарелл Хафф написал очень понятную и интересную книгу о том, как правильно реагировать на фразы «98% наших выпускников успешно устроились в жизни», «Это средство помогает 4 из 5 покупателей», «Исследование показывает, что на удалёнке эффективность сотрудников упала от 3% до 12%» и подобные им. Заметьте, я не пишу, что эти фразы — бред. В каждой нужно разобраться.

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

Если до этого вы очень много работали со статистикой и соц. исследованиями, то вряд ли найдёте для себя что-то новое. Остальным книгу крайне рекомендую.

https://alpinabook.ru/catalog/book-kak-lgat-pri-pomoshchi-statistiki/

Разбираемся с Style Queries

Юна Кравец рассказывает о ещё одной интересной возможности, которая пришла к нам вместе с Container Queries.

В самой спецификации CSS Containment Module Level 3 очень много текста уделено тому, как работать с размерами контейнера, и буквально 3 абзаца — про то, как опираться на почти любые свойства контейнера.

Представьте, что у вас есть компонент карточки товара, который вы берёте из дизайн-системы. И эти карточки должны уметь рисоваться по-разному, с темами. Для начала можно расставить много классов по всему HTML, чтобы явно задавать тему этим карточки. Можно ещё поставить тему на какой-то родительский блок, но тогда начинается борьба со специфичностью вида .theme_dark .card, которую к тому же довольно просто сломать неправильным подключением файлов со стилями. А можно завязаться на кастомные переменные, которые в некоторых проектах уже используют как API. По аналогии с переменными окружения в серверных приложениях.

Допустим, вы договорились, что для темизации вместо навешивания классов в нужных местах вы задаёте всего один класс на родителе, тот же .theme_dark, но внутри простой код:

.theme_dark {
   --theme: dark;
}

Теперь эта переменная доступна всем вложенным тегам. И было бы классно подсматривать её значение и каким-то образом изменять внешний вид карточки.

@container style(--theme: dark) {
  .card_bright {
    background: linear-gradient(-30deg, yellow, orange);
  }
}

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

Прелесть такого подхода, что выражения от стиля можно комбинировать точно так же, как медиавыражения, и при помощи бинарной логики сделать почти полноценный if внутри CSS (`else` пока не завезли, да он и не нужен, так как есть not и каскад). При этом на метрики Core Web Vitals новинка может повлиять положительно: раньше нужно было дождаться загрузки стилей, теперь тоже нужно дождаться загрузки стилей, но динамический HTML может стать приятно меньше, а стили при этом обычно кладут на CDN и настраивают для них кеширование.

Минусы подхода:
- Пока работает только в Chromium и только с кастомными свойствами. Но по спецификации должны будут в будущем поддерживаться и обычные свойства.
- Нужно переучиться использовать не классы, а кастомные переменные как API для связки CSS с HTML.
- Нужно явно задавать контейнеры, а это тоже требует перестроения мышления. А с большим количеством контейнеров на всём подряд можно и навредить производительности.

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

https://developer.chrome.com/blog/style-queries/

И вдогонку. Если уж вам ну очень надо знать версию браузера, вот статья, как подготовиться к урезанным User Agent.

https://developer.chrome.com/en/blog/user-agent-reduction-android-model-and-version/

Клиент подсказывает или клиент врёт?

Люблю читать про разное интересное, с чем приходится сталкиваться браузерам, чтобы не сломать интернет. Ингве Петтерсен рассказывает о том, почему заголовок User-Agent — то ещё зло для всех.

Когда-то, когда про кроссбраузерность говорили только грустным шёпотом, а разработчики вполне могли себе позволить гордо выставить плашку «W3C Validated», некоторые начали опираться на заголовок User-Agent, чтобы в зависимости от него выдавать разную вёрстку. Или, будем честны, отдавать экран, на котором требовать установить тот браузер, в котором разработчики смогли сверстать почти без багов.

Уже тогда возникла проблема вайтлистов и блоклистов. Допустим, вы точно знаете, что ваш сайт хорошо показывается в Firefox и плохо в Chrome (фантазируем). Есть три пути:
1. Починить и в Chrome.
2. Разрешать пользоваться только в Firefox.
3. Запрещать пользоваться в Chrome.

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

Допустим, команда сделала исследование браузеров на рынке, протестировала, закрепила где-то на уровне Apache этот самый вайтлист. И тут появлятся браузер Opera, который хочет честно подписать себя в User-Agent как Opera, но все сайты с вайтлистами просто в нём не работают. При этом инженеры Opera уверены, что у них самые современные реализации стандартов, сайты точно будут работать хорошо. Что они делают? Правильно, начинают подписываться как другие браузеры. И получаем что-то вроде Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36 OPR/97.0.4719.17.

Или вообще выходит браузер Arc, который под капотом Chromium. Разумеется, он тоже из коробки мимикрирует под Chrome. Просто чтобы работало.

В общем, идея изначально была хороша, но реалии разработки её извратили, поэтому опираться на User-Agent сейчас можно только если у вас есть все User-Agent всех браузеров мира — только так можно быть уверенным, что никого из пользователей не обидел зря, но и разработчиков не заставил реализовывать что-то, что они пока не умеют. (Надеюсь, сарказм распарсили.)

И собрались популярные браузеры, и придумали новую группу заголовков, и назвали их Client Hints. И стали передавать туда информацию только ту, что посчитали важным: мажорную версию движка, операционную систему, а вообще — то, что сервер спросит явно. Зачем гонять лишние байты, если у сервера в принципе нет обработки нюансов вроде разрядности процессора и типа устройства?

Вот только даже с таким решением случаются казусы. Написал разработчик регулярку v=\d{2}, а тут браузеры внезапно стали версии 100+ выпускать. И всё, теперь страница не показывается у тех, кто сидит на Intel Pentium 2 c Windows 98, и у большей части аудитории с самым последним Chrome на почти любой ОС. Казус.

Автор статьи как раз вспоминает про бесконечную версию Opera 9.9. Всё уже было в Симпсонах.

Мораль:
- User-Agent всё. Если вы на него опираетесь, то делаете пустую работу и рискуете сломать сайт нечаянно.
- Client Hints нужно уметь принимать. Придётся повозиться с сервером, чтобы запрашивать какие-то очень нужные вам детали о клиенте.
- Пишите регулярки внимательнее — версии браузера могут дойти до 1000 когда-нибудь (а что, ежедневные релизы от ChatGPT), а могут и вообще придумать альтернативу SemVer.
- Проверяйте фичи не по названию и версии браузера, а через прогрессивное улучшение на клиенте или те самые Client Hints. Всё равно браузеры врут, особенно новые, которых разработчики так и норовят оставить без рабочих сайтов, хоть они под капотом Chromium.

https://vivaldi.com/blog/technology/client-hints-or-client-lies/
https://github.com/WICG/ua-client-hints

Когда :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/

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

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

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

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

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

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

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

https://youtu.be/clZtSk2m05g

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

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

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

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

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

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

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

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

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

Chrome extension that steals everything

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

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

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

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

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

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/

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

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

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

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

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

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

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

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

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

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/

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/