Сэм Торогуд из Google опубликовал статью про события загрузки в web — "Understanding Load Events on the Web".

Во время загрузки страницы генерируются два события: load, DOMContentLoaded. Сэм пишет про то, что без них можно легко обойтись. Если надо запустить какой-нибудь код после загрузки страницы, то обработчик события load не самое лучшее для этого место. Страница может быть полностью интерактивна, но она может всё ещё ждать загрузку какого-нибудь неважного ресурса (фонового изображения, скрипта аналитики и т.п.)

Для обработки события DOMContentLoaded необходимо всегда выполнять небольшой реверанс с проверкой document.readyState. Если необходимо выполнить код скрипта после того, как будет доступен DOM, проще пометить этот скрипт с помощью defer. Единственное место, где нельзя обойтись без DOMContentLoaded, — код библиотек, так как такой код не знает был ли он загружен с помощью defer или async.

#web

https://whistlr.info/2020/understanding-load/

Еиджи Китамура на web.dev рассказал о том, как упростить процесс обновления данных для аутентификации с помощью менеджеров паролей — "Help users change passwords easily by adding a well-known URL for changing passwords".

Менеджеры паролей в Safari и Chrome (с версии 86) предоставляют элемент управления для быстрого перехода к изменению пароля. Чтобы он правильно работал, на вашем сайте должен быть настроен редирект со страницы /.well-known/change-password на страницу изменения пароля. Для редиректа лучше всего использовать: 302 Found, 303 See Other или 307 Temporary Redirect.

Редирект для /.well-known/change-password уже поддержали Google, Facebook, GitHub и другие сайты. Если на вашем сайте ещё нет редиректа, то его очень рекомендуется добавить.

#web #security

https://web.dev/change-password-url/

Дэйв Руперт поделился своим мнением про важность разнообразия браузеров — "What is the Value of Browser Diversity?".

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

Хорошая статья. Рекомендую почитать.

#web #musings

https://daverupert.com/2020/09/the-value-of-browser-diversity/

Вчера в репозитории csswg-drafts появилось предложение об отказе от HTML и CSS в пользу JavaScript. Автор предложения серьёзно подошёл к делу и подробно объяснил мотивацию (то есть это не было троллингом). Таб Аткинс предложение прикрыл с формулировкой, что оно противоречит фундаментальным принципам платформы. По мотивам произошедших событий Хид Де Врайс — участвует в разработке стандартов — написал статью "Why it's good for users that HTML, CSS and JS are separate languages".

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

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

#web

https://hiddedevries.nl/en/blog/2020-11-25-why-its-good-for-users-that-html-css-and-js-are-separate-languages/

HTTP Archive второй год подряд публикует отчёт о текущем состоянии веба — "Web Almanac 2020".

Альманах поделён на 22 главы, которые посвящены текущему состоянию дел в вебе: контенту (CSS, JavaScript, шрифты), пользовательскому опыту (доступность, производительность, SEO, приватность, безопасность, мобильный web), инструментам публикации (CMS, ecommerce, Jamstack) и распространению контента (сжатие, кеширование, Resource Hints, HTTP/2). Над проектом работали 116 специалистов, среди которых есть Рик Вискоми, Лия Веру, Тим Кадлек, Гарри Робертс и другие. Общий объём статей около 500 страниц.

В альманахе есть много информации и разных инсайтов, например, в самом большом HTML-атрибуте alt содержится 15 миллионов символов. На август 2020 года по HTTP/2 было передано 64% запросов. Средний объём страниц вместе со всем содержимым (CSS, JS, изображения) — 1.9Мб.

#report #web

https://almanac.httparchive.org/en/2020/

Андрей Ситник в блоге Злых Марсиан написал статью о современных практиках создания фавиконок сайта — "How to Favicon in 2021: Six files that fit most needs".

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

// HTML
<link rel="icon" href="/favicon.ico" /><!-- 32×32 -->
<link rel="icon" href="/icon.svg" type="image/svg+xml" sizes="any" />
<link rel="apple-touch-icon" href="/apple.png" /><!-- 180×180 -->
<link rel="manifest" href="/manifest.webmanifest" />

// manifest.webmanifest
{
  "icons": [
    { "src": "/192.png", "type": "image/png", "sizes": "192x192" },
    { "src": "/512.png", "type": "image/png", "sizes": "512x512" }
  ]
}

