#баг дня

Кастомные скроллбары — штука прекрасная, хоть за 20 лет так и не нашедшая свой путь в стандарты. До сих пор полноценная стилизация возможна только в Blink aka Chromium и WebKit aka Safari.

В Firefox как не работало, так и не работает.

К слову, хорошая статья Ахмада Шадида на тему: https://ishadeed.com/article/custom-scrollbars-css/

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

Я, правда, не знаю, кому может прийти в голову менять стили скроллбара по hover.

Раз сработает, два сработает, а на третий — всё, нет. Смотрим видео, собственно.

Решение от Брамуса Ван-Дамма довольно забавное: нужно стриггерить инвалидацию стилей, для чего можно рандомной CSS-переменной присвоить неопределённое значение. Вот так:

.section:hover {
  --force-rerender: ;
}

Странные вайбы такие... IE-шные.

Короче, как будет ссылка на официальный багтрекер — закину.

Upd. Ссылка на багтрекер: https://bugs.webkit.org/show_bug.cgi?id=267575

#css #scrollbar #safari #bug #бородач

#баг дня

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

Вот только если ты пойдёшь и скопируешь в Chrome текст, на который наложен text-transfrorm: uppercase, скопируются заглавные буквы!

Но это неправильно: спека.

В общем, в Chrome 127, благодаря разработчикам из Microsoft, это будет исправлено.

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

Ну и ссылка на баг: https://chromium-review.googlesource.com/c/chromium/src/+/5399744

Такой же баг присутствует в Safari, Firefox же отрабатывает ок. Думаю, код этой части CSS в Blink довольно старый, потому можно ожидать, что в Safari и WebKit будет бэкпорт.

#bug #chrome #css

#баг дня

Разработчики спецификации:
— Вот вам предложение ввести нативный нестинг в CSS!

Разработчики браузеров:
— Мы сделали вам нативный нестинг в CSS!

Разработчики сайтов:
— Гляди, рендер одного слова занимает пять секунд

Кроме шуток, это действительно интересная проблема. Довольно больно.

Давайте посмотрим на этот пример: https://crisal.io/tmp/lots-of-nesting.html

На моей машине рендерится за 5.4 секунды. MacBook Pro M2 13", Chrome 126.0.6478.63

Safari вылетает и на ноутбуке, и на iPhone.

Firefox показывает кривые данные, но тоже близко к 5 секундам.

Вот ссылка на GitHub issue: https://github.com/w3c/csswg-drafts/issues/2881#issuecomment-1642450622

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

...но делитесь вашими бенчмарками, котаны :)

#css #nesting #bug

#баг дня

Одна из моих любимых фишек инструментов разработчика Google Chrome (aka девтулзов) — это возможность сделать скриншот ноды.

Нужен длинный скриншот страницы? Бахаешь на body или html и сидишь довольный.

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

Но не обошлось без проблем. Ну честное слово, вот же вся страница, на экране. Бери да превращай в картинку. Нет...

Если в вашей ноде есть картинки, добавленные через тег img с атрибутом decoding="async" — они потеряются :(

Вот так вот неожиданно. Видимо кто-то где-то промис не разресолвил :)

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

Но неприятный осадок всё-таки остался.

Сейчас ищу формальное описание бага в багтрекере. Если не найду — придётся заводить.

Демо: https://10web.io/blog/how-to-create-a-blog-on-wordpress/

Просто попробуйте сделать скриншот body, не скролля заранее.

Проверено на Chrome 128.0.6613.120.

В итоге, часть картинок может появиться, а часть — нет.

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

P. S. В Firefox баг тоже имеется.

#chrome #bug #async

#баг дня

Наслаждаетесь экраном MacBook Pro или радуетесь новому wide gamut дисплею от, например, Dell?

Не спешите радоваться, Chome и тут нас подставил!

Обратите внимание на иллюстрацию. На ней — не продублированный текст, а просто пропущенный через SVG-фильтр, который фильтрует цвета и сдвигает контент через матрицу преобразований: https://codepen.io/thebabydino/pen/RwmPZVR

Автор этой прелести — Ана Тюдор (ну кто же ещё, больше таких крутых специалистов по фильтрам просто нет).

Так вот, есть маленькая проблема. На дисплеях с широким покрытием цветового поля Chrome находит зелёный цвет в красном и голубом. Где-то просчитались :) Из-за чего в фильтрах появляются серые полосы.

На Firefox и Safari таких проблем нет.

Чтобы проверить свой дисплей, можно пройти сюда: https://www.wide-gamut.com/test

Чтобы проверить баг, сюда: https://codepen.io/thebabydino/pen/vYqMvzv (должно быть только три чёрные полосы, без серых).

И вот сегодня утром Ана отправила баг в Chromium: https://issues.chromium.org/u/1/issues/373410239?pli=1

Если у вас оно повторяется, напишите, пожалуйста, подробности о своей платформе на трекере 🙏

