keyux

Андрей Ситник выпустил библиотеку, помогающую удобнее работать с сайтом при помощи клавиатуры. Под капотом работает с ARIA-атрибутами, то есть если вы изначально доступно размечали комбинации клавиш, то библиотека сработает как прогрессивное улучшение.

Кроссбраузерно, фреймворко-агностично, в сжатом виде всего 1 КБ, без зависимостей, с отличной документацией прямо в Readme проекта.

https://github.com/ai/keyux

Интерактивный гайд по :has()

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

Что можно подсмотреть:
- Как правильно делать boolean-логику на основе has().
- Как радикально менять разметку на основе количества вложенных элементов (например, когда мало карточек — растягивать их на всю ширину, а когда много — рисовать плотно и колонками).
- Как делать фолбеки, если какого-то элемента нет (например, когда картинка товара есть — рисуем картинку, а когда нет — заранее подготовленный placeholder).
- Как изменять размеры контейнера на основе его содержимого (для маленьких виджетов резервировать поменьше места на сам контейнер в раскладке, для больших — побольше).
- Как сделать всплывашки и попапы, которые не перекрывают друг друга (очень хороший пример про GDPR-баннер и иконку чата с поддержкой, которые на большом количестве сайтов друг другу мешают).
- Как научить панель управления с кнопками визуально реагировать на наличие особенных кнопок внутри.
- Как сделать зависимые друг от друга инпуты (например, если значение select требует уточнения, рисуем инпут для этого уточнения).
- И многое другое.

Примеры из списка сразу хочется сделать на каком-нибудь React: затащить на клиент логику показа компонента в зависимости от пропсов, перерендерить при необходимости. Но в этом и огромное преимущество :has() — ему не нужны фреймворки. При помощи этого селектора и дисциплины в именовании классов можно творить самые настоящие «умные» компоненты без единой строчки JavaScript. А это и меньший клиентский бандл, и меньшее количество ререндерингов.

Напоминаю, что не стоит забывать про старые браузеры, которые в :has() пока не умеют. Но если ваш проект работает с вечнозелёными браузерами, то уже можно внедрять: https://caniuse.com/css-has.

https://ishadeed.com/article/css-has-guide/

Итак, что же на самом деле ломает Apple в ЕС?

Думаю, мимо вас не прошла новость о том, что с 6 марта 2024 года Apple обязаны обеспечить в Евросоюзе выполнение закона DMA, в том числе разрешить установку сторонних магазинов приложений и альтернативные браузерные движки. Официальный анонс можно почитать тут, а ещё мы в подкасте «Веб-стандарты» несколько раз эту тему обсуждали.

Так вот, Томас Штайнер, проживая в ЕС, собрал более-менее точный список того, что сломается для пользователей iOS в Европе уже скоро:
- Push API. Оно доступно только для Home Screen web apps, а так как их больше не будет, то и доступа к API не будет. А ведь нотификации не только про зло, в разных приложениях они очень даже полезные.
- Badging API. То же самое, из-за привязки к Push API. Никаких чиселок на иконках веб-приложений.
- Режим standalone. Открываться будет в браузере, спрятать панельник браузера теперь никак не получится, никакого нативного опыта.
- Хранимые данные. Напомню, в Web Apps данные для каждой «иконки » сохранялись в своё изолированное хранилище. И если до 6 марта оно было чем-то наполнено — се ля ви, логиньтесь заново, вносите данные с нуля.
- Несколько ярлыков для одного и того же Web App. Я таким пользовался для разных аккаунтов твиттера, удобно. Данные ведь изолированы.

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

https://blog.tomayac.com/2024/02/28/so-what-exactly-did-apple-break-in-the-eu/

«А разговоров-то было!»

Apple обновили страничку с подробностями про поведение iOS в Евросоюзе. И там появился новый ответ на вопрос «Why don’t users in the EU have access to Home Screen web apps?» в секции Q&A. И если коротко, то к ним поступили просьбы продолжить поддержку Web Apps в iOS, поэтому они вернут старое поведение в обновлении 17.4. Работать будет только в WebKit, остальным браузерам придётся пока подождать.

Про «вернут», конечно, интересно написали. По сути ведь ещё ничего не исчезло, оно в обновлении 17.4 и должно было пропасть. Но «ничего не изменится» не так хорошо для анонса звучит. Ну и «просьбы» — это полноценная петиция от Open Web Advocacy, но про неё тоже как-то не захотели в анонсе писать.

Короче, выдыхаем. PWA на iOS пока в безопасности. Когда шума много, можно чего-то достигнуть. А шумели и обсуждали не зря.

https://developer.apple.com/support/dma-and-apps-in-the-eu/

MinskJS Meetup #11

Если вы не знали, я ещё и минские митапы по фронтенду помогаю делать. И уже в эту среду (6 марта) в 19:00 (по минскому времени) у нас будет онлайн-митап MinskJS. Со спикерами делаем финальные прогоны, готовим трансляцию, а вы можете сохранять в закладки:
- программу митапа, https://telegra.ph/MinskJS-Meetup-11-01-19;
- ссылку на трансляцию, https://www.youtube.com/watch?v=lQmFPJUljNM.

