#статья дня

Я давно такого удовольствия не получал. Технических знаний много не требуется, но при этом погружение в кишки браузеров и формат GIF с головой.

Это я об этом: https://www.biphelps.com/blog/The-Fastest-GIF-Does-Not-Exist

Правда, буду честен, я читал в переводе на хабре: https://habr.com/ru/post/676480/

Потому что циановый фон блога, где размещён оригинал, это какой-то ад… но сути дела не меняет.

Итак, в чём же история? История в том, что все браузеры и все программы просмотра GIF на свете совершенно неверно обрабатывают задержку между кадрами. Да так, что даже лишают нас многих возможностей формата.

Точнее, на всё есть свои причины. Исторические в основном. Chrome кивает на Firefox, тот на IE, тот на Netscape… беда.

И всё это снабжено, собственно, примерами кода. Прям как в двигателе покопался.

#gif #img #web

#ссылка дня

А как сделать кнопку? А как тулбар? А как сверстать несколько колонок с перекрытием? А если мне анимации стандартные не подходят?

Ни слова больше! Google has us covered!

https://web.dev/patterns/

От простых вещей вроде кнопки или описания кривой Безье для анимации до загрузки файлов, работы с буфером обмена и превращения сайта в PWA.

Хотелось бы больше примеров, конечно, но кому не хочется? :)

#web #app #patterns

#ссылка дня

А как сделать кнопку? А как тулбар? А как сверстать несколько колонок с перекрытием? А если мне анимации стандартные не подходят?

Ни слова больше! Google has us covered!

https://web.dev/patterns/

От простых вещей вроде кнопки или описания кривой Безье для анимации до загрузки файлов, работы с буфером обмена и превращения сайта в PWA.

Хотелось бы больше примеров, конечно, но кому не хочется? :)

#web #app #patterns #бородач

#статья дня

С чего начать построение своего веб-секвенсора?

Конечно же с изучения Web Audio и Web Midi API!

Статья Мэдса Стоуманна рассказывает не только о том, как сверстать свою MIDI-клавиатуру и потыкать в неё мышкой, чтобы послушать звуки, но и как подключить настоящую MIDI-клавиатуру и даже подсветить аккорды: https://blog.logrocket.com/exploring-web-audio-api-web-midi-api/

Ну и, конечно, сразу демо: https://codepen.io/stoumann/pen/ZEjjyEp

Есть у кого MIDI-синтезатор, кстати? Делитесь результатом!

#web #audio #grid #music

#фишка дня

Голубые галочки захватывают мир! Теперь и в вашей почте, котаны.

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

Это называется BIMI: Brand Indicators for Message Identification и каждая компания может получить такой. Достаточно простого советского...

1. Логотип компании должен быть зарегистрированной торговой маркой. Не у всех это так, кто бы мог подумать.
2. Необходимо получить сертификат VMC. Процесс аналогичен получению сертификата SSL.
3. После логотип и сертификат вписываются в TXT-запись DNS, вроде:
default._bimi TXT "v=BIMI1; l=https://example.com/image.svg; a=https://example.com/image/certificate.pem"
4. ...
5. Вы великолепны и сверкаете голубой галочкой. В GMail и Apple Mail точно, дальше — больше.

В будущем требование регистрации торговой марки уберут, но вот сертификат всё равно получать придётся.

Пните своих CMO, котаны.

#web #bimi #logo #email

#статья дня

TIL, что браузерам можно указывать на приоритет сетевых операций: в fetch, в загрузке картинок, и в загрузке скриптов.

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

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

Или какие-то картинки чуть более важные, чем другие. Хотелось бы иметь возможность отложить их загрузку, даже если браузер хочет решить иначе.

Для этого у нас есть свойство priority в методе fetch, атрибут fetchpriority для изображений и async и всё тот же fetchpriority в загрузке скриптов.

А подробнее в статье Алекса МакАртура: https://www.macarthur.me/posts/priority-hints