Новые возможности хардвари — это, конечно, хорошо. Но лучше бы без багов, да.

#color #bug

#баг дня

Если вы тут утром решили развернуть новый проект на Vite, и у вас ничего не вышло, это нормально.

esuild, на котором Vite и основана, в версии 0.24.1 принёс ломающее конфиги изменение.

И на данный момент лучшее решение — запинить зависимость esbuild на 0.24.0: https://github.com/vitejs/vite/issues/19018

Ну или использовать пятую ветку Vite.

Повторяется на всех пакетных менеджерах: и npm, и pnpm и bun и, прости господи, yarn.

Осторожнее там, котаны :)

#vite #esbuild #bug

#баг дня

Посмотрите на иллюстрацию к посту, ничего интересного не замечаете?

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

Да, использование новомодных HDR-цветов и описывание их в OKLCH в Chrome на macOS приводит к неожиданным эффектам, будучи применённым на корневую ноду, aka тег HTML.

Правильный цвет тот, что темнее. Откуда я знаю? В Safari бага нет. В FIrefox, кстати, тоже.

А багу в Chrome на macOS тупо два года уже: https://issues.chromium.org/issues/40064153

Ну, бывает.

#oklch #color #bug

#баг дня или история одного апокалипсиса

Знаете, что происходит, если в Firefox ввести в <input type="number"> что-то вроде lol?

Он позволяет.

Да, вы видите эти lol, будто это валидное число. Только вот значение value в DOM превращается в пустую строку. Ну типа «я тебе это показал, но делать с этим ничего не буду». Гениально.

Баг #1398528 в Bugzilla живёт с 2017 года. Проблему признают: Firefox нарушает спецификацию WHATWG, согласно которой input type=number должен принимать только корректные числовые строки. А на деле — буквы, кириллица, эмоджи — всё идёт в бой. Только вот под капотом — пусто. Т.е. ты видишь, что ввёл, но значение не считается валидным. UX? Ну, такое себе.

Почему не фиксят?

Ответ классический: «а что, если у нас локаль с деванагари и арабскими цифрами, и вообще — как различать запятую и точку?». Ну и правда, лучше пусть вводится вся клавиатура, чем разбираться в сепараторах.

А теперь немного цирка из Chrome:

В Chrome <input type="number"> иногда разрешает ввод e, ведь вдруг ты хочешь ввести 1e10 (научную запись). Но если ты просто набрал e, поле становится… валидным. Бинго!

Ещё веселее: 1e- — тоже "нормально", но 1ee — уже нет. Картинку с барабаном вставите сами.

А если ты вводишь 1,5 в локали, где десятичный — это точка, Chrome может забраковать это, а может и нет — зависит от версии, луны и количества кофе у разработчика.

В итоге: у Firefox можно ввести хоть «привет», и он такой: «ну окей, но это не число». Chrome вроде бы фильтрует, но делает это через лунную призму.

Что же мы делаем? Пишем код, блять!

Мораль: в 2025 году проще создать свою валидацию под конкретный случай, чем надеяться, что браузеры когда-нибудь договорятся.
А баг тем временем отмечает 8 лет жизни, всё ещё «NEW», и, судя по комментариям, будет жить

Баг-репорт: https://bugzilla.mozilla.org/show_bug.cgi?id=1398528

Подпишитесь и следите, если вы, как и мы, верите (нет) в чудеса стандартизации.

P. S. тем временем Firefox пробивает дно за дном. В англоязычном интерфейсе выдаёт мне ошибки валидации на финском языке.

P. P. S. я молчу уже о том, что <input type="number"> вообще нахер не нужен и даже вреден: https://xn--r1a.website/htmlshit/2663

#firefox #bug #input #number

#баг дня

Одна из моих любимых фишек инструментов разработчика Google Chrome или Firefox (aka девтулзов) — это возможность сделать скриншот ноды.

Нужен длинный скриншот страницы? Бахаешь на body или html и сидишь довольный.

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

Но не обошлось без проблем. Ну честное слово, вот же вся страница, на экране. Бери да превращай в картинку. Нет...

Если в вашей ноде есть картинки, добавленные через тег img с атрибутом decoding="async" — они потеряются :(

Вот так вот неожиданно. Видимо кто-то где-то промис не разресолвил :)

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

Но неприятный осадок всё-таки остался.

Сейчас ищу формальное описание бага в багтрекере. Если не найду — придётся заводить.

Демо: https://10web.io/blog/how-to-create-a-blog-on-wordpress/

Просто попробуйте сделать скриншот body, не скролля заранее.

Проверено на Chrome 138.0.7204.184. Столько времени прошло с предыдущей проверки...

В итоге, часть картинок может появиться, а часть — нет.

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

P. S. В Firefox 141 баг тоже имеется.

#chrome #bug #async #бородач

#такое дня

Вы, наверное, ждёте все, что я сообщу о выходе jQuery 4.0?

