Новые возможности CSS, которые меняют взгляд на вёрстку

Вчера читал доклад на конференции DUMP про то, что наши страхи использовать новые фичи в CSS во многом обусловлены «детской травмой» веб-мастеров 2000-ых, что любое новое свойство скорее всего работает всего в одном браузере, а в остальных либо кое-как, либо никак. А на самом деле благодаря инициативе Interop многие фичи появляются чуть ли ни одновременно в вечнозелёных браузерах (вот бы ещё Safari подтянули релизный цикл хотя бы до обновления в пару месяцев).

Заодно поделился CSS-свойствами, которые нашёл крайне интересными за последние полгода.

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

Переопределение заголовков ответа для дебага

В Chrome 113 Dev Tools появилась, на мой взгляд, потрясающая фича, которая сильно ускорит параллельную разработку фронтенда и бэкенда в некоторых конкретных случаях.

Представьте, что у вас есть какая-то функциональность на сайте, которая зависит от HTTP-заголовков ответа сервера. Да даже представлять особо не надо, она точно есть: кэширование, куки, CORS, CSP, скачивание файлов, редиректы и разное другое. И вот в какой-то момент эту функциональность нужно доработать новыми заголовками, но на бэкенде доработка требует 2 дня разработки, тестирование и деплой, а на фронтенде — пары часов небольших правок с тестированием. Что можно сделать, чтобы не стопорить фронтенд в таком случае:

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

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

3. Воспользоваться новой фичей Chrome Dev Tools! (как будто в телемагазине вещаю, простите)

В чём суть фичи:
- В открытых Dev Tools во вкладке Network > Headers > Response Headers теперь можно редактировать заголовки ответа сервера. Или добавить новые.
- Во вкладке Sources > Overrides можно найти домен, на котором экспериментируете с заголовками, и отредактировать там файл .headers, внутри которого можно задать переопределения не конкретному ответу, а вообще всем ответам.

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

https://developer.chrome.com/blog/new-in-devtools-113/#network

D&D Tokenizer

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

За выходные собрал приложение для рисования токенов персонажей в настольных играх. По названию можно понять, что фокус сделал на D&D. Мы с друзьями привыкли, что у всех NPC и у наших игровых альтер-эго есть красивые картинки, а рамка — часть этого впечатления. Делал для себя, но почему бы не поделиться со всеми.

Разумеется, буду приложение дорабатывать постепенно, там есть над чем работать. Но PWA на вкус попробовал — очень нравится.

Исходники: https://github.com/MeFoDy/dnd-tokenizer
Сам проект: https://dnd-tokenizer-41471e.netlify.app/

Одно PWA, чтобы править всеми

Вчера на HolyJS читал доклад про то самое приложение для генерации картинок-токенов, про которое писал выше. Цель доклада в том, чтобы убедить разработчиков, что PWA вполне себе могут заменить нативные приложения в каких-то случаях. Не во всех, это точно, но во многих. На самом деле не так уж и часто нативные приложения нуждаются в каких-то редких низкоуровневых API, при этом под капотом часто у них WebView, из которого уже можно сделать PWA меньшими усилиями.

Самую большую дискуссию вызвал вопрос безопасности PWA: «Можно ли написать что-то банковское и безопасное фронтенд-инструментами?» На мой взгляд, здесь между нативным и PWA разница очень маленькая:

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

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

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

— Банковские приложения внезапно начали писать на PWA. А у банков аудиты безопасности обычно очень даже серьёзные.

Дискуссия интересная, на конференциях явно нужен доклад про безопасность в PWA, будет полезно.

Видео доклада пока нет, но слайдами уже могу поделиться: https://mefody.github.io/talks/pwa-2023/

MinskJS #10

Кто давно со мной знаком, знают, что когда-то я был в составе организаторов минских сообществ MinskJS и MinskCSS. У нас были крутые оффлайн-митапы с трансляциями, полные залы на площадке Space в Минске.

Недавно вернулся в мои любимые сообщества, помогаю Саше Шинкевич и Глаше Жур делать классные онлайн-митапы: искать спикеров, прогонять доклады, делать минский движ ярче. MinskCSS #10 вообще транслировали из моей квартиры.

Завтра (31 мая) в 19:00 у нас как раз состоится онлайн-митап MinskJS #10, где поговорим про путь браузера от ввода урла в адресную строку до отрендеренной страницы, «толстые клиенты» и расширение круга знакомств в индустрии, если ты интроверт. Всех приглашаю, заваривайте пельмешки, зовите коллег и задавайте вопросы в чате. Увидимся!