Пока только в Chrome и уже очень скоро в Safari: https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-178#Web-API

#fetch #priority

#ссылка дня

«Что происходит когда ты набираешь google.com в адресной строке браузера и жмёшь ввод?»

Да, котаны, вы угадали: это довольно популярный вопрос на собеседованиях.

Если у тебя его не спрашивали, значит, предполагается, что ты знаешь ответ.

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

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

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

Вот: https://github.com/alex/what-happens-when

Официального перевода на русский нет, но есть PR: https://github.com/alex/what-happens-when/pull/1462/files

Как вы думаете, котаны, имеет ли смысл в 2023 году вообще такое спрашивать? Должен ли условный фронт это понимать?

#web #interview

#статья дня

С чего начать построение своего веб-секвенсора?

Конечно же с изучения Web Audio и Web Midi API!

Статья Мэдса Стоуманна рассказывает не только о том, как сверстать свою MIDI-клавиатуру и потыкать в неё мышкой, чтобы послушать звуки, но и как подключить настоящую MIDI-клавиатуру и даже подсветить аккорды: https://blog.logrocket.com/exploring-web-audio-api-web-midi-api/

Ну и, конечно, сразу демо: https://codepen.io/alinaki/pen/jOdeqRv

Есть у кого MIDI-синтезатор, кстати? Делитесь результатом!

#web #audio #grid #music #бородач

#заметка дня

Рубрика "Вы не спрашивали, но я всё равно отвечу!"

На самом деле, разговор произошёл в Твиттере, и я посчитал разумным, вынести его сюда.

Итак, вопрос:
Что бы убедиться: использование testid в end-2-end тестах для выборки элементов это анти-паттерн, верно? Следует тестировать с точки зрения пользователя: искать кнопку с неким текстом, например.

Знаете ли вы статьи или доклады, которые подкрепляют эту точку зрения?

Отвечаю:
Это не то чтобы антипаттерн, это просто бестолковое использование ресурсов, потому и продвигается как антипаттерн.

1. Надо тестировать то, что видит юзер
2. Если что-то не видит, значит, всё плохо
3. Если там иконка или нужен результат — искать надо по a11y атрибутам.

Сразу поясню за "бестолковость".

Когда ты что-то тестируешь, тесты становятся твоей документацией. Значит, в тестах закрепляется текущее поведение проекта. Даже строки не стоит импортировать (если ты только не тестируешь систему перевода).

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

Дальше, решая проблему через ARIA-атрибуты, ты заодно решаешь вопрос доступности. Бесплатно. Поэтому data-testid и названы бестолковым использованием ресурсов.

Это же, кстати, касается систем трекинга вроде Datadog RUM.

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

Подобный подход к тестировани применяется как в E2E, так и в юнит- и интеграционном тестировании. Вот, например, поясняющая статья от Testing Library, которая нынче стандарт де-факто для тестирования в вебе.

Тестируйте, котаны!

#web #testing #e2e

#новость дня

Посмотрите на иллюстрацию. Ничего интересного не замечаете?

А здесь происходит ого-го какая драма!

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

Если коротко, есть такой чувак, Андреас Клинг. Долгое время он работал над движком WebKit в Nokia, а потом и над браузером Safari в Apple. А потому немного... в общем, оказался в центре реабилитации.

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

И вот, разрабатывая просмотровщик HTML-документации, ребята случайно написали браузер. И так получилось, что браузер стал развиваться быстрее чем материнский проект.

И месяц назад Андреас решил, что будет заниматься только им, выпустив соответствующее уведомление.

И вот тут началось самое интересное. Все так наелись монополии Google, что новость взлетела с дикой скоростью. Казалось бы, зачем нам ещё один движок и тем более — браузер? Но запрос есть. Начиная от энтузиастов, заканчивая слабомощными машинами и телевизорами.

