Браузер 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

GPTBot User-Agent

Как-то раньше не задумывался, но ведь ChatGPT — это такой же краулер, как и другие поисковики. То есть он собирает информацию из страниц в интернете, а значит заходит на сайт с каким-то User-Agent. Если поискать документацию, то с таким:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.0; +https://openai.com/gptbot)

И это значит, что я могу попробовать довериться честности разработчиков OpenAI и добавить в robots.txt исключения для GPTBot, если не хочу, чтобы контент моего сайта использовался для обучения AI-моделей. Если не могу довериться, то можно в принципе на сервере добавить мидлвару, которая будет по User-Agent из HTTP-заголовков находить ботов и отдавать им щедрое ничего.

Ну или расслабиться и ничего не менять. Кажется, что такие меры нужны только сайтам, где контент — способ зарабатывать. NY Times, Medium и прочие издания с платной подпиской, скорее всего, захотят так сделать. Моему блогу это не надо, пускай он влияет на какой-нибудь маленький персептрон в большой нейронной сети.

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

https://platform.openai.com/docs/gptbot

Как читать hex-цвета

Нашёл у себя в сохранённых старый доклад с dotCSS 2018 года. В нём Дэвид ДеСандро объясняет, как он со своей цветовой слепотой читает цвета по кодам. И сам по себе доклад пятилетней давности зародил у меня в голове много мыслей:

1. Чтобы работать с цветами, совсем не обязательно их видеть так же, как большинство. Достаточно знать математику работы с цветом. У нас ведь всякие цветовые палитры вполне себе описываются математически, доступность тоже.

2. HEX — супер-сложный формат для людей, но очень понятный для машин. Не просто так последние годы делается упор на работу сначала с HSL, потом с OKLCH. Если для HEX нужно запомнить как цветовой круг, так и произвести в голове некоторые вычисления для высчитывания яркости и насыщенности, в новых форматах всё довольно интуитивно, запоминать нужно только цветовой круг.

3. Как же всё-таки здорово, что в современных DevTools и IDE рядом со значением цвета рисуется квадратик с самим цветом. Это экономит кучу времени.

4. Чтобы переход на OKLCH произошёл, нужно, чтобы его поддержали графические редакторы. Как в 2018 году, так и сейчас разработчики копируют цвета, потому что так удобно и быстро. Если редактор показывает hex-цвет, то в коде тоже окажется hex-цвет. Да и не должны разработчики и дизайнеры разговаривать на разных языках, когда делают один интерфейс.

5. Я хочу научиться делать такие же красивые переходы в слайдах, как у Дэвида.

https://youtu.be/eqZqx6lRPe0

#видеозаписи

Весной многим понравился доклад Никиты Дубко про текущее состояние PWA.

А в этот #ТяжелыйПонедельник у нас двойная премьера: опубликовали сразу и видеозапись доклада, и его текстовую версию на Хабре.

Так что теперь его можно хоть посмотреть, хоть прочитать — как вам удобнее.

Как делать качественные плагины для Figma

Очередной подробнейший гайд от Злых Марсиан, как сделать классно. На этот раз про плагины для Figma.

У ребят есть проект Playbook, который помогает удобно организовывать работу с визуальным контентом. И написать к нему плагин для интеграции с Figma было вполне логичной идеей. Рита Клубочкина подробно описывает все шаги, которые понадобилось пройти, чтобы выпустить такой плагин:
- Изучение ограничений плагинов.
- Написание бэкенда.
- Проектирование архитектуры и выбор вспомогательных инструментов.
- Подключение авторизации.
- Настройка коммуникации между плагином и страницей.
- Оффлайн-режим работы.
- Подключение аналитики.
- Публикация в Figma Community.

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

Кстати, вот сам плагин: https://www.figma.com/community/plugin/1230012401218765040/Playbook

https://evilmartians.com/chronicles/how-to-make-next-level-figma-plugins-auth-routing-storage-and-more

Пригласили на стрим Доки поговорить про внерабочие активности: зачем они нужны, как они помогают в работе. Подискутируем, нужно ли вообще заниматься чем-то около работы вне работы.

Приходите послушать и позадавать вопросы.

Стили счётчиков

Мне кажется, счётчики — фича в CSS, которую иногда незаслуженно забывают. Помню, когда делал мини-фреймворк для оформления по ГОСТ-ам дипломной работы на HTML и CSS, счётчики сильно выручали. Номера глав проставить, пронумеровать изображения и таблицы, ссылки и источники — одно удовольствие.

Для веба тоже несколько раз пригодилось, когда нужно было хитро оформлять нумерованные списки. Приходилось выкручиваться с ::before, отменять браузерные дефолты. А так хотелось иногда применить @counter-style, который первым внедрил Firefox, а потом и Chromium подтянулся. Но Safari...