Формат ico нужен для поддержки RSS-ридеров. Формат SVG будет использоваться в браузерах (в статье есть пример, как в SVG сделать изменение цвета иконки в зависимости от текущей темы ОС). Иконка с rel="apple-touch-icon" нужна для того, чтобы ваш сайт красиво выглядел на домашнем экране iPhone. Файл манифеста нужен для добавления иконок, которые будут использоваться в Android.

Очень полезная статья. Рекомендую почитать.

#web

https://evilmartians.com/chronicles/how-to-favicon-in-2021-six-files-that-fit-most-needs

Дженс Оливер Маейерт написал небольшой пост о том, почему нужно забыть о AMP (Accelerated Mobile Pages) — "Ignore AMP".

В 2015 году Google предложил использовать AMP — технологию для ускорения доставки страниц. Намерение было благое, но сообщество выступило против этой инициативы с резкой критикой, в первую очередь из-за того, что AMP должен был распространяться с домена Google. По прошествии пяти лет AMP не получил большого распространения, более того Google начал продвигать другую инициативу с похожей целью — Web Vitals.

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

Советую заглянуть в статью, если задумывались о внедрении AMP в свой проект.

#google #web

https://meiert.com/en/blog/ignore-amp/

Йехуда Катц — один из отцов Ember, cargo и участник W3C — написал в твиттере большой тред, о распространённом заблуждении, что фронтенд — это специализация для джуниоров.

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

Разнообразие тулинга во фронтенде объясняется не уровнем подготовки специалистов, а, снова, враждебной средой, в которой должен работать код. Код нужно транспилировать, чтобы поддержать разные браузеры; можно, конечно, использовать старые версии языка, но это больно. Большие проекты используют PostCSS для использования новых фич CSS, добавления вендорных префиксов и для автоматического обхода ошибок в браузерах. Чтобы код был доставлен пользователю как можно быстрее, он должен быть собран сборщиком и минифицирован. Код нужно оптимизировать, потому что основная масса пользователей используют мобильные устройства на слабых процессорах.

В общем, хороший тред. Очень рекомендую почитать.

#musings #web

https://twitter.com/wycats/status/1342484366279098369

Мальте Юбэл из Google написал статью про современные практики работы с изображениями в web — "Maximally optimizing image loading for the web in 2021".

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

Самым интересным в статье для меня было описание техник для снижения потребления и оптимизации CPU. Например, вставка изображений с атрибутом decoding="async" даёт сигнал браузерам о том, что декодировать изображение можно вне главного потока (в твиттере в обсуждении статьи, лид, отвечающий за рендеринг в Chrome, говорит о том, что этот атрибут не включён по умолчанию, так как загружаемый контент моргал бы при загрузке). Ещё в статье есть описание трюка с использованием размытия с помощью SVG-фильтров, благодаря этому подходу изображения размываются только один раз при загрузке, а не на каждый layout страницы как при использовании CSS-фильтров.

Небольшая и очень полезная статья. Рекомендую почитать.

#graphics #web

https://www.industrialempathy.com/posts/image-optimizations/

Петер Перлепес написал статью про обработку событий перехода страницы в фоновый режим — "Exploring the Page Visibility API for Detecting Page Background State".

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

Все браузеры поддерживают события beforeunload и unload, с помощью которых можно отловить закрытие страницы, но они ненадёжны на мобильных платформах. Ещё эти события могут негативно влиять на Back/Forward Cache браузера. Современный подход — использование событий Page Visibility API: pagehide и visibilitychange. С ними есть сложности, связанные с кроссбраузерностью. В статье рассказывается о том, как лучше всего их использовать.

#js #web

https://tech.trivago.com/2020/11/17/exploring-the-page-visibility-api-for-detecting-page-background-state/

В прошлом году самой горячей темой стало усилившееся разногласие в отношении будущего веба между Apple, Google и Mozilla. Google продвигает идею "нативного" веба, добавляя в Chromium экспериментальные API для доступа К Bluetooth/USB-устройствам, файловой системе пользователя и т.п. Apple и Mozilla придерживаются консервативной позиции и не хотят добавлять некоторые API, предлагаемые Google, объясняя это заботой о приватности и безопасности пользователей.

Ноам Розенталь — участвует в разработке стандартов и движков браузеров — постарался объективно разобраться в этой теме и поделился своим видением решения возникшей проблемы — "Should The Web Expose Hardware Capabilities?".