Ну так не вышла ещё, только RC1: https://blog.jquery.com/2025/08/11/jquery-4-0-0-release-candidate-1/

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

В мире, в котором нет Internet Explorer, всё ещё есть Safari. И не сказать, что это плохой продукт — вроде целевой аудитории-то он даже нравится — но и хорошим не назвать.

И вот что интересно, плохая или, что даже хуже, неочевидная работа Safari и движка WebKit в частности (а точнее говоря, работа движка в конечном продукте интеграции) сформировала целую культуру длинных гневных комментариев!

Вы только посмотрите на пример на иллюстрации! Я уверен, я бы тоже написал нечто подобное (да и писал), если бы наткнулся сам.

Ну то есть суть всей проблемы: WebKit или зумит по двойному тапу, или скроллит, если зум отключён через CSS. И чтобы предотвратить скролл, надо просто объявить использование события двойного клика. Даже отменять поведение по-умолчанию не обязательно.

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

А какая особенность яблочного браузера раздражает вас больше всего, котаны?

#safari #bug #feature

#баг дня

В Chrome 147 случилась регрессия.

Всем известно, что input type="number" реагирует на колесо мыши, это никогда не было проблемой, потому что браузер прекрасно понимал, когда случится прокрутка страницы и отменял событие.

Но вот, случилось что случилось. Если оставить курсор на инпуте и крутануть колесом — и страница прокрутится, и число поменяется: https://issues.chromium.org/issues/508306805
Демо: https://jsfiddle.net/7389xv1z

Исправление приземлится только в Chrome 150, так что если вас заденет... работаем по-старинке:

input.addEventListener('wheel', e => e.preventDefault(), { passive: false });

#chrome #bug

#баг дня или история одного апокалипсиса

Знаете, что происходит, если в Firefox ввести в <input type="number"> что-то вроде lol?

Он позволяет.

Да, вы видите эти lol, будто это валидное число. Только вот значение value в DOM превращается в пустую строку. Ну типа «я тебе это показал, но делать с этим ничего не буду». Гениально.

Баг #1398528 в Bugzilla живёт с 2017 года. Проблему признают: Firefox нарушает спецификацию WHATWG, согласно которой input type=number должен принимать только корректные числовые строки. А на деле — буквы, кириллица, эмоджи — всё идёт в бой. Только вот под капотом — пусто. Т.е. ты видишь, что ввёл, но значение не считается валидным. UX? Ну, такое себе.

Почему не фиксят?

Ответ классический: «а что, если у нас локаль с деванагари и арабскими цифрами, и вообще — как различать запятую и точку?». Ну и правда, лучше пусть вводится вся клавиатура, чем разбираться в сепараторах.

А теперь немного цирка из Chrome:

В Chrome <input type="number"> иногда разрешает ввод e, ведь вдруг ты хочешь ввести 1e10 (научную запись). Но если ты просто набрал e, поле становится… валидным. Бинго!

Ещё веселее: 1e- — тоже "нормально", но 1ee — уже нет. Картинку с барабаном вставите сами.

А если ты вводишь 1,5 в локали, где десятичный — это точка, Chrome может забраковать это, а может и нет — зависит от версии, луны и количества кофе у разработчика.

В итоге: у Firefox можно ввести хоть «привет», и он такой: «ну окей, но это не число». Chrome вроде бы фильтрует, но делает это через лунную призму.

Что же мы делаем? Пишем код, блять!

Мораль: в 2026 году проще создать свою валидацию под конкретный случай, чем надеяться, что браузеры когда-нибудь договорятся.
А баг тем временем отмечает 8 лет жизни, всё ещё «NEW», и, судя по комментариям, будет жить

Баг-репорт: https://bugzilla.mozilla.org/show_bug.cgi?id=1398528

Подпишитесь и следите, если вы, как и мы, верите (нет) в чудеса стандартизации.

P. S. тем временем Firefox пробивает дно за дном. В англоязычном интерфейсе выдаёт мне ошибки валидации на финском языке.

P. P. S. я молчу уже о том, что <input type="number"> вообще нахер не нужен и даже вреден: https://xn--r1a.website/htmlshit/2663

#firefox #bug #input #number #бородач

#заметка дня

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

С TLS inspection он фактически работает как MITM-прокси: расшифровывает трафик, проверяет его и устанавливает новое соединение до вашего сервера. В результате ваши красивые предположения про HTTP/2, multiplexing и долгоживущие соединения внезапно превращаются в тупую очередь.

У Zscaler HTTP/2 зависит от настроек, а некоторые функции вообще откатывают трафик на HTTP/1.1. WebSocket тоже проходит через отдельные политики и ограничения.
И вот вы ищете баг во фронтенде, потому что «у банка всё тормозит», а проблема в том, что где-то между вашим кодом и пользователем сидит корпоративный прокси и молча превращает 2026 год обратно в 2012-й.

А потом тикет всё равно прилетит вам.

#bug #http