На неделе вышли Release Notes для Safari 17, который приедет с обновлением macOS после 26 сентября. И там написано, что @counter-style будет работать. Можно даже проверить, какие именно фичи будут работать, по тестам WPT.

Это значит, что в скором будущем в CSS можно будет кроссбраузерно делать такое:

@counter-style emoji-numbers {
   system: numeric;
   symbols: '0️⃣' '1️⃣' '2️⃣' '3️⃣' '4️⃣' '5️⃣' '6️⃣' '7️⃣' '8️⃣' '9️⃣';
   suffix: ' ';
}

ol { 
   list-style: emoji-numbers;
}

И вместо цифр в счётчике будут эмодзи. Или вот так сделать карту настроения (семантически не верно, но для примера сойдёт):

@counter-style rating {
   system: cyclic;
   symbols: '🙁' '😐' '🙂';
   suffix: ' ';
}

ol.rating { 
   list-style: rating;
}

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

https://developer.mozilla.org/en-US/docs/Web/CSS/@counter-style

«Халява» для разработчиков

Скинули интересный ресурс, где можно найти много всякого полезного и бесплатного для опенсорсных проектов и не только. Там есть инструменты CI/CD, сервисы проверки качества, шрифты, генераторы кода, CMS, хостинги, скриншотилки, мониторинги и многое другое. Где-то триал-версии, где-то бесплатный доступ только для open source, что-то работает только под VPN.

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

Со мной поделились, делюсь с вами.

https://free-for.dev/

Как вычисляются CSS-переменные

Хотя, как мне кажется, правильнее было бы назвать статью «Как НЕ вычисляются CSS-переменные».

Крайне полезная статья от Стэфани Эклз про то, какие особенности есть у CSS-переменных. Несколько важных фактов, которые нужно учитывать при вёрстке с их использованием:

1. Если у обычных наследуемых свойств некорректные значения приводят к дальнейшему поиску корректного значения по каскаду, то для CSS-переменных нет понятия корректного значения (если не использовать @property), это просто строка, поэтому обработка ошибки идёт уже во время вызова var(--my-color), по месту применения определяется, а может ли быть такое значение в принципе.

2. Некорректный var() обрабатывается очень похоже на то, как обрабатывается значение unset.

3. Фолбэки внутри var() тоже обрабатываются во время вызова, поэтому если их задать неправильно, срабатывает тот же принцип. То есть нельзя написать так:

color: var(--my-color, rgb(0, 0, 0));
color: var(--my-color, oklch(40.1% 0.123 21.57));

в надежде на то, что если браузер не умеет в oklch, то откатится на простой rgb. Нет, он снова сделает unset.

4. Сами CSS-переменные вычисляются на самом раннем возможном этапе. Поэтому нельзя мыслить о них, как о функциях, если делать что-то вроде --my-color: var(--accent-color).

:root {
  --font-size: 14px;
  --font-size-large: calc(2 * var(--font-size));
}

h1 {
  --font-size: 20px;
  font-size: var(--font-size-large);
}

В этом примере у заголовка размер будет не 40px, а всего лишь 28px. Уже во время обхода :root вычислится значение переменной, а во время вызова в h1 внутри var() — подставится вычисленное.

https://moderncss.dev/how-custom-property-values-are-computed/

Очистка кэша и кук на стороне клиента

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

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

В HTTP-заголовках можно найти интересное: Clear-Site-Data: "cache", "cookies". Сервер может отправить на клиент заголовок, который попросит браузер почистить куки и/или кэш. Работает везде, кроме Safari. То есть вместо того, чтобы просить пользователя что-то сделать в стрессовой ситуации, когда у него что-то не работает, а он девтулзы не открывал никогда до этого, можно сделать всё самим.

Гарри Робертс советует делать в веб-приложениях отдельную страничку с кнопками «Очистить куки», «Очистить кэш». Так у злоумышленников будет меньше возможностей сбрасывать жертвам ссылки, которые что-то чистят без спросу, потому что можно проверять Referer на сервере.

https://csswizardry.com/2023/10/clear-cache-on-customer-device/

Ходил в гости к 404. Много диванной аналитики, много субъективного мнения, не претендующего на истину. Но поговорили, подискутировали, пофантазировали. Можно слушать как подкаст 😉

Это не запись эфира... Это браузерные войны, интриги, расследования и доминирование в веб-платформе 🔥

Недавно к нам в гости заглядывали Никита Дубко из «Веб-стандартов» и Алексей Родионов, адвокат веб-платформы, официально признанный Google эксперт в области веб-технологий.

Какие интересы в развитии веб-платформы у крупных компаний? Действительно ли Chromium — свободный open source проект? Существует ли веб-платформа на самом деле? И почему современный фронтенд переусложнён?