В первой части статьи Ноам пытается понять обе стороны спора и пишет о том, что по-своему правы и Google, и Apple с Mozilla. С одной стороны мы хотим видеть развитие платформы, с другой стороны мы не хотим жертвовать безопасностью пользователей. Это очень серьёзный вопрос, например, в 2018 году исследователи в области безопасности рассказали о способе компроментации USB-ключей доступа с помощью WebUSB (Google эту проблему устранил). Чтобы избежать подобных проблем в будущем во второй части статьи автор предлагает внедрить модель доверия, в которой разработчики железа и браузеров могут ограничить урон, который может быть нанесён потенциально небезопасными API.

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

#web #specification

https://www.smashingmagazine.com/2021/01/web-expose-hardware-capabilities/

Наверное, все по несколько раз в день сталкиваются с cookie-баннерами. Сегодня в посте Ната Фридмана (CEO GitHub) прочитал о том, что в некоторых случаях их можно не показывать — "No cookie for you".

Европейский Союз требует, чтобы владельцы сайтов отображали информацию о таких куках, которые необязательны для работы сайта (куки систем аналитики, рекламных сетей, настройки и т.п.) Но на сайте можно не показывать баннер, если используются только такие куки, без которых сайт будет работать некорректно (куки с идентификатором сессии, корзины и т.п.) В конце 2020 года GitHub полностью отказался от использования необязательных кук, и, соответственно, удалил с сайта cookie-баннер.

#web

https://github.blog/2020-12-17-no-cookie-for-you/

В декабре 2020 года вебу исполнилось 30 лет. Дэниэл Кэо вспомнил ранние дни веба и написал про это статью — "Out of the Matrix: Early Days of the Web".

Дэниэл работал техническим писателем и редактором журнала NeXTWORLD, когда он узнал про Тима Бернерса-Ли и его проект World Wide Web. Дэниэл познакомился с Тимом и захотел опубликовать статью про веб, но ему не получилось убедить главного редактора, так как интернет тогда был в зачаточном состоянии, и им пользовались только учёные из CERN.

Интересно, что самый первый браузер — Nexus, который был сделан Тимом Бернерсом-Ли до Mosaic — имел встроенные инструменты для редактирования HTML-страниц. Потом эту функциональность добавили нативно в SDK NeXTSTEP. Но с релизом браузеров за пределами операционной системы NeXT, эта функция потерялась.

Ещё Дэниэл предложил Тиму использовать вместо HTML новый формат для редактируемого PostScript от Adobe (который получил название PDF). Он организовал встречу Роберта Кайо (одна из ключевых фигур в популяризации веба) c менеджментом Adobe, но, как мы уже знаем, HTML пережил это событие.

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

#web #history

https://blog.yax.com/posts/early-days-of-the-web-1991/

В блоге CSSSR была опубликована статья про судьбу первых web-браузеров — "История фронтенда: Браузер, который умел всё".

В статье рассказывается про WorldWideWeb — самый первый браузер, над которым работал Тим Бернерс-Ли и который позднее был переименован в Nexus. Рассказывается про систему организации данных для Macintosh — некий прообраз современного веба, но без поддержки сети. С помощью этой системы была сделана знаменитая игра Myst. Ещё в 1991 году вышла первая версия ViolaWWW — браузер, который поддерживал добавление на страницу апплетов-приложений на языке Viola.

Статья большая. Очень рекомендую почитать, если интересуетесь историей развития веба. Также есть видеоадаптация статьи.

#web #history

https://blog.csssr.com/ru/article/frontend-history-the-browser-that-could-do-everything/
https://www.youtube.com/watch?v=7nrDctGYOIk

В блоге CSSSR была опубликована вторая часть статьи про историю фронтенда — "История фронтенда: JavaScript как отражение новой эпохи".

Во второй части рассказывается про историю появления и развития веб-стандартов. HTML и JavaScript пережили похожий процесс: сначала была жёсткая конкуренция браузеров с хаотичным внедрением фич, затем предпринималась попытка стандартизации, которая была отвергнута сообществом (XHTML) или стала неудачной из-за слишком больших амбиций (ECMAScript 4), потом был застой, а затем продуктивная работа вместе с сообществом. HTML и JavaScript стали живыми стандартами, которые обновляются каждый год и поддерживаются всеми браузерами.

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

#history #web

https://blog.csssr.com/ru/article/frontend-history-java-script-as-a-reflection-of-a-new-era/
https://www.youtube.com/watch?v=sgyoKkAfGpU (видео)

Почему ссылки синие?

