Вот то самое откровение, которое я обещал в новости о jQuery 4.0.
В Chrome 145 будет изменено поведение 100vw. Браузер будет учитывать ширину скроллбара, исключая горизонтальную прокрутку.
Ссылка: https://www.bram.us/2026/01/15/100vw-horizontal-overflow-no-more/
И да, это будет ломающее изменение.
Хотя, если честно, я не очень понимаю людей, которым вообще нужно было значение 100vw, это же дефолт блочных структур.
Старое поведение по факту годами создавало баг, с которым разработчики либо мирились, либо прятали его костылями — через
calc. Самый показательный момент — реальные цифры.
Через HTTP Archive было проанализировано 12 089 606 корневых страниц. Из них 324 866 сайтов, то есть примерно 2.7%, в принципе использовали
calc() рядом с 100vw. При этом явные попытки компенсировать ширину скроллбара встречаются крайне редко: порядка 4 000 сайтов принудительно задают overflow: scroll на <html>, и всего несколько десятков страниц используют calc(100vw - …) именно для учёта скроллбара.Вот комментарий в PR спеки: https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-1919428550
Это хорошо показывает реальную картину: подавляющее большинство разработчиков никогда не «считали скроллбар». Они либо избегали 100vw, либо жили с лишним горизонтальным скроллом, либо просто добавляли overflow-x: hidden. То есть проблема была массовой, а осознанно решали её — доли процента.
Именно поэтому браузеры и пошли на ломающее изменение. Старое поведение не было полезной фичей, это была историческая особенность, которая порождала баги чаще, чем решала реальные задачи. В итоге решили сломать редкие кейсы ради того, чтобы 100vw наконец означал то, что от него ожидают почти все.
Хороший пример того, сколько инженерной работы уходит на полировку вещей, которые пользователи, возможно, и не заметят напрямую, но которые годами раздражали фронтендеров.
И хороший вопрос, какой процент разработчиков морочится с чем-то менее видным, если даже на возможные скроллбары всем пофигу...
#css #scroll