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

Люблю читать про разное интересное, с чем приходится сталкиваться браузерам, чтобы не сломать интернет. Ингве Петтерсен рассказывает о том, почему заголовок 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

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

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

Разбираемся с 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/

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

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

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

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

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

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

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

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

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

CodeRun

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

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

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

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

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

https://coderun.yandex.ru/catalog

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

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

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

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

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/

Новые возможности 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/