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

Да, вы всё поняли верно. If site == X, do Y.

Особого обращения заслужили TikTok, Netflix, Instagram* и даже SeatGuru.

Так поступают Safari и Firefox. Но не Chrome.

И это говорит нам кое о чём любопытном.

Если вам любопытно, исходный код выложен на Github. Это буквально проверки доменов, встроенные в движки рендеринга браузеров и гласящие: «если пользователь находится на этом домене, рендери вот это иначе» или «если он на этом домене, обрабатывай этот вызов API по-другому». Это не баг, а фича, выпускаемая для миллиардов устройств.

about:compat в Firefox

Если открыть Firefox и ввести в адресную строку about:compat, то вы увидите список исправлений совместимости с переключателями для сайтов. Каждое из них нацелено на конкретный веб-сайт; можно попробовать отключать их и смотреть, как ломается сайт.

Система WebCompat Firefox инъецирует в отдельные домены специальные CSS и JavaScript, меняет строки user agent для сайтов, некорректно отслеживающих браузеры, и прячет баги, из-за которых веб казался бы поломанным. Исправления совместимости (intervention) отслеживаются в Bugzilla Mozilla вместе с отчётами о багах и иногда с информацией о неудачных попытках достучаться до владельцев сайтов.

«quirks» Safari

В движке WebKit Safari такие изменения называются «закидонами» (quirks); они перечислены в файле Quirks.cpp, публично доступном на GitHub. Его чтение позволяет понять, как на самом деле работает веб. Вот пример комментария из кода:

Facebook, X (twitter) и Reddit нативно ставят на паузу элемент <video> когда он при скроллинге выходит за пределы вьюпорта, вне зависимости от того, находится ли этот элемент в режиме PiP («картинка в картинке»).

Итак, браузер определяет, когда пользователь находится на facebook.com*, x.com или reddit.com, и меняет способ обработки видео «картинка в картинке». Владельцы этих сайтов написали поломанный код видео, и вместо того, чтобы ждать, пока они его исправят, браузер реализует обходное решение для каждого пользователя. Вот ещё один комментарий:

FIXME: Удалить этот quirk, если seatguru решит исправить свой сайт.

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

Чтение истории коммитов — потрясающий процесс. Вот обновления всего за несколько последних месяцев: фотографии на сайте Zillow не центрировались, TikTok показывал сообщения «обновите браузер», Instagram* Reels в процессе проигрывания хаотично меняли размер, кнопка «Episodes and Info» Netflix некорректно обрабатывала закрытие всплывающих окон, Twitch ставил на паузу видео PiP при переключении закладок, а Amazon Prime Video вообще не позволял смотреть видео пользователям Safari. Для каждого из доменов выпустили собственное исправление, установленное у каждого пользователя.

С Chrome всё иначе

Файлы quirks не просто чинят поломанные сайты; часто они компенсируют контроль Chrome над тем, что вообще означает термин «работающий».

Паттерн выглядит так: Chrome выпускает фичу, разработчики пользуются ею, потому что Chrome доминирует на рынке, а другие браузеры бросаются или реализовывать фичу, или добавлять quirks для конкретных сайтов, чтобы скрыть различия. К тому моменту, как Safari или Firefox догонят Chrome, quirks уже будут разосланы в обновлениях миллионам пользователей.

В исходном коде WebKit есть изменения user agent, позволяющие Safari выдавать себя за Chrome на определённых сайтах, например, на страницах видео Amazon и различных стриминговых сервисов. Эти сайты ищут Chrome и ограничивают возможности пользователей всех остальных браузеров, поэтому чтобы пользователи Safari не страдали, WebKit выдаёт себя за другого. Вот строка из актуальных исходников Quirks.cpp:

auto chromeUserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"_s;

Safari в буквальном смысле выпускается с фальшивой строкой user agent Chrome, готовой к использованию, если сайты откажутся работать без неё. Firefox поступает так же; многие из его исправлений совместимости about:compat заключаются в спуфинге user agent, говорящем сайтам «да, я Chrome», потому что эти сайты активно блокируют отличные от Chrome браузеры или ломаются в них. В Mozilla wiki сообщается, что некоторые сайты «полностью блокируют доступ, отображают другой дизайн или предоставляют другую функциональность» в зависимости от обнаруженного браузера, поэтому Firefox приходится реализовывать обходные решения.

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

Изменения бывают очень глубокими

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

Вот, например, строка о симулируемых событиях мыши:

При наведении на изображение товара Amazon мы касаемся или элемента #magnifierLens, или его предыдущего сестринского элемента.

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

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

Для Chrome не нужен файл Quirks

