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

Мне кажется, счётчики — фича в 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

Исследование о настройках доступности

Всегда радуюсь, когда большие компании делятся статистикой, как пользуются их приложениями. Проект «Инклюзия» делится результатами исследования, какие настройки доступности стоят у пользователей мобильного Яндекс.Браузера (для iOS и Android). Веб-разработчикам эти данные полезны как минимум для того, чтобы обосновывать, почему всё-таки стоит добавить ту или иную фичу, связанную с A11Y.

1. 35% пользователей увеличивают размер шрифта в системе или браузере. Колоссальные числа. Тут и возрастные проблемы со зрением, и тенденция на ухудшение зрения в любом возрасте, и в целом некоторые версии операционных систем с издевательским размером шрифта по умолчанию. По сути для нас это означает, что:
- Если видите дизайн, в котором все сделано 12 шрифтом — покажите дизайнеру это исследование. Может, дизайн и красивый, но удобство важнее. 35% пользователей не оценят.
- Вёрстку обязательно нужно тестировать с увеличенным размером шрифта. По-хорошему — прямо автотестами.
- Нельзя запрещать изменение шрифта в приложении. Иначе можно банально потерять огромную часть аудитории. Думаю, между красотой и потерянными деньгами бизнес выберет деньги. И хорошо, что браузеры относительно давно не дают запрещать менять размеры через тег meta.

2. Тёмной темой пользуется 27% пользователей. Тут можно поспорить, делают это потому, что светлая тема ночью неудобна или просто из эстетических соображений. Но это всё равно говорит о том, что у пользователя есть какое-то ожидание. Не соответствуешь ожиданиям — конкурентов много, до свидания.
- Проектируйте дизайн сразу с учётом наличия светлой и тёмной темы. Если есть дизайн-система — вообще хорошо. Если нет — ну хотя бы ленивую инверсную тему продумайте. Решений в опенсорсе хватает.
- prefers-color-scheme — добавьте в CSS, это ваш друг.
- Да, придётся продумать и автотесты на тёмную тему. Причём тоже лучше делать это со старта, чтобы потом не вкостыливать хитровывернутый способ включить тёмную тему в тестах.

3. Анимацию отключают 5% пользователей. Точнее, они просят отключить. Я, кстати, знаю людей, у которых нет никаких ограничений по здоровью, связанных с мельтешением. Им просто не хочется видеть анимации.
- prefers-reduced-motion — добавьте прямо сейчас, выключите плавный скролл, продолжительность переходов и анимаций поставьте в 0s.
- Через JS тоже можно отслеживать медиавыражения, не сдерживайте себя.

4. 2% пользователей увеличивают контраст. Тут я был немного удивлён, всё-таки это довольно много. Но тоже подсвечивает, что проще сделать сразу нормальную контрастность на сайте (есть плагины для Фигмы, есть проверки в девтулзах браузера), чем потом пытаться починить. Ну и в целом летом на солнце с бликами любой неконтрастный сайт уходит далеко и надолго, конкурентов, опять же, как правило хватает.

5. 6% пользователей пользуются возможностью прочитать текст на экране средствами браузера. Браузер не умеет в магию. Если разметка сделана плохо, прочитает текст он плохо. Поэтому видимый текст тоже нужно оформлять корректно. И точно не заменять его картинками.

6. 2% пользователей включают «живые субтитры». Это когда даже если у видео нет субтитров в принципе, браузер всё-таки при помощи AI и прочего распознования речи эти субтитры генерирует.
- Автоматическое распознавание речи делает ошибки, поэтому если вам важно, чтобы текст не искажался по смыслу, лучше добавить правильные субтитры самим.

7. На iOS есть функциия потрясти смартфоном для отмены действия. 5% пользователей её выключают.

8. У 51% пользователей включена хотя бы одна настройка доступности. Пусть потом кто-нибудь скажет, что доступность не нужна.

Лендинг исследования — https://inclusion.yandex.ru/settingsresearch
Само исследование в PDF — https://disk.yandex.ru/i/D1RLUIPJmVBPzg

Приходите в субботу 16 декабря в 12:00 (UTC+3) на стрим подсмотреть как мы записываем 400-й эпизод Веб-стандартов вживую и обсуждаем новости фронтенда за неделю. Обычный эпизод, ничего такого 🤓

https://youtube.com/live/-QyzkZ0sHRA

isolation: isolate

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

Допустим, у вас по какой-то причине есть необходимость в z-index: -1. В статье для примера приводится оформительская кавычка для цитаты, которая вставляется фоновой картинкой в карточку через псевдоэлемент ::before. Вполне логично, что если выставить z-index: -1 на ::before, то он поместится под карточку. Можно пойти дальше и поставить на контент карточки z-index: 1. Но так можно дойти до z-index: 9999, а там и до z-index hell рукой подать.

В CSS есть механизм, который в оригинале называется Stacking context (контекст наложения?). По сути это такая изолированная коробочка, внутри которой z-index работает, не глядя на другие коробочки. И есть много способов создать этот самый контекст. Но как правильно пишет в статье Франческо, почти все способы приносят с собой сайд-эффекты. Чаще всего я встречал transform: translateX(0), который может повлиять на рендеринг текста, например.

