Классные анимации

Понравилась статья Эмиля Ковальски про то, чем отличаются посредственные анимации от классных анимаций. Откликается.

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

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

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

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

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

6. Классные анимации — доступные. Не забывайте, что есть люди, которым физически неприятно видеть некоторые виды движения. Уважайте настройки их системы.

7. Классные анимации сделать тяжело. Нужно приложить усилия. Но оно того стоит.

https://emilkowal.ski/ui/great-animations

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

Видео выходного дня. Олег Федоткин погружается в то, как приносить крупные инновации в большие компании. Мысли, которые захотелось записать:

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

- Эффективность и продуктивность ≠ работа «туда». Можно продуктивно заниматься ерундой.

- Внедрять изменения нужно не к дате и директивно, а к результату и для чего-то. Объяснять «что-то» важно всем участникам процесса.

- Top-Down инновация, когда изменения идут с самого верха структуры компании, похожа на скалу, о которую бьются волны. Чем больше уровней в компании, тем хуже такой подход работает.

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

- Для диффузии инноваций важно внедрять новое постепенно, ориентируясь на инноваторов и ранних адоптеров, которые сами в случае полезного внедрения сарафанным радио повлияют на остальных участников внедрения. Инноваторы любят что-то новое, чего нет у остальных. Это как Apple Vision Pro, который по сути своей пока бесполезен, но техноблогеры всё равно его хотят.

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

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

- Соберу-ка я список инноваторов вокруг себя, чтобы через них эффективнее внедрять новое.

https://youtu.be/7HKJf7HGnTY

Адаптивные графики на HTML и CSS

Матиас Шафер делится тем, как из бар-чартов (диаграммы с горизонтальными полосками, их ещё горизонтальными гистограммами называют) на SVG получилось сделать адаптивный вариант на HTML и CSS. Причём это хороший пример для полезного применения многострадальных сабгридов.

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

- Адаптивность реализуется довольно просто, достаточно переписать пару свойств по разметке грида.

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

- При желании любое значение можно особым образом выделить, так как это обычный CSS. Добавил класс на ряд — и вот уже очень важное значение на графике выглядит тоже очень важно.

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

- Я бы добавил чуть больше математики на calc и CSS-переменных, чтобы ещё меньше писать лишнего в самом HTML. Прям просится в демках поправить.

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

- При желании такой же подход можно применить и к колоночным диаграммам. Или даже превращать их в горизонтальные гистограммы, когда экран маленький, а колонок много.

Хороший пример для вдохновения, чтобы с чего-то начать и доработать под себя.

https://9elements.com/blog/responsive-bar-charts-in-html-and-css/

Клавиатурная навигация для CSS-игры

Темани Афиф продолжает удивлять. На этот раз он показывает по шагам, как на HTML и CSS сделать игру, которая работает с кнопками-стрелками на клавиатуре для передвижения персонажа по экрану. В демке Марио собирает монетки на время и уклоняется от гумб.

1. Стрелки меняют положение скроллбара в контейнере. То есть если у нас есть большой контейнер со скроллбарами, мы можем как-то реагировать на стрелки, если скроллбар двигается.

2. Свежее свойство animation-timeline: scroll(neasert inline), scroll(nearest block); позволяет привязать анимацию к положению скролла. То, что нам нужно.

3. Прячем сами скроллбары через scrollbar-width: none;.

4. Размечаем кифреймы по каждой оси, чтобы получить нужные нам позиции монеток. В нужных кадрах выставляем значения CSS-переменных в 1 как признак того, что та или иная монетка собрана.

5. Используем Style Queries @container style(...), чтобы менять холст под значения переменных.

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

7. Так как игра на скроллбарах, управление мышкой получаем из коробки.

Жду, когда Doom запустят на HTML+CSS и таких вот хаках. Кажется, недолго осталось.

https://frontendmasters.com/blog/how-keyboard-navigation-works-in-a-css-game/

Speculation Rules API для View Transition

Недавно браузеры начали у себя активно внедрять View Transition API для многостраничных сайтов, а не только SPA. Но у подобной красоты есть минус — браузер реально что-то рисует относительно поздно, прогрессивный рендеринг уже не работает.

Райан Седдон показывает, как при помощи ещё одного API, Speculation Rules API, ускорить показ красоты. Добавляете на страницу специальные правила, и браузер по ховеру уже через 200мс попытается отпререндерить будущую страницу. Это, конечно, даёт лишнюю нагрузку на сервера, но зато пользователь увидит то, что ему нужно, раньше.

https://ryanseddon.com/web/view-transitions-speculative/

Как собрать сложное расширение для Chrome