Наверно, вы заметили, что я показал about:compat Firefox и файл Quirks.cpp WebKit, но ничего не говорил об их эквиваленте для Chrome.

На самом деле, Chrome он не нужен, и не всегда потому, что Chrome качественнее спроектирован. Веб уже заточен под Chrome. Более 80% пользователей ходят в веб через браузеры на основе Chromium, поэтому разработчики в первую очередь создают сайты под Chrome. Если сайт работает под Chrome, он считается готовым к запуску. Если он ломается в Safari или Firefox, то владельцы считают, что это менее серьёзная проблема.

Chrome не добавляет quirks, он задаёт повестку. Когда Chrome меняет работу какого-нибудь элемента, сайты подстраиваются под него, а другие браузеры следуют за ними или ломаются.

И эта асимметрия характерна для всего современного веба. Когда сайт ломается в Safari, инженеры WebKit добавляют quirk. Когда разработчики Chrome хотят поменять способ работы веба, то просто меняют его, а все остальные подстраиваются. Chrome не нужны quirks, потому что интерпретация веб-стандарта владельцем Chrome и есть та версия, с которой работают все остальные.

Это не делается злонамеренно и в этом не полностью виновата одна Google; на самом деле, это естественное следствие из доминирования на рынке. Разработчики браузеров диктуют нам те спецификации, которые уже сложились. Подход HTML5 к реализации «живой спецификации» позволил избавиться от хаоса эпохи IE/Netscape, согласовав спецификации с реальностью. Проблема в том, что разработчики полагаются на неоднозначные подробности реализации, а затем винят несоответствующие им браузеры, когда подробности различаются.

Пусть это и правда, исхода это не меняет. Когда Chrome становится для всех целевой реализацией, неоднозначные подробности Chrome де-факто становятся спецификацией. То же самое происходило с Internet Explorer в 2000-х. Когда разработчики создавали сайты под IE, те ломались в других браузерах, а соответствие стандартам становилось менее важным, чем работоспособность сайта в IE. Чтобы выбраться из этой ямы, нам понадобились годы.

Спустя десяток лет появилась надежда, что особенности браузеров со временем исчезнут, потому что веб станет больше соответствовать стандартам. Можно считать, что так и произошло, но по неожиданной причине: они никуда не пропали, а просто ушли во все остальные браузеры, кроме Chrome.

Проще исправить, чем ждать

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

Задача производителя браузеров заключается в том, чтобы веб работал у его пользователей, а если популярный сайт поломан в основном браузере, но работает в Chrome, то пользователи винят браузер. Отправка бага сторонней компании и ожидание в течение недель или месяцев исправления, которое могут так и не реализовать — невыгодная стратегия, если ты можешь уже завтра выпустить обходное решение длиной в пять строк.

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

Разработчик WebKit написал пост об удалении quirk для FlightAware. Этот сайт сравнивал строки матричных преобразований CSS, но в спецификации CSS изменился способ сериализации значений браузерами. Браузер внедрил эти изменения, а FlightAware поломался, поэтому разработчики добавили для этого домена код, устраняющий поломку на стороне пользователей. В конечном итоге обращение помогло, FlightAware исправил свой код, и quirk удалили. Но до этого в течение нескольких месяцев у пользователей Safari сайт не ломался только потому, что разработчик добавил конструкцию if, проверяющую наличие имени flightaware.com.

Проверьте сами

Возможно, рендеринг вашего сайта обрабатывается особым образом, а вы об этом даже не знаете. Quirk, благодаря которому это возможно, не отображается в логах ошибок, как нет и сообщения в консоли «этот браузер обходит ваши ошибки». Исправление невидимо по самой своей природе.

Если вы в основном выполняете тестирование в Chrome, то особенно подвержены таким проблемам. Возможно, ваш сайт работает идеально не потому, что вы написали хороший код, а потому, что поведение Chrome согласуется с вашими допущениями. Другим же браузерам приходится выбирать: или ваш сайт поломается для пользователей, или он добавит его в файл quirks.

Открывайте свой сайт в Firefox и Safari. Не иногда, не перед большим запуском, а регулярно. Файлы quirks существуют именно потому, что разработчики этого не делают.

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

Веб, который нам нужен и веб, который у нас есть

Спецификации — это карта, а списки quirks — реальная неприглядная территория.

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

В этих файлах есть сайты, над которыми работал я. Возможно, ваш там есть тоже.
И списки становятся только длиннее.

Примечание переводчика: я проверил файл Quirks.cpp браузера Safari и about:compat браузера Firefox, в обоих Хабр отсутствует.

_{Meta Platforms*, а также принадлежащие ей социальные сети Facebook** и Instagram**:*признана экстремистской организацией, её деятельность в России запрещена;**запрещены в России.}