«Я💛Ф» CTF 2024

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

Если считаете, что разбираетесь во фронтенд-технологиях, заходите сегодня после 20:07 по минскому времени, чтобы поучаствовать в гонке за призами.

https://ctf-2024.ilovefrontend.ru/

Service Worker Static Routing API

В Chrome 123 из-под флага выехало классное улучшение для сервис-воркеров.

Представьте, что у вас есть сервис-воркер на сайте. Даже если вы настроили его при помощи Workbox (популярный пакет для автоматизации большого числа типовых кейсов, связанных с SW), то всё равно этот сервис-воркер под капотом обрабатывает вообще любой запрос.

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

Так вот, в Chrome 123 добавили возможность задать специальный конфиг, в котором вы можете попросить браузер за какими-то ресурсами ходить только через сеть, за какими-то — через кэш, и так далее.

addEventListener('install', (event) => {
  event.addRoutes({
    condition: {
          urlPattern: "/form/*",
          requestMethod: "post"
    },
    source: "network"
  });
});

Тут в коде явно прописывается, что все POST-запросы по маске /form/* должны идти мимо сервис-воркера. Не тратим время на бесполезную обработку, идём сразу в сеть.

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

https://developer.chrome.com/blog/service-worker-static-routing

Железобетонные автогриды

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

Нильс Байндер по шагам собирает как раз такой CSS-компонент. Причём каждый шаг подробно объясняет. Полезно для тех, кто хочет разобраться в том, как работают auto-fit, функции max, min и minmax в контексте гридов и как создавать CSS-компоненты, которые всю магию держат внутри, а наружу отдают API в виде CSS-переменных.

https://9elements.com/blog/building-a-rock-solid-auto-grid/

«По-настоящему красивые переходы средствами браузера»

Читал на Dump Spb доклад про то, как уже сейчас можно потихоньку внедрять View Transitions API и Scroll-driven Animations в ваши проекты для вау-эффектов. Показывал на демках, ссылался на статьи. Видео доклада опубликовали, теперь можно посмотреть.

Простите за звук, я никак не мог повлиять на его качество.

Видео: https://youtu.be/Dud0DozVwvo
Слайды: https://mefody.github.io/talks/pretty-transitions/

Компонент для отображения активности

Думаю, вы не раз видели компонент, который показывает активность в каком-нибудь сервисе. Самый популярный пример — активность коммитов в GitHub. Эдакая сетка с разноцветными квадратиками. Чем насыщеннее квадратик — тем больше в этот день было активности.

Марио Хаманн делится опытом, как он собирал клиентский веб-компонент <activity-graph>, адаптировал его под SSR, упаковывал в WASM. Интересный пример того, как прогрессивно улучшая что-то существующее прийти к решению, которое можно переиспользовать на клиенте, на сервере и даже в других технологиях (в статье пример с PHP).

Все наработки доступны на GitHub и в npm, так что можно брать и подключать к себе в проект, если вам нужен такой компонент.

https://mariohamann.com/activity-graph-component

Как я могу помочь CSS развиваться

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

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

А что с придумыванием этих фичей? Есть комитет w3c, рабочие группы в нём: там некоторые занимаются фичами на зарплате, а кто-то — на энтузиазме. И вот среди энтузиастов есть люди и компании, которые очень сильно влияют на стандарты как качественно, так и количественно.

Мириам Сюзанн — как раз такой человек. @scope, @layer, CSS Anchor Positioning, popover — все эти довольно революционные для CSS спецификации так или иначе дошли до браузеров благодаря OddBird — компании Мириам. Они ещё делают SCSS.

Никого ни к чему не призываю, но так как я сам спецификации писать не умею, а в браузере их реализовывать и подавно, то помогаю как могу. Буду донатить OddBird, которым сейчас нужны деньги на дальнейшую работу. Когда-то веб-разработчики всем миром собрали на атрибут inert. Я хочу таким образом двигать CSS вперёд.

Хотите так же помогать развитию CSS — https://opencollective.com/oddbird-open-source.

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

Ну а если ваш путь — тот самый open source, который вы хотите делать своими руками, то вот вам видео выходного дня: Андрей Ситник ещё в 2019 году поделился опытом, как продвигать open source.

https://youtu.be/-CLm8bwwL_M

Полезные стили для кнопок

Дэвид Бушелл делится набором дефолтных стилей для кнопок, который он добавляет в свои проекты. И каждое свойство обосновывает.

- touch-action: manipulation поможет отключить спецэффекты типа зума страницы по двойному тапу в мобильных браузерах.
- user-select: none выключит выделение текста кнопок (если нужно).
- ::file-selector-button даст стилизовать кнопку выбора файла для <input type=file>.
- inline-size: fit-content — моё любимое, задаёт кнопке ширину по контенту, а не контейнеру.

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

https://dbushell.com/2024/03/10/css-button-styles-you-might-not-know/

Мгновенная валидация форм

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

https://doka.guide/recipes/validation/

Тестирование HTML при помощи CSS

Ох, как я люблю такие элегантные решения. Хейдон Пикеринг рассказывает, как реализована библиотека REVENGE.CSS (именно капсом, иначе она не работает).

Суть в том, что многие HTML-конструкции можно легко проверить банальной проверкой атрибутов. А в CSS для этого всё есть. Ещё часть можно проверить вложенностью, и тут нас радует :has(). Когда видим конструкцию, которая нас смущает, делаем две вещи:

1. Прямо в интерфейсе жутким шрифтом Comic Sans на розовом фоне выводим текстом предупреждение.

2. В DevTools в CSS-переменную записываем информативное сообщение об ошибке, чтобы его было видно при разработке.

Хейдон дополнительно использует новомодную директиву @layers, чтобы создать слой tests в проекте. Подключает его в самый низ слоёв, чтобы тестовые стили наверняка применились.

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

https://heydonworks.com/article/testing-html-with-modern-css/

Спеки-потеряшки на iOS

Шалана Доусон собрала замечательный по визуалу сайт, который на основе данных из caniuse показывает, какие спецификации не реализованы в WebKit для iOS, хотя уже есть в других мобильных браузерах (Chrome и Firefox).

Во-первых, это мило. Задумка в виде коробок с молоком, на которых напечатаны объявления о потеряшках, вызывает эмоции.

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

В-третьих, это просто красивый сайт для вдохновения. Сижу ковыряюсь в исходниках, изучаю, как синхронизируется вращение 3D-коробки и объявления на ней.

https://ios404.com/

Квантовая механика: 100 лет открытий за один час

Видео выходного дня. Доктор физико-математических наук Алексей Семихатов популярным языком объясняет, как устроен мир согласно квантовой механике. Люблю такие видео, которые ломают мозг, но при этом двигают вперёд.

https://youtu.be/4iAkAT7mhnw

Игра Wordle на HTML и CSS

Очередное интересное применение возможностей CSS не для того, для чего он задумывался.

Скотт Джел попробовал реализовать игру Worlde без использования JavaScript. Вы можете помнить эту игру, она когда-то была на хайпе: есть 5 ячеек, нужно в них ввести буквы. Если буква правильная и на правильном месте, то клеточка закрашивается в зелёный. Если буква правильная, но не на том месте — в жёлтый. И если мимо — в серый.

Сначала Скотт реализовал только хардкорную версию, где нет жёлтых клеточек. Либо угадал полностью букву, либо нет. Для этого использовал комбинацию селекторов по атрибуту, псевдоклассы :invalid и :valid, отслеживание фокуса и показа плейсхолдера. У меня сразу возникла идея, что можно было бы сделать генератор кроссвордов, которому не нужен JavaScript — принцип работы тот же.

Затем Скотт попытался реализовать всё-таки жёлтые клетки. Но как будто валидация по паттерну у инпута не умеет в сразу два паттерна: возможные значения и правильные значения. Если бы можно было задать три состояния, тогда получилось бы на чистом CSS. Но, увы, пришлось всё-таки добавить несколько строчек JavaScript, чтобы доделать игру полностью.

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

https://scottjehl.com/posts/wordleish/

API для работы со складываемыми экранами

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

Начиная с Chrome 125 за Origin Trial появится доступ к Device Posture API и Viewport Segments API.

Device Posture API позволит через CSS и JavaScript понимать, в каком состоянии сейчас складываемое устройство.
- @media (device-posture: folded) — устройство согнуто, экран разделён на две части.
- @media (device-posture: continuous) — экран сплошной (подходит в том числе для обычных экранов).

В JavaScript появится navigator.devicePosture, из которого можно получить то же самое. А ещё на него можно навесить addEventListener('change', ...), чтобы реагировать на изменения.

Viewport Segments API посложнее, тут рекомендую вчитываться в примеры в статье. Но если коротко, в функции env() появится ещё несколько ключевых слов, которые помогут работать с размерами сегментов складываемого экрана. Честно говоря, синтаксис не самый запоминающийся, у разных положений разные кодовые числа. Но по сути это единственный гибкий способ узнать нужные значения для вычислений в CSS.

В JavaScript появится window.visualViewport.segments, в котором будет лежать массив сегментов с их размерами.

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

https://developer.chrome.com/blog/foldable-apis-ot

Правильные для языка кавычки

Небольшое напоминание, что в разных языках правильные с точки зрения типографики разные кавычки. Например, в русском языке правильно использовать «ёлочки», а не "лапки".

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

blockquote::before {
  content: open-quote;
}
blockquote::after {
  content: close-quote;
}

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

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

q {
  quotes: "((" "{" "[" "_";
}

Больше не буду мучить content и селекторы по атрибутам.

https://www.stefanjudis.com/today-i-learned/how-to-use-language-dependent-quotes-in-css/

Руководство для фронтендеров 2024

Коди Линдли собрал для Frontend Masters гайд по тому, что можно изучить современному фронтендеру, чтобы прокачаться. От основ до углубления в технологии.

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

Во-вторых, это опенсорс, так что можно дополнять, если что-то упущено. Ссылки на инструменты, например, которых тут не так много на самом деле.

В-третьих, раньше, конечно, веб-мастером стать было сильно проще, чем сейчас фулстеком. Я хоть и понимаю всё, что в гайде есть, но шёл к этому 15 лет. «Фронтенд не такой сложной, как бэкенд», — говорили они.

https://frontendmasters.com/guides/front-end-handbook/2024/

TypeScript 5.5 Beta

Хотел сделать подробный пост, но зачем, если Зар уже это сделал.

https://news.1rj.ru/str/zarzakharov/566

Длинный alt

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

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

А вот Адриан Розелли подробно и с примерами объясняет, почему длинные тексты в alt — плохо.

1. Альтернативный текст рисуется в браузерах вместо картинок, если картинки по какой-то причине не загрузились. И если с короткими текстами всё более-менее аккуратно рисуется, то с текстом, который не помещается в изначальную «коробочку» для картинки, каждый браузер ведёт себя по-разному. Safari вообще текст перестаёт рисовать. А в Chrome и Firefox текст либо ломает вёрстку, либо обрезается без скролла.

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

3. Ссылки и тексты на другом языке (отличном от языка элемента или страницы) в разных скринридерах тоже читаются по-разному, но везде что-то ломается.

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

https://adrianroselli.com/2024/04/long-alt.html

Современный системный набор шрифтов

Когда-то давно мне понравилась идея, что можно выбрать из системных шрифтов подходящие, чтобы вообще не тратить время на загрузку шрифтов для сайта. Поэтому у меня в блоге до вчерашнего дня основной шрифт для текста был system-ui — алиас для выбора дефолтного в ОС шрифта. Ну и для кода Fira Code, он слишком хорош, чтобы от него отказываться.

Дэн Кламмер собрал интересные наборы системных шрифтов из разных ОС, которые не настолько приелись в интерфейсах, при этом выглядят хорошо. Обновил у себя в блоге шрифты заголовков на набор Old Style — нравится. И всё ещё шрифты загружаются только для примеров кода, Core Web Vitals что надо. Дизайнеры, наверное, ужаснутся от того, как я работаю с типографикой на глазок, но у меня и не дизайнерский блог же.

https://modernfontstacks.com/

Что нужно знать, чтобы начать делать local-first приложения

Есть такой тренд в современной разработке создавать приложения, которые изначально отлично работают без интернета, а потом как-то синхронизируются с сервером, когда интернет появляется. Браузерные API уже умеют столько всего, а веб-приложения так много делают прямо на клиенте, что по сути сервер в таких приложениях и правда нужен только для взаимодействия с БД.

Павел Гринченко рассказывает о трёх больших задачах, которые нужно решить, чтобы приложение научилось в local-first:
- хранение данных;
- синхронизация;
- разрешение конфликтов.

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

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

Но и реализовать local-first правильно тоже сложно. Нужно хорошо разбираться, как работает браузер, понимать CRDT и P2P. К счастью, Павел делится ссылками на решения, которые уже неплохо себя показали в реальных приложениях.

https://evilmartians.com/chronicles/cool-front-end-arts-of-local-first-storage-sync-and-conflicts

Инди vs Корпорат

Лёгкое пятничное.

Вастрик в свойственной ему манере шикарно раскладывает по полочкам, почему не стоит одинаково подходит к рабочим и пет-проектам. И почему кто-то делает инди-проекты на PHP+jQuery и получает миллионы долларов дохода, а кто-то пилит корпоративные приложения, следуя закону Конвея.

https://vas3k.blog/notes/indie_vs_corpo/

Как понять язык метрик своего бизнес-заказчика

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

https://youtu.be/asIcPJwF57Q

Телеграм-канал Серафимы:
https://news.1rj.ru/str/Serafima_Chekulaeva/