Так вот, есть замечательное свойство isolation: isolate, вся суть которого — создать контекст наложения. И всё. Без сайд-эффектов. Работает с 2015 года во всех браузерах.

Прошёлся по нескольким крупным сайтам с тултипами и попапами. Там в CSS встречается больше сотни z-index на страницу, но ни одного isolation. Видимо, не я один про него забываю.

https://dev.to/francescovetere/the-css-property-you-didnt-know-you-needed-3fk0

Атрибут form

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

Но при этом хочется сделать семантично. В том числе для того, чтобы сработал фолбек, ведь если JS отвалится, то хотя бы атрибут method у формы поможет отправить данные на сервер. Как быть?

В статье Александр Музенхардт напоминает про атрибут form, который отлично работает на многих элементах формы. Туда достаточно написать id самой формы, а браузер сам свяжет инпут и форму, даже если форма не является родителем инпута. Очень удобно. Причём атрибут настолько древний, что работает буквально почти везде.

<form action="/login" method="get" id="form-login"></form>

<button type="reset" form="form-login">Reset</button>

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

Кстати, на сайте htmhell.dev сейчас каждый день выходит по одной статье про хорошие и плохие практики HTML, адвент-календарь. Рекомендую.

https://www.htmhell.dev/adventcalendar/2023/3/

Веб-компонент снежинок для сайта

Пятничное предновогоднее.

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

<noscript type="module" src="snow-fall.js"></noscript>
<snow-fall></snow-fall>

Единственное, что я бы добавил — это обработку prefers-reduced-motion. Компонент маленький, доработать несложно: можно детектить настройку как через JS, так и через CSS.

https://www.zachleat.com/web/snow-fall/

LanguageTool

Подсмотрел в твиттере у Андрея Ситника, что он пользуется для проверки текстов сервисом LanguageTool. Сам пользуюсь пару недель, решил тоже с вами поделиться.

Что нравится:
- Проверяет на грамматические ошибки и частично пунктуацию текст на разных языках. В постах в этот блог опечатки мне помогал находить, пару запятых расставил за меня.
- Умеет в разные версии одного языка. То есть британский и американский английский исправляет по-разному, проверял.
- Говорят, что ничего не хранят на серверах, если пользоваться браузерным расширением или клавиатурой. Проверить не могу, конечно, но заботу о приватности моих данных ценю.
- Бесплатного аккаунта для моих нужд хватает выше крыши.
- Есть функция перефразирования текста с помощью AI 3 раза в день. Работает, но проверить, круче ли, чем ChatGPT, не смог, потому что всего 3 раза в день.

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

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

https://languagetool.org/

Корректная конфигурация для preconnect

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

<link rel=preconnect href=https://fonts.googleapis.com>

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

Гарри Робертс разбирает пример, когда неправильная настройка таких подсказок только вредит. На сайте BBC находит 4 такие подсказки, которые не работают, и объясняет, почему. Рекомендую прочитать вдумчиво, в статье нужно смотреть в графики. Но несколько коротких советов можно выделить:

1. preconnect к ресурсам, которые на самом деле не нужны в первые 5 секунд загрузки приложения, вредят. Chrome держит соединение всего 10 секунд, при этом количество соединений ограничено.

2. Домены в href нужно писать с протоколом. Если https, то https://. Незачем давать браузеру думать, искать редиректы и применять эвристики.

3. Атрибут crossorigin может быть не нужен. Проверить можно в DevTools, подсмотреть у запроса за ресурсом заголовок Sec-Fetch-Mode. Если там стоит значение cors, то тогда атрибут crossorigin можно и добавить.

4. Если на одном и том же домене нужны ресурсы и с CORS, и без, то нужно прописать два отдельных <link rel=preconnect>, один с crossorigin, второй без. Этот атрибут влияет на куки, то есть заголовки запроса, поэтому по сути получается два разных запроса.

5. При переносе статики на другие домены-поддомены не забывайте про <link rel=preconnect>. Скорее всего у вас есть какая-нибудь функция-хелпер, в которую редко смотрят, потому есть вероятность просыпать домены при рефакторинге. Выносите домены в общий конфиг либо собирайте самое нужное непосредственно при сборке приложения, помечая как-то критические ресурсы в исходном коде по месту их загрузки.

https://csswizardry.com/2023/12/correctly-configure-preconnections/

Видео с MinskCSS Meetup 11

Делюсь отдельными видео с нашего недавно прошедшего митапа:
- Как играть, побеждать и учиться в CSS Battle / Тимофей Чаптыков
- 5 лучших практик, чтобы предотвратить хаос в Tailwind CSS / Нина Торгунакова
- OpenSource. Зачем тебе это надо и как начать / Егор Левченко

Плейлист целиком: https://www.youtube.com/playlist?list=PL3uk4LxG9ZznGCBLJZhifqjQoPQ-7-6zn