https://minskjs.timepad.ru/event/2406669/

Стратегия оптимизации перфоманса веб-страницы

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

Шаг 0. Настройте инструменты, измерьте текущее состояние страницы.
Шаг 1. Правильно поместите всё самое важное внутрь <head>.
Шаг 2. Настройте загрузку критического CSS.
Шаг 3. Поиграйтесь со шрифтами.
Шаг 4. Позаботьтесь о метрике LCP.
Шаг 5. Разберитесь с загрузкой JavaScript.

https://smashed.by/perf-strategy

Sunday CSS

У Юли Миоцен на канале раз в неделю выходят ролики о том, как при помощи CSS рисовать. Не верстать страницы, а именно рисовать. Кинематографичные анимации, иллюстрации, псевдо-3D псевдоигры. Юля объясняет и показывает, из чего состоят такие иллюстрации и как из одного HTML-элемента на странице извлечь максимум пользы на «холсте».

Вдохновиться готовыми демками Юли можно здесь: https://codepen.io/miocene

https://youtube.com/playlist?list=PLbNASFXzvzeaS5ELuPN4imYOuETjxX_x_

Приложил руку к большому числу заданий. Приходите ломать.

Техника появления из жёлтого

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

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

Сейчас всё ещё нужно делать так же, но скоро появится новый способ делать это исключительно средствами CSS. У Брамуса есть хороший пример, с которым всё становится понятнее.

div {
  transition: background-color 0.5s;
  background-color: transparent;

  @starting-style {
    background-color: yellow;
  }
}

В этом примере сначала у дива будет жёлтый фон, потом за 0.5 секунды он станет прозрачным. Никакого JavaScript, исключительно магия CSS.

Пока что эта возможность доступна только пользователям Chrome Canary 115+ с включёнными экспериментальными флагами веб-платформы. Правило настолько свежее, что caniuse про него просто не знает, а в спецификации CSS Transitions даже в черновике пока про такую возможность ещё ничего не написано. Но раз Chrome потихоньку внедряет, скоро появится и спецификация.

https://www.bram.us/2023/05/24/the-yellow-fade-technique-with-modern-css-using-starting-style/

19:00 https://ctf-2023.ilovefrontend.ru

Новые возможности CSS, которые меняют взгляд на вёрстку (видео)

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

Скидываю: https://youtu.be/_JB-wXwryhw

AI Explain: postmortem

Если вы вдруг пропустили, в MDN произошёл интересный случай с тем, как chatGPT внедрили в документацию, а через два дня его выключили.

27 июня появился анонс новой функции AI Help — эдакого помощника для подписчиков MDN Plus, в котором можно было спросить chatGPT 3.5 про всякое вроде «как центрировать div по вертикали», «как наложить маску на картинку» и так далее. Команда, на самом деле, проделала хорошую работу, чтобы обучить модель контексту: скормили модельке статьи на MDN, которые вышле после 2021 года (ограничение модели 3.5), протестировали, даже автотестами покрыли.

Рядом с этой функцией появился AI Explain — возможность попросить AI объяснить какой-то код на странице. В статьях на MDN часто есть сниппеты кода с примерами, но в них помимо объясняемого в статье свойства бывают и другие сложные для восприятия новичками особенности. Цель инструмента, как говорит команда MDN, была как раз в помощи новичкам.

30 июня на гитхабе появилось ишью про то, что MDN теперь врёт пользователям автоматизированно. Комьюнити собрало много примеров, где AI не просто не справлялся с задачей, но ещё и выдавал ложные сведения. Мы в подкасте тоже обсуждали этот инцидент, можете послушать, если хотите подробностей. В ишью выяснилось, что фичу катнули в принципе мимо согласования с MDN Core Team. И тем самым сильно подорвали доверие к MDN как источнику корректной технической информации.

1 июля AI Explain выключили для всех пользователей сайта.

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

Мораль:
- Применяйте AI осторожно. Он может помогать в вашей работе, но всё ещё не гарантирует валидности выдаваемой информации.
- Продумывайте UX. Если бы где-то на сайте была огромная плашка «Это ответ AI, он может врать, проверяйте за ботом», комьюнити, возможно, не так сильно бы и злилось.
- Не тащите AI бездумно в проект, лишь бы усидеть на паровозике хайпа.

https://developer.mozilla.org/en-US/blog/ai-explain-postmortem/

Доклады JS Nation 2023