В программе:
- «Апгрейд браузера с помощью Web Extension API», Александр Селиванов.
- «Создание виджетов на iOS с использованием JSX», Олег Поздняков.
- «Не учите алгоритмы, они не нужны!*», Полина Гуртовая.

Да, никакой регистрации. Просто приходите. Всех ждём 🙂

Что на самом деле делает атрибут decoding у img?

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

Возможно, вы замечали, что иногда к изображениям зачем-то добавляют decoding=async. Возможно, вы даже сами добавляли такой атрибут по советам из статей по оптимизации перфоманса. А если вы пользуетесь компонентом Image из NextJS, то у вас в проекте точно по умолчанию для картинок включён этот атрибут. А он вообще важный?

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

Начнём с того, что у decoding может быть три значения по спеке:
- sync — просим браузер декодировать картинку синхронно;
- async — просим браузер декодировать асинхронно;
- auto — доверяем браузеру выбрать самостоятельно.

Пока понятней не стало. Но мы уже знаем, что у картинок есть этап декодирования. То есть когда браузер видит в коде страницы <img src='...'>, он сначала попросит сетевой кусок браузера сходить за картинкой в сеть или кэш, потом ещё один вспомогательный кусок попросит декодировать картинку (превратить из набора байтов в понятные для отрисовки данные, не просто так же кучу кодеков придумали сложных для сжатия), и только потом отрисует.

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

А ещё в Firefox по умолчанию у всех картинок применяется async. А у Chrome sync. А у WebKit в большинстве случаев sync, но для некоторых исключений всё же async. То есть сами браузеры до сих пор не договорились, какое поведение должно быть дефолтным.

На самом деле значительная разница появляется тогда, когда вы вставляете картинки при помощи JavaScript. А в современном SPA-мире такое сплошь и рядом. Джейк Арчибальд собрал демку, на которой в разных браузерах можно эту разницу заметить (ссылка в статье). Суть в том, что если внутри JS последовательно создать div с красным фоном, а потом внутрь него положить баааальшой img, загруженный через тот же JS, то в случае с sync случится подвисание страницы, потому что браузер увидит инструкцию декодировать синхронно и отложить отрисовку до окончания декодирования. А в случае с async вы сначала увидите красный фон у div, и только потом поверх нарисуется картинка, что тоже не ок, потому что моргание на экране.

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

В общем, после прочтения статьи хочется дать такие советы:
- Если вы и так загружаете картинки при помощи JS, то добавьте ещё await img.decode();. Эта конструкция всё равно асинхронная, зато перед отрисовкой будет всё готово, чтобы отрисовать быстро.
- async всё же предпочитетельнее для ситуаций, когда вам текстовый контент на странице важнее картинок. Будет два кадра отрисовки, но зато текст появится чуть-чуть раньше. На слабых устройствах это «чуть-чуть» будет заметно глазу.
- Для тонкого тюнинга Core Web Vitals, особенно LCP, пробуйте разное. Интуитивно кажется, что sync правильнее, чтобы не тратить время на лишнюю отрисовку, но браузер слишком умный, поэтому банально надо пробовать разное и сравнивать.
- Если вы занимаетесь тюнингом декодирования картинок на сайте, то либо ваш сайт уже идеален по перфомансу, либо можно заняться более полезными вещами, вроде ленивой загрузки и оптимизации самих картинок.

https://www.tunetheweb.com/blog/what-does-the-image-decoding-attribute-actually-do/

Держим <head> в порядке

Наткнулся на интересный скрипт, который позволяет провести очень быстрый аудит и относительно быстро починить порядок тегов внутри <head>.

Есть такой CSS-сниппет от Гарри Робертса, который подсвечивает неправильный порядок служебных тегов. Называется ct.css. И ещё доклад про этот сниппет. Гарри — очень крутой специалист по веб-перфомансу, к тому же слайды довольно убедительны.

Скрипт capo.js делает почти то же самое, только выводит результаты аудита в консоль. И даёт советы, как лучше отсортировать мета-теги, OG-разметку и прочее содержимое <head>, чтобы отдавать самое важное для быстрого отображения страницы сразу, а остальное попозже.

Попробовал запустить на нескольких сайтах — не врёт, и правда есть смысл внести правки.

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

https://rviscomi.github.io/capo.js/

Открытие файлов в веб-приложении

Думаю, все когда-нибудь делали набор действий «Правой кнопкой мыши — Открыть с помощью... — Какое-то приложение». PWA на десктопе тоже можно добавить в список приложений, при помощи которых можно открывать файлы определённого формата.

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

Для этого нужно сделать две вещи:
- Добавить в веб-манифест массив обработчиков file_handlers. Нужно указать, какой относительный URL открывать при открытии файла. И можно указать иконки, чтобы они в меню подставлялись рядом с названием приложения.
- При открытии PWA обработать window.launchQueue — именно сюда браузер сложит файлы, которые пользователь попытается открыть из операционной системы.