В общем, пару дней назад стало известно, что в некоммерческую организацию, созданную под Ladybird, инвестировали 1 миллион долларов. И не кто иной, а Крис Ванстрат.

Не знаете, кто это? А это сооснователь GitHub. И он не один такой. Shopify тоже в спонсорах.

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

И пусть он пока не умеет всего, что умеет Chrome, я верю в его светлое будущее.

#web #browser #ladybird

#фишка дня

Как-то так получилось, что на мобильных устройствах работать с файлами и буфером обмена ну... неудобно.

И ладно iOS, но на Android тоже интерфейсы такие себе. Даже на Windows Mobile и PalmOS было как-то... стандартнее чтоль.

С другой стороны, появилась идея шэринга, aka share. И она на самом деле отвечает запросам людей: перекинуть файл из одного приложения в другое, а что нам ещё нужно-то?

Итак, встречайте: Web Share API.

Пользоваться очень просто:

navigator.share({
  title: "Будни разработчика",
  text: "Фронтенд и не только",
  url: "https://yangx.top/htmlshit",
});

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

navigator.share({
  files: [file],
  title: 'hello.png'
});

На десктопе, к сожалению, не работает. Но там у нас иные средства имеются.

#web #share #api

#статья дня

С чего начать построение своего веб-секвенсора?

Конечно же с изучения Web Audio и Web Midi API!

Статья Мэдса Стоуманна рассказывает не только о том, как сверстать свою MIDI-клавиатуру и потыкать в неё мышкой, чтобы послушать звуки, но и как подключить настоящую MIDI-клавиатуру и даже подсветить аккорды: https://blog.logrocket.com/exploring-web-audio-api-web-midi-api/

Демо: https://codepen.io/stoumann/pen/ZEjjyEp

Есть у кого MIDI-синтезатор, кстати? Делитесь результатом!

#web #audio #grid #music #бородач

#статья дня

Я давно такого удовольствия не получал. Технических знаний много не требуется, но при этом погружение в кишки браузеров и формат GIF с головой.

Это я об этом: https://www.biphelps.com/blog/The-Fastest-GIF-Does-Not-Exist

Правда, буду честен, я читал в переводе на хабре: https://habr.com/ru/post/676480/

Потому что циановый фон блога, где размещён оригинал, это какой-то ад… но сути дела не меняет.

Итак, в чём же история? История в том, что все браузеры и все программы просмотра GIF на свете совершенно неверно обрабатывают задержку между кадрами. Да так, что даже лишают нас многих возможностей формата.

Точнее, на всё есть свои причины. Исторические в основном. Chrome кивает на Firefox, тот на IE, тот на Netscape… беда.

И всё это снабжено, собственно, примерами кода. Прям как в двигателе покопался.

#gif #img #web #бородач

#фишка дня

Как-то так получилось, что на мобильных устройствах работать с файлами и буфером обмена ну... неудобно.

И ладно iOS, но на Android тоже интерфейсы такие себе. Даже на Windows Mobile и PalmOS было как-то... стандартнее чтоль.

С другой стороны, появилась идея шэринга, aka share. И она на самом деле отвечает запросам людей: перекинуть файл из одного приложения в другое, а что нам ещё нужно-то?

Итак, встречайте: Web Share API.

Пользоваться очень просто:

navigator.share({
  title: "Будни разработчика",
  text: "Фронтенд и не только",
  url: "https://yangx.top/htmlshit",
});

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

navigator.share({
  files: [file],
  title: 'hello.png'
});

На десктопе, к сожалению, не работает. Но там у нас иные средства имеются.

#web #share #api #бородач

#статья дня

TIL, что браузерам можно указывать на приоритет сетевых операций: в fetch, в загрузке картинок, и в загрузке скриптов.

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

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

Или какие-то картинки чуть более важные, чем другие. Хотелось бы иметь возможность отложить их загрузку, даже если браузер хочет решить иначе.