Нина Торгунакова в блоге Злых Марсиан по шагам собирает расширение для работы с сервисом Playbook. Сначала добавляет OAuth-авторизацию, пишет сам скрипт для сохранения медиа в локальное хранилище, затем добавляет пункт в контекстное меню браузера, обработку ошибок. И готовит расширение для публикации в Chrome Web Store.

Часто использую статьи марсиан как инструкции. Эта уже в закладках на случай, если захочу опубликовать какое-нибудь расширение.

https://evilmartians.com/chronicles/how-to-make-complex-chrome-plugins-a-zero-gravity-guide

Верстаем в прямом эфире

Точнее, верстать будет Полина Гуртовая, помогать ей будет Алёна Батицкая, а я буду давать комментарии. Решать будем задачи на вёрстку, которые я собирал для своей подборки на CodeRun.

Всё это состоится 18 июля в 20:00 по Минску. Приходите советовать советы и спрашивать вопросы в комментариях к стриму 🙂

https://news.1rj.ru/str/doka_guide/161

Разные способы спрятать что-то в DOM

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

1. Свойство display: none. Прячет элемент полностью, контент элемента не читается скринридерами.

2. Атрибут [hidden]. Почти как display: none, только в HTML. Крис не пишет про это, но [hidden] легко теряет свою визуальную спрятанность, если поверх выставить display: block.

3. Свойство visibility: hidden. Прячет элемент, но оставляет вместо него пустое пространство. Контент элемента не читается скринридерами.

4. Класс .visually-hidden. Популярный набор свойств, которые заставляют элемент занимать нулевое пространство на странице, то есть быть визуально невидимым, но при этом оставляют содержимое читаемым скринридерами.

5. Атрибут [aria-hidden="true"]. Прячет содержимое от скринридеров, не влияет на визуальное отображение.

Статья Криса Фердинанди:
https://gomakethings.com/the-many-ways-to-hide-things-in-the-dom/

А ещё есть хорошая статья про прятание содержимого от скринридеров у Доки:
https://doka.guide/a11y/content-hidden/

Подводные камни In-app браузеров

Когда вы открываете ссылки в каких-нибудь нативных приложениях соц. сетей, они часто норовят открывать даже не WebView, а какую-то свою обёртку над WebView, которая имеет полный контроль над вашей страницей. Поль Эш-Лоран объясняет, почему такие обёртки — зло.

1. У них меньше функций, чем у браузеров. Просто потому, что операционные системы в принципе ограничивают WebView из соображений приватности и безопасности.

2. В In-app браузерах у вас вообще нет контроля над собственным кодом. Если какой-нибудь Cakebook решит вставить туда свой скрипт для «улучшения пользовательского опыта», то вы ничего с этим сделать не сможете.

3. Неконсистентный для пользователя UI/UX. Дизайнеры таких браузеров считают важным сделать что-то «удобнее оригинала», но забывают, что в основном пользователи сидят именно в обычных браузерах, поэтому там привычно. А сила привычки очень велика.

В 2022 году был скандал вокруг того, что Meta добавляет отдельный скрипт на каждую открываемую веб-страницу в своих приложениях, который отслеживает буквально каждое мельчайшее действие на странице. К сожалению, в 2023 году дело против Meta по этому кейсу было закрыто. TikTok делает так же. И не только они. Недавно Twitter/X зачем-то стал открывать страницы в первый раз в какой-то поделке, похожей на браузер, а во второй раз — в WebView.

Так и что с этим делать? Мы не контролируем собственные сайты?

В статье предлагается посмотреть на https://inappbrowser.com/ и https://inappdebugger.com/, которые помогают детектить, открывается сайт в обычном браузере или в In-app браузере. Плюс показывают код, который был внезапно вставлен на страницу извне.

Для Android можно использовать префикс intent: в ссылках. Так операционная система будет понимать, что вы хотите открыть именно дефолтный браузер в системе, а не In-app.

Также для любых ОС, если вы хотите сберечь пользовательские данные, можно задетектить, что страница открыта в In-app браузере, и вывести для пользователя инструкцию, как открыть страницу в нормальном браузере. Увы, требует дополнительной разработки, причём поди ещё угадай, какую инструкцию составить. Тот же Twitter очень дерзко в своём In-app браузере в принципе не даёт опции открыть в дефолтном браузере.

https://frontendmasters.com/blog/the-pitfalls-of-in-app-browsers/

Стилизация таблиц современным CSS

Мишель Баркер показывает, как стилизовать таблицы, не меняя в них display. Всё чаще вижу примеры, где таблицы переделывают на гриды, потому что так удобнее с ними работать и при необходимости переделывать на узких экранах в карточки. Но иногда таблицы — это просто таблицы.