Я у себя похожее внедрял в своём D&D Tokenizer, чтобы любые картинки быстро передавать в PWA для рисования игровых токенов. Экономит время, удобно. А для всяких веб-плееров, которые умеют работать с локальными файлами, ещё и необходимо.

https://dev.to/denladeside/handling-files-in-enterprise-web-solutions-3mkc

Создание цветовых палитр при помощи CSS-функции color-mix()

Мишель Баркер очень подробно объясняет, как работает функция color-mix(). По сути при помощи неё можно смешивать цвета, только важно разобраться, как работает это смешивание.

Когда вы пишете color-mix(in srgb, blue, red), то по сути вы смешиваете синий и красный в соотношении 1:1. При этом смешивание — это интерполяция. Очень грубо говоря, для sRGB браузер возьмёт отрезок на градиентной цветовой плоскости между двумя точками, выберет середину, выдаст результат. Для пространств вроде oklch всё сложнее, но суть та же — у браузера есть правила интерполяции.

Для записи color-mix(in srgb, blue, red 10%) синего будет 90%. В сумме браузер попытается сделать 100%.

А вот с color-mix(in srgb, blue 10%, red 20%) случай интересный. Здесь суммарный цвет получится в соотношении 1:2, но непрозрачность цвета будет 0.3, потому что оставшееся до 100% заполняется прозрачным цветом.

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

https://developer.mozilla.org/en-US/blog/color-palettes-css-color-mix/

Safe/unsafe в флексбоксах

Когда в субботу записывали подкаст, внезапно обнаружил в релизноутах Safari TP поддержку внутри flexbox ключевых слов safe и unsafe. Подумал, что это что-то новое, пошёл разбираться. Оказалось, в Firefox это есть аж с 2018 года. И в Chrome оно тоже есть.

Стефан Джадис удивился так же, как я. В своей статье он показывает, для чего эти ключевые слова нужны.

Пусть у вас есть вёрстка на флексбоксах, в колонку. И пусть вы выравниваете контент по центру при помощи align-items: center;. Если контент по какой-то причине не помещается во вьюпорт, что должен сделать браузер? Ну, я его попросил выравнивать по центру, он и будет выравнивать по центру. Но, к сожалению, левая часть большого блока будет спрятана за левым краем вьюпорта. И, как вы понимаете, подскроллить к этой спрятанной области у пользователя возможности не будет. Это — поведение ключевого слова unsafe, которое прописывать не обязательно. Для картинок такое поведение, наверное, подходит, а вот для текстов нужен другой подход.

Если мне всё-таки важно не прятать левый край, можно написать align-items: safe center;. И в таком случае браузер, когда уткнётся левым краем большого блока в левый край вьюпорта, начнёт этот большой блок двигать вправо. Скролл спасёт пользователя от потери информации. Удобно.

https://www.stefanjudis.com/today-i-learned/safe-unsafe-alignment-in-css-flexbox/

Тултипы на CSS

Темани Афиф показывает, как при помощи разных CSS-техник рисовать тултипы с хвостиками. Есть варианты со сплошной заливкой, с выделенной обводкой. Позиция хвостика управляется при помощи CSS-переменных. Ну и в HTML это всего лишь один элемент <div class="tooltip">Текст</div>. Под капотом много clip-path и математики.

Часть 1: https://www.smashingmagazine.com/2024/03/modern-css-tooltips-speech-bubbles-part1/
Часть 2: https://www.smashingmagazine.com/2024/03/modern-css-tooltips-speech-bubbles-part2/

CSS-каскад. (Ново)введение

Видео выходного дня. Мануэль Матузович на примерах показывает, как работает каскад в CSS. Особый упор делает на объяснение @layer и @scope, которые появились не так давно, но на каскад сильно влияют.

https://vimeo.com/916686376

Индикатор прогресса

Энди Белл показывает, как можно собрать веб-компонент, который умеет в анимацию прогресса, показывает галочку на 100%, доступный, стилизуемый, адаптируемый под размеры контейнера. Решение родилось из челленджа, который Энди запускал в своём Front-End Challenges Club.

https://piccalil.li/blog/solution-009-progress-indicator/

Scroll snapping для заголовков

Думаю, вы уже успели попробовать свойства из семейства scroll-snap в CSS. Они очень удобные, чтобы создавать всякие простые карусельки без JavaScript. И почти везде их как раз на карусельках и показывают, потому что самый очевидный пример.

Крис Койер предлагает интересную, хоть и сомнительную идею применять снаппинг для заголовков. Представьте, что у вас есть статья с короткими абзацами, где много заголовков. И когда пользователь скроллит, можно заголовок с абзацем как карточку «примагничивать» к верху вьюпорта, чтобы красиво переключалось между разными фрагментами текста.

Сомнительность такой истории в том, что сложно предугадать, поместится текст во вьюпорт или нет. И в демках Криса я не могу прочитать последний абзац одной из таких «карточек» — его выбрасывает за вьюпорт постоянно.

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

https://frontendmasters.com/blog/chill-scroll-snapping-article-headers/

«Я💛Ф» 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/