Конференция JS Nation опубликовала записи докладов 2023 года. Там есть про перфоманс, доступность, веб-компоненты, TypeScript. Много крутых экспертов. Добавляйте в закладки, чтобы посмотреть на досуге, пока ваш проект собирается.

Себе в закладки добавил:
- доклад Вани Акулова про то, как некоторые общие советы по загрузке веб-приложений в конкретных случаях скорее вредят, чем помогают;
- доклад Максима Сальникова про веб-пуши — с их появлением в Safari тема как никогда актуальная;
- доклад Зака Лезермана про веб-компоненты — интересно посмотреть, как он их реализует совместимо с 11ty, который очень хорош по перфомансу из коробки.

https://portal.gitnation.org/events/jsnation-2023/talks

Better full screen mode with the Keyboard Lock API

Томас Штайнер делится хорошим примером, когда можно сделать пользовательский опыт лучше очень коротким сниппетом кода. Представьте, что вы открылы браузер в fullscreen-режиме, открыли модалку на сайте, пытаетесь её закрыть при помощи Esc — что произойдёт? Правильно, браузер выйдет из fullscreen-режима, потому что в ОС по умолчанию так сделано. Я на macOS постоянно из-за этого страдаю.

Так вот, есть Keyboard Lock API, который позволяет заблокировать какие-то кнопки или вообще все. В случае с Escape нужно будет не нажать кнопку, а зажать, чтобы выйти из fullscreen-режима.

// блокируем
await navigator.keyboard.lock(['Escape']);
// разблокируем
navigator.keyboard.unlock();

Я периодически пользуюсь веб-приложениями, которые для моего лучшего пользовательского опыта на любое нажатие клавиши на клавиатуре пытается что-нибудь сделать. Не через Alt+F, например, а через просто F, K, S и так далее. Беда в том, что я никогда этими шорткатами не пользуюсь, они мне не нужны, но в настройках выключить не могу. Если бы были нужны, то лучше через какие-то комбинации клавиш. И вот заполняю я форму на этом сайте, нечаянно фокус не выставил, начал набирать текст — а сайт в этом время заполнил форму, завёл тикет в саппорт, приготовил глазунью и включил тёмную тему. Теперь могу сделать себе через браузерные расширения или закладки отключение этой ненужной мне функции.

Эта апишка работает только в Chromium-браузерах, но довольно давно. Как прогрессивное улучшение — почему бы и не да.

https://developer.chrome.com/blog/better-full-screen-mode/

Браузер Arc

Свершилось. Сегодня браузер Arc вышел в версии v1.0 и отключил лист ожидания. Это значит, что его может установить каждый без инвайт-кодов.

Я им пользуюсь уже давно, хоть и не постоянно. Основные фичи, которые мне нравятся:
- Сплит-вью. Можно разместить вкладки в одном окне рядом. Незаменимая фича для подготовки докладов.
- Всё на комбинациях клавиш. К тачпаду тянусь довольно редко, причём комбинации можно переназначать под себя.
- Пользовательские стили. Раньше в такое умели все браузеры, а теперь как будто только в Arc это осталось без расширений. В твиттере у меня всё ещё птичка в качестве лого :)
- Разделение на пространства. Завёл себе группу вкладок для записи подкастов, для игр в D&D и для подготовки докладов.
- Вкладки закрываются сами, если не открывать их в течение суток.
- Список вкладок — горизонтальный список, а не табики. Просто нравится, экран ведь широкий.
- По умолчанию можно скрыть весь интерфейс. Больше от сайтов ничего не отвлекает.
- Режим превью. Любую ссылку можно открыть в окне предпросмотра, и если уже надо, то тогда открыть как полноценную вкладку.

Ничего лишнего. Настраиваемое. Удобное. Попробуйте.

Да, работу работаю я всё ещё в Chrome. Потому что там удобнее с инструментами разработчика играться. Но пользоваться интернетом пока приятнее в Arc. Плюс у них классная работа с сообществом, на мои багрепорты отвечали очень быстро. В общем, хорошо, когда на рынке появляется что-то новое, пусть под капотом там всё тот же Chromium.

https://arc.net/

Стилизуй свой RSS

Дэрек Кэй предлагает интересное. Если у вас есть блог, или вы делаете новостной сайт, или сайт с какой-то обновляемой базой знаний, то скорее всего вы уже прикрутили RSS-ленту. Я, например, RSS пользуюсь постоянно, подписан много на кого через Feedly.