Prettier-плагин для void-элементов

В HTML есть void-элементы, вы их часто встречаете: <br>, <img>, <input>, <link>, <source> и так далее (вот тут можно посмотреть полный список). Это такие элементы, у которых не может быть дочерних DOM-узлов, в том числе текстовых.

А ещё в современном HTML нет самозакрывающихся тегов. Вот цитата с MDN:

Self-closing tags (<tag />) do not exist in HTML.

То есть когда я пишу <br /> — это ошибка, которую браузер за мной чинит. У Джейка Арчибальда есть статья про бесполезные слеши в HTML-тегах, мы её как-то активно в подкасте обсуждали.

Беда в том, что prettier, которым я всё-таки активно пользуюсь в React-проектах, очень не очень работает с обычным HTML. Конкретно с void-элементами работает плохо: расставляет те самые бесполезные слеши, придумывает какие-то новые самозакрывающиеся элементы вроде <div /> и так далее.

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

https://github.com/awmottaz/prettier-plugin-void-html

Итоги 2023 года в книгах

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

В прошлом году я ставил себе цель прочитать 20 книг, справился только с 12. В этом году решил здраво оценить свои возможности, поэтому поставил цель в 12 книг, а справился с 26. Вывод — я не умею оценивать свои возможности.

Итак, топ-5 из прочитанного за 2023 год по мнению доброжелюбного бородача:

5. Дарелл Хафф, «Как лгать при помощи статистики»
Я про неё писал уже в этом блоге. Хорошие примеры того, как можно красиво преподносить данные, чтобы они по-разному влияли на разную аудиторию. Как рисовать графики, которые как будто показывают правду, а на самом деле обманывают читателя. Как проводить статистические исследования, чтобы они давали нужный, а не правдивый результат. После этой книги любые графики теперь воспринимаю ещё скептичней, чем раньше.

4. Роберт Мартин, «Чистый Agile. Основы гибкости»
Классика. Дядя Боб рассказывает, как появился Agile, как с ним правильно работать и почему он на самом деле не противоречит многим другим методологиям.
Главное, чем книга расстроила: чтобы принципы начали работать, нужно всего лишь нанять команду крутых профессионалов. Делов-то. Но в целом принципы Agile в голове у меня книга устаканила хорошо, что-то попробовал применять в работе.

3. Ася Казанцева, «В интернете кто-то неправ!»
Работает ли гомеопатия, опасны ли ГМО, умнее ли мужчины женщин, вредно ли мясо для употребления в пищу. Кайф книги в том, что Ася Казанцева не навязывает своё субъективное мнение, а даёт ссылки на реальные научные исследования. И вообще призывает думать своей головой.

2. Рид Хастингс, Эрин Мейер, «Никаких правил. Уникальная культура Netflix»
Книга про успешный успех Netflix. Про то, как менялись процессы в компании, как выстроен найм. В целом неплохо объясняет, почему Netflix считается вполне себе желанным местом работы среди айтишников. Какие-то принципы можно попробовать перетащить к себе, они очень здравые. Какие-то не стыкуются с моими реалиями. В общем, читать нужно со здравой долей скепсиса, но полезного всё-таки в книге много.

1. Пирс Браун, «Алое восстание»
Художественная, Sci-Fi. Целая серия книг про будущее человечества, разделённого на касты. «Золотые» правят миром, опираясь на принципы древнеримской и древнегреческой империй, «алые» находятся внизу цепочки. Колонизация Солнечной системы, терраформирование, революции, «ваятели». Не всем подойдёт, это довольно жестокий боевик. Но я прочитал первые 3 книги саги взахлёб.

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

https://www.goodreads.com/user/year_in_books/2023/75780428

Запросы за спрятанными картинками

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

Стоян Стефанов провёл эксперимент с разными способами прятанья картинок:
1. Внутри <div style="visibility: hidden">.
2. Внутри <div style="display: none">.
3. Внутри закрытого <details>.
4. Пункты 1–3, но с loading=lazy.
5. Пункты 1–4, но внизу длинной страницы.

Результаты эксперимента:
- Если картинка без loading=lazy — она загрузится в любом случае. Во всех браузерах.
- <details> и display: none вместе с loading=lazy не загружают картинку, а вот visibility: hidden вместе с loading=lazy — загружает.
- Хотите что-то не загружать — либо loading=lazy, либо JS-решение.

В статье есть ссылка на демку, где можете сами посмотреть, как работают разные комбинации. И интересная старая техника с комментариями в HTML.

https://www.phpied.com/image-requests-in-hidden-content/

Выключение сторонних кук в Chrome

Если вы не следили за тем, что происходит в браузерах с 3rd-party куками, то сегодня, 4 января, Chrome запустил следующий этап по отключению сторонних кук на сайтах. Это значит, что у 1% пользователей Chrome такие куки будут выключены. Длиться тестирование будет целых полгода, в Q3 2024 планируют отключить 3rd-party куки совсем.

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

https://blog.google/products/chrome/privacy-sandbox-tracking-protection/