Для этого у нас есть свойство priority в методе fetch, атрибут fetchpriority для изображений и async и всё тот же fetchpriority в загрузке скриптов.

А подробнее в статье Алекса МакАртура: https://www.macarthur.me/posts/priority-hints

Пока только в Chrome и Safari с версии 17.2: https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-178#Web-API

#fetch #priority #бородач

#инструмент дня

Наткнулся на тред Андрея Романова про мониторинг крашей. Публикуется с изменениями.

Не тех крашей, что с чёлкой, а крашей браузера. Падений на ровном месте.

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

Зато Chrome нарисует симпатичную графику, очень полезно.

Однако, есть экспериментальный Reporting API, который позволяет браузеру отправлять отчёты о сбоях, нарушениях политик безопасности и использовании устаревших функций:
🔗 Спецификация API: https://w3c.github.io/reporting/
🔗 Обзор на Chrome for Developers: https://developer.chrome.com/docs/capabilities/web-apis/reporting-api

Reporting API предоставляет два способа получения отчётов:

📌 Глобальный класс ReportingObserver — позволяет подписаться на предупреждения и обрабатывать их в JavaScript. Он не фиксирует падения, так как работает на клиенте.
📌 HTTP-заголовок Reporting-Endpoints — задаёт серверные эндпойнты, на которые браузер отправляет отчёты. Этот метод покрывает все виды ошибок, включая падения вкладки.

Хотя API остаётся нестабильным и реализован не во всех браузерах, у него нет аналогов. Например, Figma уже использует его для мониторинга крашей браузера:
🔗 Разбор использования в Figma: https://neugierig.org/software/blog/2023/01/browser-crashes.html

Лучше так, чем совсем не иметь :)

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

Ну и, как минимум, средства вроде Sentry и Datadog отлично справляются с трекингом ошибок, по которым тоже можно косвенно понять причину падения.

#web #crash #report

#ссылка дня

А как сделать кнопку? А как тулбар? А как сверстать несколько колонок с перекрытием? А если мне анимации стандартные не подходят?

Ни слова больше! Google has us covered!

https://web.dev/patterns/

От простых вещей вроде кнопки или описания кривой Безье для анимации до загрузки файлов, работы с буфером обмена и превращения сайта в PWA.

Хотелось бы больше примеров, конечно, но кому не хочется? :)

#web #app #patterns #бородач

#заметка дня

Рубрика "Вы не спрашивали, но я всё равно отвечу!"

На самом деле, разговор произошёл в Твиттере, и я посчитал разумным, вынести его сюда.

Итак, вопрос:
Что бы убедиться: использование testid в end-2-end тестах для выборки элементов это анти-паттерн, верно? Следует тестировать с точки зрения пользователя: искать кнопку с неким текстом, например.

Знаете ли вы статьи или доклады, которые подкрепляют эту точку зрения?

Отвечаю:
Это не то чтобы антипаттерн, это просто бестолковое использование ресурсов, потому и продвигается как антипаттерн.

1. Надо тестировать то, что видит юзер
2. Если что-то не видит, значит, всё плохо
3. Если там иконка или нужен результат — искать надо по a11y атрибутам.

Сразу поясню за "бестолковость".

Когда ты что-то тестируешь, тесты становятся твоей документацией. Значит, в тестах закрепляется текущее поведение проекта. Даже строки не стоит импортировать (если ты только не тестируешь систему перевода).

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

Дальше, решая проблему через ARIA-атрибуты, ты заодно решаешь вопрос доступности. Бесплатно. Поэтому data-testid и названы бестолковым использованием ресурсов.

Это же, кстати, касается систем трекинга вроде Datadog RUM.

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

Подобный подход к тестировани применяется как в E2E, так и в юнит- и интеграционном тестировании. Вот, например, поясняющая статья от Testing Library, которая нынче стандарт де-факто для тестирования в вебе.

Тестируйте, котаны!

#web #testing #e2e #бородач