И вот пользователь переходит по прямой ссылке на RSS-ленту. Скорее всего он увидит месиво из XML-тегов и их содержимого. Казалось бы, ну и ладно, это же для автоматики страница, а не для людей.

Но у нас ведь есть древний способ стилизовать XML-документы — XSLT. В прошедшем недавно ЯЛФ CTF как раз было задание, где нужно было в XML-документе поиграться со стилями и получить нужный для ответа флаг.

Как это работает:
1. Вы заводите XML-документ с данными. RSS — это подмножество XML.
2. К нему прикрепляете XSL-стили. <?xml-stylesheet href="/rss.xsl" type="text/xsl"?>.
3. Внутри XSL описываете шаблон представления данных. По сути — HTML с дополнительными возможностями шаблонизации, среди которых циклы, фильтрация, работа с «объектами», условия и прочее.
4. Туда же добавляете обычные CSS-стили, потому что уже есть привычный HTML-шаблон с тегами и классами, если нужно.
5. Если в RSS-ленту зайдёт робот, он не будет ничего делать со стилями и просто распарсит вашу ленту, как ему надо. То есть ничего не меняется.
6. Если зайдёт по прямой ссылке реальный пользователь, он увидит красивую ленту в стиле вашего сайта. Можно, например, приделать инструкцию, как подписаться на эту ленту.

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

https://darekkay.com/blog/rss-styling/

О порядке применения трансформаций

София Валитова проверила по спецификации, в каком порядке применяются CSS-свойства transform, transform-origin, translate, rotate и scale, и на примерах показывает, чем задание индивидуальных свойств отличается от задания частей свойства transform.

Напомню, теперь во всех основных браузерах есть индивидуальные свойства трансформации, то есть вместо transform: scale(1.2) можно писать scale: 1.2. Помню, в чатике Веб-стандартов была заруба, что чаще всего нет разницы, как писать эти трансформации, потому что редко мы используем сложные трансформации, где подряд несколько translate, например. А я недавно как раз наткнулся на такой случай, где трансформации из библиотеки мешали трансформациям из дизайн-системы. В общем, однозначно полезная заметка от Софии, которая поможет не путаться.

Кстати, у Софии есть свой канал, где она делится похожими находками из мира CSS, подписывайтесь: https://news.1rj.ru/str/css_mind.

https://ru.ariarzer.dev/2023/notes/transformation_order/index.html

Кладезь полезных докладов по доступности!

В своё время мой мир перевернуло видео, где Анатолий Попко, незрячий, пришёл в гости в Вилсакому и показал, как он пользуется техникой. Теперь у меня язык не поворачивается сказать «доступность не нужна».

Лера Курмак делает важное дело, помогая разработчикам думать об интерфейсах по-другому. Если вам тоже приходится верстать интерфейсы, обязательно подпишитесь на канал «Не исключение», там много полезных материалов про a11y.

В преддверие курса по цифровой доступности A11y Unity, мы решили провести уже четвертую конференцию по доступности.

Пишите в комментариях, какие темы, вы бы хотели послушать. А также, если у вас уже есть доклад, с которым вы бы хотели выступить, тоже пишите в комментариях. Ну а если вы пропустили предыдущие конференции, ловите несколько ссылок на доклады:

• Доступные фичи и где они обитают, Таня Фокина
• Дизайн система — доступность через ограничения, Ник Лопин
• Встреча с незрячим пользователем программ экранного доступа (скринридеров). Женя Арнапольский
• Как задокументировать дизайн и не облажаться. Кай Катонина
• Встреча с пользователем с астеническим синдромом. Паша Любецкий
• Доступность физического и цифрового пространства на выставках и в Музеях. Мария Щекочихина
• Встреча с пользователем с нарушением моторики, Денис Редькин
• Как искусственный интеллект и другие технологии меняют доступность

Даты конференции мы пока финализируем, а вот с датами курса уже определились. Он стартует 23 сентября и до 12 августа действует скидка, присоединяйтесь accessibilityunity.com !

INP Debugger

Нашёл интересный инструмент для замеров метрики INP. Расшифровывается она как Interaction To Next Paint и в 2024 году станет частью Core Web Vitals. Если коротко, то INP равняется количеству миллисекунд, прошедших от пользовательского действия до визуального обновления на странице. Например, пользователь нажимает кнопку, вы обрабатываете клик, шлёте запрос на сервер, ждёте ответа, показываете сообщение на странице. Так вот INP — это значение самой большой задержки после пользовательского ввода на странице. Подробнее можно почитать вот здесь.

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

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

https://www.debugbear.com/inp-debugger