- border-collapse: collapse схлопывает границы ячеек в одну общую.
- <thead> и <tfoot> — полезные элементы, чтобы выделить заголовочный ряд и ряд «Итого».
- У таблиц есть <caption> — подпись к таблице. И её можно двигать при помощи caption-side: bottom.
- Чтобы научить таблицу уважать задаваемые ширины колонок, нужно задать ей свойство table-layout: fixed.

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

https://piccalil.li/blog/styling-tables-the-modern-css-way/

Фронтенд 2024: тренды, CSS, доступность, браузерные API

Сходили с Глашей Жур в подкаст к Хекслет, поболтали про всякое разное, связанное с вебом. Заодно поговорили о том, что нужно знать новичкам в профессии, чтобы выделяться среди других.

https://youtu.be/9I1g06XSYZk

Typenoscript теперь и в Node.js?

В свежем выпуске мы затронули нашумевший PR. Что случилось то? А случилось такое, что в Node.js подвезли в экспериментальном режиме загрузчик для ts файлов. Работает он очень просто (правда просто). В ноду вшивается SWC в виде скомпиленного для WASM бинаря. TS файлы прогоняются через SWC и из них отстреливаются типы. Всё. Enum и namespace не работают (о счастье). Никакие транспиляции трансформации не производятся. Просто отстреливаются типы.

Есть ли проблемы? Конечно есть. Например, нужно писать расширение файлов в импортах. Потому что импорт так работает бай дизайн.

Почему это круто и важно? Потому что транспиляция раздражает. Потому что хочется всё иметь из коробки и без настроект. Накидать ts-файлик и запустить.

В общем, неожиданно и очень приятно.

Кастомное сообщение при подключении ESM через require

Если попытаться подключить ESM-пакет внутри CommonJS, Node.js выдаст вам ошибку. По ней, в принципе, достаточно понятно, что надо что-то поменять, но Зак Лезерман делится рецептом, как выдать кастомное сообщение, если ваш пакет уже не поддерживает CommonJS.

Для начала нужно попросить Node.js использовать разные файлы для разных способов импорта, внутри package.json пакета.

{
 "type": "module",
 "main": "./lib.js",
 "exports": {
  "import": "./lib.js",
  "require": "./libCommonJs.cjs"
 }
}

А затем внутри cjs-файла осознанно упасть.

try {
 module.exports = require("./lib.js");
} catch (e) {
 if(e.code === "ERR_REQUIRE_ESM") {
  throw new Error("Oops. It's not the module you are looking for.");
 }
 throw e;
}

Как верно замечает Зак, Node.js планирует скоро сделать так, чтобы внутри require можно было загружать и ESM-модули (с некоторыми ограничениями), так что лайфхак временный.

https://www.zachleat.com/web/future-friendly-esm/

Сборщик мусора и замыкания

Джейк Арчибальд делится интересным кейсом, в котором неожиданно в JavaScript утекает память.

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  (() => {
    console.log(bigArrayBuffer.byteLength);
  })();

  globalThis.innerFunc = () => {
    console.log('hello');
  };
}

demo();

Несмотря на то, что innerFunc никак не связана с bigArrayBuffer, bigArrayBuffer не удаляется из памяти посе выполнения этого кода.

Подробнее в статье.

https://jakearchibald.com/2024/garbage-collection-and-closures/

Причины, почему JavaScript может не работать

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

1. Браузерное расширение может сломать JS на сайте. Сам с таким сталкивался, когда блокировщики рекламы творили дичь.
2. Политики безопасности (например, в компании), которые тупо вырубают некоторые домены или расширения файлов.
3. Блокировка CDN, например, потому что РКН или другие «регуляторы».
4. Скрипт не загрузился, потому что пользователь в метро.
5. Банальная ошибка в JS-коде, которая всё ломает.
6. Opera Mini.
7. «Умный» инкогнито-режим в Safari, который иногда сам решает отключить некоторые скрипты.
8. У пользователя слабое устройство, которому не хватает памяти обработать ваш JS.
9. Пользователь осознанно выключил JS, чтобы за ним не следили.

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

https://piccalil.li/blog/a-handful-of-reasons-javanoscript-wont-be-available/

MinskCSS Meetup #12

Сегодня вечером проводим очередной онлайн-митап для фронтендеров, где обсудим с классными спикерами всякое интересное:

- Алексей Назаренко объяснит особенности Shadow DOM, связанные с изоляцией и стилями.

- Глафира Жур расскажет, что есть полезного в мире AI для accessibility.

- Юлия Миоцен покажет, как моделировать и анимировать настоящего 3D-персонажа на CSS.

Программа митапа: https://telegra.ph/MinskCSS-Meetup-12-07-29
Трансляция на YouTube: https://www.youtube.com/watch?v=-s7s_IB2egc

Снова никакой регистрации. Просто приходите в 19:00 по минскому времени. Всех ждём 🙂

Подкаст «Гости из IT». Олимпиадное программирование