📹 Запись эфира на ютуб-канале Фестиваля 404: https://youtu.be/DXdNTrpLzWw?feature=shared

0:58 Как Никита попал в «Веб-стандарты» и почему он до сих пор во фронтенде?
07:11 Что такое «браузерные войны» и продолжаются ли они сегодня?
16:03 Internet Explorer: появление, влияние и проблемы
20:51 Переход IE на Edge — причина доминирования Chromium?
24:15 Влияет ли доминирование браузеров на стандартизацию веба?
26:36 Кто делает веб?
30:10 Интересы крупных компаний в продвижении веб-платформы
33:46 Могут ли интересы производителей браузеров и пользователей разойтись?
35:12 Рассуждаем об интересах и планах Microsoft. Развитие Bing
39:28 Какими браузерами пользуется Никита?
41:59 Зачем Microsoft пылесосит рынок разработчиков? Монетизация приложений и PWA
47:19 В чём интерес Mozilla?
50:51 Google искусственно поддерживает разнообразие браузеров?
52:35 Отношение Mozilla к новым API. Стандартизация, инновации и фрагментированность.
58:52 Firefox проиграл Safari борьбу за приватность?
1:00:49 Как компании зарабатывают на браузерах
1:02:11 Как Apple видит будущее Safari? Интеграция браузеров в ОС
1:06:31 Удобство и интуитивность в экосистеме Apple
1:08:47 Почему Apple вкладывается в развитие веба? Все нативщики грешат с WebView
1:14:41 Как могут измениться браузеры через 10 лет?
1:18:30 Специализированные браузеры
1:20:54 Действительно ли Chromium — свободный open source проект?
1:28:32 Так ли хорош Project Fugu? Критика и похвала
1:34:38 Проблема обратной совместимости и «системные требования» для веба
1:38:23 Веб-компоненты. «Взлетели» или нет веб-компоненты?
1:42:05 Фреймворки vs. Веб-платформа. Про специализацию в веб-разработке.
1:48:03 Так все же… что такое PWA?
1:55:27 Никакой веб-платформы на самом деле не существует?
1:56:29 Современный фронтенд переусложнён?
2:01:01 Почему появляются фреймворки?
2:04:47 В чем разница между фреймворком и библиотекой?
2:08:01 Зачем нужно знание низкоуровневой платформы?
2:11:41 API — будущее веба? Нужен ли HTML? Про Telegram, ChatGPT, голосовые помощники
2:18:32 Какого API не должно быть в вебе?

Послушать эфир можно также в виде подкаста:
👉 Mave.Digital
👉 Яндекс.Музыка
👉 Вконтакте
👉 Apple Podcast

CSS4 быть. И CSS5 тоже

Ещё с 2020 года в w3c велось обсуждение: «А не определиться ли нам с тем, что такое CSS 4?». И вот на днях рабочая группа CSS решила дать зелёный свет этой инициативе. Суть в том, чтобы определить набор фичей, которые относятся к CSS 4, какие к CSS 5, и так далее. Стабильные фичи, которыми мы уже относительно давно пользуемся, станут CSS 4. Новые модные выражения от контейнера, сабгриды, слои, родительский селектор и прочие — CSS 5. Возможные будущие спецификации пока в CSS Next.

Явно скоро появится больше деталей и анонсов, более формализованные процессы, куда отнести фичу, как это соотносить с уровнями отдельных спецификаций. Но событие явно знаковое. Ещё бы, теперь CSS4 в резюме — не издевательство, а прямо необходимость.

https://github.com/orgs/CSS-Next/projects/1/views/2

Изолировал-изолировал, да выизолировал

На FrontendConf 2023 читал доклад «Алло, мы с нижнего этажа, у вас стили протекают», где рассказывал, как эволюционировал со временем подход к написанию CSS, какие ухищрения придумало сообщество, чтобы изолировать стили. И заодно показал современные приёмы, как влиять на каскад, наследование и изоляцию при помощи нативных CSS-переменных, @layer, @scope.

А вот и видео этого доклада: https://youtu.be/FeFMSZVFuBY

MinskCSS Meetup 11

Сегодня буду вести митап по CSS, присоединяйтесь в 19:00 по Минску.

Получилось собрать классную программу:
- Тим Чаптыков расскажет про разные секреты, чтобы попадать в топы cssbattle.dev — это такое соревнование, где надо нарисовать картинку на чистом CSS минимальным количеством символов.
- Нина Торгунакова поделится опытом уменьшения хаоса при работе с Tailwind CSS.
- Егор Левченко покажет, как делать свой опенсорс на примере Доки (доброй документации для веб-разработчиков).

Никакой регистрации, просто приходите 🙂

Программа — https://telegra.ph/MinskCSS-Meetup-11-11-28
Трансляция — https://www.youtube.com/watch?v=_fcB0kvXLlg