Элиза Бланшар написала статью про то, почему на многих сайтах ссылки синего цвета — "Why are hyperlinks blue?"

В первых интерфейсах для гиперссылок использовался чёрный цвет с подчёркиванием или рамками. С распространением цветных мониторов гиперссылки стали приобретать разные цвета, например, в клиенте Gopher (предтеча веб) использовался зелёный цвет. Mosaic стал первым браузером, который закрепил за ссылками привычные цвета: синий для обычных ссылок и тёмно-фиолетовый для посещённых. Почему был выбран синий цвет для обычных ссылок, точно неизвестно. Есть теория, что на этот выбор повлиял интерфейс Windows, который закрепил за синим цветом сигнал интерактивности.

Интересная статья. Рекомендую почитать, если интересуетесь историей появления веба.

#web #history #ux

https://blog.mozilla.org/en/internet-culture/deep-dives/why-are-hyperlinks-blue/

Причины сломанной загрузки JS и CSS

На сайте правительства Великобритании есть руководство, посвящённое прогрессивному улучшению — "Building a resilient frontend using progressive enhancement".

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

— временные сетевые ошибки;
— браузерные расширения, такие как блокировщики рекламы;
— проблемы сторонних сервисов, которые используются для доставки ресурсов сайта;
— ошибки резолвинга DNS;
— ошибки браузеров;
— блокировка на уровне файрволов;
— изменение содержимого страницы оператором сотовой связи;
— персональные файрволы или антивирусное ПО;
— изменение содержимого страницы провайдерами.

#web

https://www.gov.uk/service-manual/technology/using-progressive-enhancement

CORS — история появления и нюансы использования

Джейк Арчибальд написал статью про CORS с интерактивными примерами — "How to win at CORS".

Впервые управление кроссдоменными-запросами появилось в Flash с помощью файла /crossdomain.xml, в котором описывались права доступа сторонних сайтов. В 2005 году рабочая группа W3C Voice Browser Working Group предложила альтернативное решение для XML-ресурсов. Так как XML не получил широкого распространения для представления HTML-документов, предложение рабочей группы трансформировалось в CORS (Cross-Origin Resource Sharing), который управляется с помощью HTTP-заголовка: Access-Control-Allow-Origin.

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

#web #security #history

https://jakearchibald.com/2021/cors/

Потенциальные проблемы с Firefox 100 и Chrome 100

Близится день, когда Firefox и Chrome дойдут до сотой версии. Это не просто красивая цифра, но и потенциальная причина ошибок.

Немного истории. Opera стала первым браузером, дошедшим до версии 10. В альфа-версии десятки поломались сайты, неправильно парсившие User-Agent. Их логика парсинга предусматривала только одну цифру в версии, поэтому Opera 10 превращалась в Opera 1, ломая отображение сайта.

Подобная ситуация может случиться с Firefox 100 и Chrome 100, если логика парсинга не предусматривает трёхзначные числа. Поэтому разработчики браузеров рекомендуют проверить работу своих проектов с изменением версии браузера в User-Agent. Разработчики Chrome пошли немного дальше и сделали специальный флаг #force-major-version-to-100, который автоматически подымает версию Chrome до 100.

#announcement #web

https://developer.chrome.com/blog/force-major-version-to-100/
https://www.otsukare.info/2021/04/20/ua-three-digits-get-ready

Самые интересные факты из веб-альманаха 2021

Стефан Джудис рассказал о наиболее интересных фактах из веб-альманаха 2021 года — "Highlights of the Web Almanac 2021".

Каждый год майнтейнеры HTTP Archive и активные участники сообщества составляют веб-альманах — слепок текущего состояния веба на базе исследования более восьми миллионов популярных сайтов. В этом году в веб-альманахе было опубликовано 24 главы про HTTP, HTML, CSS, JS, приватность, производительность и т.п.

Из интересного:
— jQuery используется на 84% сайтов, React — на 8%;
— Wordpress обслуживает 33% просканированных сайтов;
— 94% сайтов используют по крайней мере один сторонний ресурс; подавляющее большинство от сервисов Google;
— если на странице подключается виджет youtube, медианное время блокирования главного потока составляет 1,6 секунд;
— 16% страниц используют бессодержательные названия ссылок: "click here", "read", "more" и т.п.;
— 22% сайтов поставляется с HSTS (HTTP Strict Transport Security);
— на 20% сайтов нет определения атрибута lang.

#web #research

https://www.stefanjudis.com/blog/highlights-from-the-web-almanac-2021/