Сходил в гости в подкаст с Антоном Комоловым «Гости из IT», где вместе с тренером чемпионов мира ICPC Михаилом Густокашиным обсудили с ведущими подкаста, что такое олимпиадное программирование, полезно ли оно в работе, даёт ли это какие-то преимущества в трудоустройстве и может ли ИИ победить чемпиона мира по программированию.

Мало кто знает, но в школе я занимался олимпиадным программированием, доходил до областного этапа олимпиады по информатике, постоянно брал там дипломы II степени. А в университете мне повезло быть в рабочей группе организаторов первых чемпионатов по программированию BSUIR Open, который до сих пор пользуется уважением в олимпиадном сообществе. Ну а сейчас я руковожу сервисами, которые помогают проводить контесты и соревнования. Было приятно поностальгировать.

https://podcast.ru/e/599XsTl4qNW

Официальная поддержка Firefox в Puppeteer

Для автоматизации тестирования в браузере всё чаще вместо Selenium используют Playwright или Puppeteer. Удобно, когда можно поднять реальный браузер в «безголовом» режиме и тестировать страницу ровно такую, какую «видит» пользователь.

Чисто субъективно мне всегда по функциям и обилию API больше нравился Puppeteer. В нём как минимум есть классная возможность генерировать PDF с большим количеством настроек. Но при этом по сути Puppeteer всегда был под капотом Chrome. А мне важна кроссбраузерность. У пользователей Firefox сайт тоже должен работать.

Начиная с Puppeteer 23 тестировать кроссбраузерно станет проще, там появляется официальная поддержка Firefox. Не все API работают, список можно посмотреть в статье, но большую часть потребностей закрывает.

https://hacks.mozilla.org/2024/08/puppeteer-support-for-firefox/

Как Google обрабатывает JavaScript во время индексации

Есть несколько мифов по поводу того, как Google индексирует SPA-приложения. Например, что боты-краулеры не умеют в JavaScript совсем. Или что для обхода сайтов Google использует древние версии Chrome. И другие.

Беда в том, что у Google нет ни одной полной странички с документацией, как именно поисковик обходит сайты и как краулеры эти самые сайты загружают, обрабатывают и индексируют. И даже та документация, что есть, не даёт полного понимания, что сделать, чтобы бот точно всё распарсил правильно. Оно и понятно: зная точную механику, можно стать повелителем SEO.

Vercel вместе с MERJ провели эксперимент, обложив 100000 запросов от гуглобота разными замерами. Как именно они это сделали, лучше посмотреть в статье, есть даже примеры кода. И получили они такие знания:

1. Googlebot отлично справляется с любым JavaScript. Синхронным, асинхронным, из фреймворков.

2. Рендерит он только страницы с HTTP-кодами 200 и 304. Остальные коды не рендерит в принципе. Поэтому не забывайте отправлять корректные коды ошибок на страницы, это влияет на позиции в выдаче.

3. Googlebot умеет находить ссылки внутри JavaScript, не только в HTML. Причём смотрит он именно на готовые ссылки, не encoded URL.

4. Наличие sitemap.xml значительно ускоряет обработку ботом, что изменилось на сайте. То есть если вы боретесь за актуальность ссылок в поисковой выдаче, на sitemap.xml надо обратить внимание в первую очередь.

5. Метатег noindex работает. Но только если он пришёл в HTML, а не вставился при помощи JavaScript уже на клиенте. Если вы прячете странички от индексации уже на клиенте — это не работает, нужно уносить логику на сервер.

6. Тяжёлые страницы с большим количеством JavaScript краулятся медленнее, могут долго висеть в очереди. Поэтому перфоманс страницы всё-таки влияет на SEO.

7. Если в robots.txt запретить нечаянно доступ к папкам со скриптами и другими ассетами, они не загрузятся. Проверьте свой robots.txt, нет ли там чего-нибудь лишнего.

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

https://vercel.com/blog/how-google-handles-javanoscript-throughout-the-indexing-process

Генератор пружинистого изинга

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

Анимации сделаны на функции linear(), так что не забудьте убедиться, что ваша браузерная поддержка в проекте позволяет ими пользоваться.

https://www.kvin.me/css-springs

Браузерное расширение Resource Override для фронтендеров

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

В Chrome и Safari есть возможность подменять файлы на уровне DevTools. Но динамику так не протестировать, к тому же каждый отдельный файл подменять, когда хочется подменить целую папку, муторно.

Марио Хаманн делится браузерным расширением, которое работает как прокси. Если вам нужно подменить обращения к каким-нибудь ресурсам по маске, оно умеет подменять на другие ресурсы с сохранением этой самой маски.

А ещё при помощи этого расширения можно «патчить» чужие сайты в Интернете.

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

https://mariohamann.com/resource-override-for-frontend-development