Ширина скролла в браузерах

Обновлено: 05.07.2024

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

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

Простой пример

В качестве простого примера демонстрации свойств мы будем использовать следующий элемент:

У элемента есть рамка (border), внутренний отступ (padding) и прокрутка. Полный набор характеристик. Обратите внимание, тут нет внешних отступов (margin), потому что они не являются частью элемента, для них нет особых JavaScript-свойств.

Результат выглядит так:

В иллюстрации выше намеренно продемонстрирован самый сложный и полный случай, когда у элемента есть ещё и полоса прокрутки. Некоторые браузеры (не все) отбирают место для неё, забирая его у области, отведённой для содержимого (помечена как «content width» выше).

Таким образом, без учёта полосы прокрутки ширина области содержимого (content width) будет 300px , но если предположить, что ширина полосы прокрутки равна 16px (её точное значение зависит от устройства и браузера), тогда остаётся только 300 - 16 = 284px , и мы должны это учитывать. Вот почему примеры в этой главе даны с полосой прокрутки. Без неё некоторые вычисления будут проще.

Область padding-bottom (нижний внутренний отступ) может быть заполнена текстом

Нижние внутренние отступы padding-bottom изображены пустыми на наших иллюстрациях, но если элемент содержит много текста, то он будет перекрывать padding-bottom , это нормально.

Метрики

Вот общая картина с геометрическими свойствами:

Значениями свойств являются числа, подразумевается, что они в пикселях.

Давайте начнём исследовать, начиная снаружи элемента.

offsetParent, offsetLeft/Top

Эти свойства редко используются, но так как они являются «самыми внешними» метриками, мы начнём с них.

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

То есть, ближайший предок, который удовлетворяет следующим условиям:

Является CSS-позиционированным (CSS-свойство position равно absolute , relative , fixed или sticky ),
или <td> , <th> , <table> ,
или <body> .

Свойства offsetLeft/offsetTop содержат координаты x/y относительно верхнего левого угла offsetParent .

В примере ниже внутренний <div> имеет элемент <main> в качестве offsetParent , а свойства offsetLeft/offsetTop являются сдвигами относительно верхнего левого угла ( 180 ):

Существует несколько ситуаций, когда offsetParent равно null :

Для скрытых элементов (с CSS-свойством display:none или когда его нет в документе).
Для элементов <body> и <html> .
Для элементов с position:fixed .

offsetWidth/Height

Теперь переходим к самому элементу.

Эти два свойства – самые простые. Они содержат «внешнюю» ширину/высоту элемента, то есть его полный размер, включая рамки.

Для нашего элемента:

offsetWidth = 390 – внешняя ширина блока, её можно получить сложением CSS-ширины ( 300px ), внутренних отступов ( 2 * 20px ) и рамок ( 2 * 25px ).
offsetHeight = 290 – внешняя высота блока.

Координаты и размеры в JavaScript устанавливаются только для видимых элементов.

Если элемент (или любой его родитель) имеет display:none или отсутствует в документе, то все его метрики равны нулю (или null , если это offsetParent ).

Например, свойство offsetParent равно null , а offsetWidth и offsetHeight равны 0 , когда мы создали элемент, но ещё не вставили его в документ, или если у элемента (или у его родителя) display:none .

Мы можем использовать это, чтобы делать проверку на видимость:

Заметим, что функция isHidden также вернёт true для элементов, которые в принципе показываются, но их размеры равны нулю (например, пустые <div> ).

clientTop/Left

Пойдём дальше. Внутри элемента у нас рамки (border).

Для них есть свойства-метрики clientTop и clientLeft .

В нашем примере:

clientLeft = 25 – ширина левой рамки
clientTop = 25 – ширина верхней рамки

…Но на самом деле эти свойства – вовсе не ширины рамок, а отступы внутренней части элемента от внешней.

В чём же разница?

Она возникает, когда документ располагается справа налево (операционная система на арабском языке или иврите). Полоса прокрутки в этом случае находится слева, и тогда свойство clientLeft включает в себя ещё и ширину полосы прокрутки.

В этом случае clientLeft будет равно 25 , но с прокруткой – 25 + 16 = 41 .

Вот соответствующий пример на иврите:

clientWidth/Height

Эти свойства – размер области внутри рамок элемента.

Они включают в себя ширину области содержимого вместе с внутренними отступами padding , но без прокрутки:

На рисунке выше посмотрим вначале на высоту clientHeight .

Горизонтальной прокрутки нет, так что это в точности то, что внутри рамок: CSS-высота 200px плюс верхние и нижние внутренние отступы ( 2 * 20px ), итого 240px .

Теперь clientWidth – ширина содержимого здесь равна не 300px , а 284px , т.к. 16px отведено для полосы прокрутки. Таким образом: 284px плюс левый и правый отступы – всего 324px .

Если нет внутренних отступов padding , то clientWidth/Height в точности равны размеру области содержимого внутри рамок за вычетом полосы прокрутки (если она есть).

Поэтому в тех случаях, когда мы точно знаем, что отступов нет, можно использовать clientWidth/clientHeight для получения размеров внутренней области содержимого.

scrollWidth/Height

Эти свойства – как clientWidth/clientHeight , но также включают в себя прокрученную (которую не видно) часть элемента.

На рисунке выше:

scrollHeight = 723 – полная внутренняя высота, включая прокрученную область.
scrollWidth = 324 – полная внутренняя ширина, в данном случае прокрутки нет, поэтому она равна clientWidth .

Эти свойства можно использовать, чтобы «распахнуть» элемент на всю ширину/высоту.

Нажмите на кнопку, чтобы распахнуть элемент:

текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст текст

scrollLeft/scrollTop

Свойства scrollLeft/scrollTop – ширина/высота невидимой, прокрученной в данный момент, части элемента слева и сверху.

Следующая иллюстрация показывает значения scrollHeight и scrollTop для блока с вертикальной прокруткой.

Другими словами, свойство scrollTop – это «сколько уже прокручено вверх».

В отличие от большинства свойств, которые доступны только для чтения, значения scrollLeft/scrollTop можно изменять, и браузер выполнит прокрутку элемента.

При клике на следующий элемент будет выполняться код elem.scrollTop += 10 . Поэтому он будет прокручиваться на 10px вниз.

Установка значения scrollTop на 0 или Infinity прокрутит элемент в самый верх/низ соответственно.

Не стоит брать width/height из CSS

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

Но как мы знаем из главы Стили и классы, CSS-высоту и ширину можно извлечь, используя getComputedStyle .

Так почему бы не получать, к примеру, ширину элемента при помощи getComputedStyle , вот так?

Почему мы должны использовать свойства-метрики вместо этого? На то есть две причины:

Во-первых, CSS-свойства width/height зависят от другого свойства – box-sizing , которое определяет, «что такое», собственно, эти CSS-ширина и высота. Получается, что изменение box-sizing , к примеру, для более удобной вёрстки, сломает такой JavaScript.

Во-вторых, CSS свойства width/height могут быть равны auto , например, для инлайнового элемента:

Конечно, с точки зрения CSS width:auto – совершенно нормально, но нам-то в JavaScript нужен конкретный размер в px , который мы могли бы использовать для вычислений. Получается, что в данном случае ширина из CSS вообще бесполезна.

Есть и ещё одна причина: полоса прокрутки. Бывает, без полосы прокрутки код работает прекрасно, но стоит ей появиться, как начинают проявляться баги. Так происходит потому, что полоса прокрутки «отъедает» место от области внутреннего содержимого в некоторых браузерах. Таким образом, реальная ширина содержимого меньше CSS-ширины. Как раз это и учитывают свойства clientWidth/clientHeight .

…Но с getComputedStyle(elem).width ситуация иная. Некоторые браузеры (например, Chrome) возвращают реальную внутреннюю ширину с вычетом ширины полосы прокрутки, а некоторые (например, Firefox) – именно CSS-свойство (игнорируя полосу прокрутки). Эти кроссбраузерные отличия – ещё один повод не использовать getComputedStyle , а использовать свойства-метрики.

Если ваш браузер показывает полосу прокрутки (например, под Windows почти все браузеры так делают), то вы можете протестировать это сами, нажав на кнопку в ифрейме ниже.

У элемента с текстом в стилях указано CSS-свойство width:300px .

На ОС Windows браузеры Firefox, Chrome и Edge резервируют место для полосы прокрутки. Но Firefox отображает 300px , в то время как Chrome и Edge – меньше. Это из-за того, что Firefox возвращает именно CSS-ширину, а остальные браузеры – «реальную» ширину за вычетом прокрутки.

Обратите внимание: описанные различия касаются только чтения свойства getComputedStyle(. ).width из JavaScript, визуальное отображение корректно в обоих случаях.

Итого

У элементов есть следующие геометрические свойства (метрики):

offsetParent – ближайший CSS-позиционированный родитель или ближайший td , th , table , body .
offsetLeft/offsetTop – позиция в пикселях верхнего левого угла относительно offsetParent .
offsetWidth/offsetHeight – «внешняя» ширина/высота элемента, включая рамки.
clientLeft/clientTop – расстояние от верхнего левого внешнего угла до внутренного. Для операционных систем с ориентацией слева-направо эти свойства равны ширинам левой/верхней рамки. Если язык ОС таков, что ориентация справа налево, так что вертикальная полоса прокрутки находится не справа, а слева, то clientLeft включает в своё значение её ширину.
clientWidth/clientHeight – ширина/высота содержимого вместе с внутренними отступами padding , но без полосы прокрутки.
scrollWidth/scrollHeight – ширины/высота содержимого, аналогично clientWidth/Height , но учитывают прокрученную, невидимую область элемента.
scrollLeft/scrollTop – ширина/высота прокрученной сверху части элемента, считается от верхнего левого угла.

Все свойства доступны только для чтения, кроме scrollLeft/scrollTop , изменение которых заставляет браузер прокручивать элемент.

Задачи

Найти размер прокрутки снизу

Свойство elem.scrollTop содержит размер прокрученной области при отсчёте сверху. А как подсчитать размер прокрутки снизу (назовём его scrollBottom )?

Напишите соответствующее выражение для произвольного элемента elem .

P.S. Проверьте: если прокрутки нет вообще или элемент полностью прокручен – оно должно давать 0 .

Другими словами: (вся высота) минус (часть, прокрученная сверху) минус (видимая часть) – результат в точности соответствует размеру прокрутки снизу.

Материал на этой странице устарел, поэтому скрыт из оглавления сайта.

Как найти ширину окна браузера? Как узнать всю высоту страницы, с учётом прокрутки? Как прокрутить её из JavaScript?

С точки зрения HTML, документ – это document.documentElement . У этого элемента, соответствующего тегу <html> , есть все стандартные свойства и метрики и, в теории, они и должны нам помочь. Однако, на практике есть ряд нюансов, именно их мы рассмотрим в этой главе.

Ширина/высота видимой части окна

Свойства clientWidth/Height для элемента document.documentElement – это как раз ширина/высота видимой области окна.

Например, кнопка ниже выведет размер такой области для этой страницы:

В чём отличие? Оно небольшое, но чрезвычайно важное.

Свойства clientWidth/Height , если есть полоса прокрутки, возвращают именно ширину/высоту внутри неё, доступную для документа, а window.innerWidth/Height – игнорируют её наличие.

Если справа часть страницы занимает полоса прокрутки, то эти строки выведут разное:

Обычно нам нужна именно доступная ширина окна, например, чтобы нарисовать что-либо, то есть за вычетом полосы прокрутки. Поэтому используем documentElement.clientWidth .

Ширина/высота страницы с учётом прокрутки

Теоретически, видимая часть страницы – это documentElement.clientWidth/Height , а полный размер с учётом прокрутки – по аналогии, documentElement.scrollWidth/scrollHeight .

Это верно для обычных элементов.

А вот для страницы с этими свойствами возникает проблема, когда прокрутка то есть, то нет. В этом случае они работают некорректно. В браузерах Chrome/Safari и Opera при отсутствии прокрутки значение documentElement.scrollHeight в этом случае может быть даже меньше, чем documentElement.clientHeight , что, конечно же, выглядит как совершеннейшая чепуха и нонсенс.

Эта проблема возникает именно для documentElement , то есть для всей страницы.

Надёжно определить размер страницы с учётом прокрутки можно, взяв максимум из нескольких свойств:

Почему так? Лучше и не спрашивайте, это одно из редких мест, где просто ошибки в браузерах. Глубокой логики здесь нет.

Получение текущей прокрутки

У обычного элемента текущую прокрутку можно получить в scrollLeft/scrollTop .

Что же со страницей?

Большинство браузеров корректно обработает запрос к documentElement.scrollLeft/Top , однако Safari/Chrome/Opera есть ошибки (к примеру 157855, 106133), из-за которых следует использовать document.body .

Чтобы вообще обойти проблему, можно использовать специальные свойства window.pageXOffset/pageYOffset :

Кросс-браузерный вариант с учётом IE8 предусматривает откат на documentElement :

Изменение прокрутки: scrollTo, scrollBy, scrollIntoView

Чтобы прокрутить страницу при помощи JavaScript, её DOM должен быть полностью загружен.

На обычных элементах свойства scrollTop/scrollLeft можно изменять, и при этом элемент будет прокручиваться.

Никто не мешает точно так же поступать и со страницей. Во всех браузерах, кроме Chrome/Safari/Opera можно осуществить прокрутку установкой document.documentElement.scrollTop , а в указанных – использовать для этого document.body.scrollTop . И будет работать. Можно попробовать прокручивать и так и эдак и проверять, подействовала ли прокрутка, будет кросс-браузерно.

Но есть и другое, простое и универсальное решение – специальные методы прокрутки страницы window.scrollBy(x,y) и window.scrollTo(pageX,pageY).

Метод scrollBy(x,y) прокручивает страницу относительно текущих координат.

Например, кнопка ниже прокрутит страницу на 10px вниз:

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

Он эквивалентен установке свойств scrollLeft/scrollTop .

Чтобы прокрутить в начало документа, достаточно указать координаты (0,0) .

scrollIntoView

Для полноты картины рассмотрим также метод elem.scrollIntoView(top).

Метод elem.scrollIntoView(top) вызывается на элементе и прокручивает страницу так, чтобы элемент оказался вверху, если параметр top равен true , и внизу, если top равен false . Причём, если параметр top не указан, то он считается равным true .

Кнопка ниже прокрутит страницу так, чтобы кнопка оказалась вверху:

А следующая кнопка прокрутит страницу так, чтобы кнопка оказалась внизу:

Запрет прокрутки

Иногда бывает нужно временно сделать документ «непрокручиваемым». Например, при показе большого диалогового окна над документом – чтобы посетитель мог прокручивать это окно, но не документ.

Чтобы запретить прокрутку страницы, достаточно поставить document.body.style.overflow = "hidden" .

При этом страница замрёт в текущем положении.

При нажатии на верхнюю кнопку страница замрёт на текущем положении прокрутки. После нажатия на нижнюю – прокрутка возобновится.

Вместо document.body может быть любой элемент, прокрутку которого необходимо запретить.

Недостатком этого способа является то, что сама полоса прокрутки исчезает. Если она занимала некоторую ширину, то теперь эта ширина освободится, и содержимое страницы расширится, текст «прыгнет», заняв освободившееся место.

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

Итого

Для получения размеров видимой части окна: document.documentElement.clientWidth/Height

Для получения размеров страницы с учётом прокрутки:

Прокрутка окна:

На всякий случай – вот самый кросс-браузерный способ, учитывающий IE7- в том числе:

Установить прокрутку можно при помощи специальных методов:

window.scrollTo(pageX,pageY) – абсолютные координаты,
window.scrollBy(x,y) – прокрутить относительно текущего места.
elem.scrollIntoView(top) – прокрутить, чтобы элемент elem стал виден.

Задачи

Полифилл для pageYOffset в IE8

Обычно в IE8 не поддерживается свойство pageYOffset . Напишите полифилл для него.

Скроллбар (scrollbar, полоса прокрутки) — это простой, но эффективный механизм, который действует как основное средство, с помощью которого можно просматривать большие документы. Но это — далеко не всё, на что способны полосы прокрутки! Эти скромные рабочие лошадки ещё и неплохо подсказывают пользователям о том, каковы размеры документов, с которыми они взаимодействуют. В результате скроллбары несут на себе двойную нагрузку. Они и помогают работать с различными материалами, и информируют пользователя о размерах этих материалов.

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

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

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

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

Немного терминологии

Прежде чем мы продолжим — давайте определимся с парой терминов, которые мы будем тут использовать. А именно, мы выделяем две разновидности скроллбаров:

Фиксированные (obtrusive) скроллбары — такие, которые занимают экранное пространство. Они не накладываются на просматриваемые материалы, вместо этого располагаясь рядом с ними.
Нефиксированные (unobtrusive) скроллбары — такие, которые накладываются на контент. Они не отнимают экранное пространство у того, что находится в контейнерах, которым они принадлежат.

Стандартное поведение современных скроллбаров

По умолчанию и в iOS, и в Android скроллбары являются нефиксированными.

В macOS (в частности, речь идёт об актуальной на момент написания этого материала macOS Mojave) скроллбары скрыты до момента начала прокрутки элемента. Это — стандартное поведение системы в ситуации, когда к компьютеру не подключена мышь. Существует три варианта отображения скроллбаров (соответствующие настройки можно найти по адресу General > System Preferences ).

Настройки скроллбаров в macOS Mojave

Эти настройки, как удалось выяснить, контролируют поведение скроллбаров в браузерах Chrome, Firefox, и в новом Edge, основанном на Chromium.

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

Фиксированный скроллбар в macOS виден всегда и занимает некоторое экранное пространство

Нефиксированный скроллбар в macOS накладывается на контент в процессе прокрутки документа

Нефиксированный скроллбар в macOS скрыт в тот момент, когда документ не прокручивают

В Windows 10, по адресу Settings > Display > Simplify and personalize Windows , можно обнаружить похожие настройки.

Настройки скроллбаров в Windows 10

К сожалению, даже в том случае, когда включена опция Automatically hide scroll bars in Windows , она не оказывает влияния на Firefox, Chrome, Internet Explorer и Edge. В случае с Edge речь идёт и о варианте браузера, основанном на Chromium, и о варианте, основанном на EdgeHTML.

Обзор задачи

Вот как выглядит в Windows страница, которую мы рассматривали выше в macOS.

Скроллбары в Windows по умолчанию являются фиксированными. Они, кроме того, выглядят довольно-таки «тяжёлыми» с точки зрения дизайна. Они, в их стандартном варианте, гораздо шире, чем их собратья из macOS. Кроме того, цвет скроллбаров в Windows обычно соответствует системным настройкам, а не цветовой палитре веб-страницы.

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

Требования к проекту

Мы хотим разработать веб-приложение, скроллбары, используемые в котором, отличаются следующими особенностями:

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

Насколько далеко можно продвинуться, используя CSS?

Вот код элемента-контейнера, которому назначен класс overflowing-element , а также — CSS-код для его стилизации:

Если вам нужны нефиксированные скроллбары в Internet Explorer и в Edge, основанном на EdgeHTML, это значит, что вам пригодится свойство -ms-overflow-style: -ms-autohiding-scrollbar; . С его использованием всё будет работать так, как нужно (это достаточно просто — правда?).

Когда вышла iOS 13, то оказалось, что свойство -webkit-overflow-scrolling: touch может и не потребоваться для улучшения физики скроллинга. Хотя, если нужно поддерживать более старые версии iOS, от использования этого свойства лучше не отказываться.

Если говорить о CSS-свойствах, имеющих отношение к скроллингу, то тут, возможно, полезным будет почитать о свойстве overscroll-behavior. Оно позволяет управлять поведением системы при достижении границы элемента, поддерживающего прокрутку.

▍Firefox

Браузер Firefox поддерживает CSS-свойства без префиксов. Это — scrollbar-color и scrollbar-width.

В следующем примере, для понятности, используются CSS-переменные, которые не поддерживаются в Internet Explorer 11:

▍Chrome и Safari, браузер Edge, основанный на Chromium, и прочие браузеры

Браузеры, основанные на Webkit и Blink, поддерживают нестандартные псевдо-элементы, предназначенные для настройки скроллбаров:

Вот пример на CodePen, демонстрирующий возможности по настройке скроллбаров, выполняемой исключительно средствами CSS. А вот — пример, в котором демонстрируется стандартное поведение скроллбаров. Можете их сравнить.

CSS и немного JS

Мы можем добавить в проект небольшой объём JavaScript-кода, который позволяет узнать о том, является ли стандартный скроллбар фиксированным или нет. Выглядит это примерно так:

Если скроллбар является фиксированным — мы добавляем к элементу документа body класс layout-scrollbar-obtrusive . Этот класс можно использовать для того, чтобы настраивать свойства width и height только фиксированных скроллбаров. Это позволяет избегать описанного выше вмешательства в поведение скроллбаров. В ходе такого вмешательства скроллбары меняются и проект отходит от системных настроек, выполненных пользователем. Вот стиль для класса layout-scrollbar-obtrusive :

Здесь можно найти пример применения методики, предусматривающей совместное использование CSS и JavaScript. Вот, для сравнения, пример, демонстрирующий стандартное поведение системы.

Итоги: обзор решения задачи

На устройствах с сенсорными экранами, на которых применяются нефиксированные скроллбары (то есть — на iOS и Android-устройствах) мы просто пользуемся стандартным поведением скроллбаров.

В macOS у нас появляется возможность учитывать системные настройки, сделанные пользователем. Это означает, что мы не осуществляем непреднамеренного переключения между нефиксированными и фиксированными скроллбарами. Мы применяем стили лишь к фиксированным скроллбарам, которые видны всегда. Это позволяет нам приводить внешний вид страниц в соответствие с нашими требованиями к дизайну проекта.

В Windows, а именно — в браузерах Firefox и Chrome, нет стандартных нефиксированных скроллбаров, но тут можно, как и в других случаях, применить наш подход, предусматривающий использование исключительно возможностей CSS. Благодаря тому, что мы смогли выйти на работающие примеры использования скроллбаров, настраиваемых средствами CSS, нам удалось прийти к согласию с нашей командой дизайнеров. Мы остановились на компромиссном варианте и избежали использования тяжёлых JavaScript-решений.

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

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

Intro. Возможности системного скрола.

Чтобы было от чего отталкиваться, я приведу простой пример (посмотреть в работе):

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

Стоит ли это все или часть этого реализовывать средствами js, чтобы изменить внешний вид скроллбаров?
да: потому что есть новые идеи для навигации по контенту, тяга к экспериментам с js и т.д.
нет: браузер уже все это делает и нужно найти способ, как это использовать. Вот об этом я и расскажу ниже.

Решение имеет следующую структуру на html:

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

корневой блок является оберткой для всей конструкции и определяет область и размеры всей конструкции в целом;
viewport — этим блоком ограничена область просмотра контента;
systemscrolls — этот блок отвечает за прокрутку контента;
contentwrap — это корректирующий блок (о его смысле и возможностях ниже);
content — непосредственно сам контент;
vtrack и htrack — вертикальный и горизонтальный скроллбары. С их содержимым и так все понятно.

Основная тяжесть: операции Scroll и Resize

На мой взгляд, это самые «тяжелые» и неудобные в реализации на javascript операции. Почему? Чтобы программно реализовать Resize и сохранение пропорций нужно, в основном, обрабатывать событие window.onresize, а во время возникновения этого события — корректировать размеры и пропорции у нескольких элементов (чаще всего так…). Недостатком ресайза подобным образом является неплавное (с небольшими непостоянными, заметными глазу, шагами) изменение размеров элемента, кто пытался подобное отладить — поймет меня. Это сильно «напрягает» глаза, когда вкладываешь душу в разработку и стараешься довести работу всего интерфейса до идела.

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

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

О Scroll. Для реализации scroll на desktop-браузерах необходимо обрабатывать событие колеса мыши и анализировать значения от этого события (также не забывать, что некоторые мыши позволяют листать контент в горизонтальной плоскости, а не только в вертикальной), а для mobile-браузеров нужно обрабатывать события группы touch. Т.е. для кроссплатформенного решения нужно программировать две эти реализации. Но лучше прокрутку контента возложить на сам браузер. Достаточно определить стиль для элемента systemscrolls:

Скрытие системных скроллбаров и 22px

Решая задачу прокрутки контента, я использовал свойство overflow:scroll, которое заставляет браузер отображать скроллбары всегда и тем самым предоставляет пользователю все удобства системной прокрутки. Но теперь нужно эти скроллбары скрыть. Здесь как раз и выручит viewport — этот блок будет скрывать всё, что выходит за его пределы. Это можно сделать двумя способами:

Первый вариант с overflow прост для понимания, но когда пользователь захочет выделить контент и начнет тянуть курсор в нужную сторону, то он, вполне вероятно, увидит системные скроллбары, т.к. при таком действии они вылезут из-под скрываемой области. Вариант с clip таким не страдает, но в этом случае пришлось применить небольшой хак и для поддержки ie7. Но это ещё не всё… Блок systemscrolls имеет такие же размеры, как и блок viewport, т.е. системные скроллбары еще видны. Здесь и используется ключевой момент «22px» — это величина, на которую будет скорректирован блок systemscrolls. Дело в том, что толщина скроллбаров у популярных браузеров менее 21px. Сама корректировка выглядит так:

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

И что в итоге? Браузер сам изменяет и следит за размерами всего элемента, контент легко и плавно прокручивается всеми описанными выше способами, а системные скроллбары скрыты. Но если это оставить в таком виде, то часть контента справа и снизу отображаться не будет…

Блок contentwrap

Основное и главное назначение блока contentwrap — это сделать так, чтобы в блоке viewport можно было увидеть блок content полностью: от одного края до другого при разных способах прокрутки.
До этого момента javascript не требовался, но сейчас он пригодится для того, чтобы скорректировать размеры блока contentwrap.

таким образом, размеры элемента contentwrap будут получаться из сложения этих величин с размерами блока content, и делать это будет нужно при каждом изменении размеров блока content. Есть исключения, но о них будет рассказано ниже.
Корректировка блока contentwrap с помощью js позволяет не обращать внимания на вид и версию браузера и используемую им толщину скроллбаров.

Блоки vscroll и hscroll

vscroll и hscroll — скроллбары. На данный момент, основная задача — «приклеить» их к краям и заставить их изменять свои размеры и местоположение их дочерних элементов за счет браузера:

в этом листинге нет ничего сложного и я перейду к более интересной части: бегунки.

Бегунки

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

Изменение положения бегунка при прокрутке контента

Это сделать крайне просто. Благодаря установленному свойству overflow:scroll у блока systemscrolls можно ловить собитие scroll на этом блоке, а уже при возникновении этого события двигать бегунок в зависимости от положения (свойства scrollLeft и scrollTop) контента относительно левой верхней точки блока systemscrolls с учетом коэффициента пропорциональности, который вычисляется в функции обновления параметров компонента (об этом будет ниже).

Перетаскивание бегунков

поймать событие mousedown на самом бегунке
подключить события mousemove и mouseup на элемент document
обрабатывать событие document.mousemove, тем самым изменяя положение бегунка и пролистывая контент
поймав событие document.mouseup — отключить события mousemove и mouseup на элемента document

событие scroll от элемента systemscrolls. Оно возникает следующим образом: чтобы пролистывать контент с помощью js, нужно изменять свойства scrollLeft и scrollTop у блока systemscrolls, а изменение этих свойств приведет к выбросу события scroll у этого блога. Таким образом сработает алгоритм по изменению положения бегунка при прокрутке контента, который описан выше.
после того, как будет поймано событие mousedown на бегунке, нужно отключить обработку события scroll на элементе systemscrolls, а элементы бегунков двигать по событию mousemove на элементе document одновременно пролистывая контент изменением свойств scrollLeft и scrollTop у блока systemscrolls.

При втором способе можно получить гораздо лучший результат. Дополнительные операции по отсоединению и присоединению события systemscrolls.scroll происходят только два раза: на события mousemove и mouseup (соответственно) элемента document. Таким образом, обработка события document.mousemove происходить быстрее и оптимальнее (см. рисунок)

Обновление параметров компонента

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

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

инициализация
изменение размеров окна браузера
изменение контанта

Кастомизация

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

обобщающие классы scrollar-scroll, scrollar-btn, scrollar-track и scrollar-thumb позволяют задавать общие стили как для вертикального, так и для горизонтального скроллбаров (например, задав scrollar-btn < display: none;>можно скрыть кнопки);
scrollar-btn и scrollar-track фиксируются относительно родительского элемента scrollar-scroll, что позволяет изменять их положение и их размеры, а также размеры scrollar-scroll, за счет браузера;
элемент scrollar-track не требует стилизации, т.к. он предназначен для определения области движения бегунка scrollar-thumb, но при желании можно и к этому элементу применить стили;
элементы позиционируются абсолютно (position: absolute) относительно scrollar-scroll, что позволяет размещать их относительно друг друга весьма легко;

А если горизонтальный или вертикальный скрол не нужен?

Все просто: при инициализации компонента нужно указать какой скрол не нужен (по умолчанию — оба отображаются). Управление видимостью и скролов производится с помощью добавления или удаления классов. Также добавление этих классов влияет на размеры контента (например, при hscroll: false ширина контента будет меняться автоматически за счет нативного функционала браузера)

Как менять контент?

content(«html», "Abcd") — заменит содержимое в области прокрутки на параграф с текстом, при этом обновление параметров компонента произойдет мгновенно, сразу по завершению функции;
content().html("Abcd") — эффект будет таким же, как и в предыдущем примере, но обновление контента произойдет за счет setInterval, в крайнем случае можно принудительно вызвать функцию update()

Ссылки к статье:

Customization — на этой странице можно посмотреть несколько вариантов кастомизации, а также можно опробовать реакцию элемента прокрутки на изменение размеров окна браузера.
GitHub — репозиторий, где можно найти всё, что описывалось в статье
Default style — пример произвольной стилизации
Safari style — стилизация скроллбаров в стиле Mac OS 10.8

Как определить высоту горизонтальной полосы прокрутки или ширину вертикальной полосы прокрутки в JavaScript?

21 ответ

Из блога Александра Гомеса я не пробовал. Дайте мне знать, если это работает для вас.

Если у вас уже есть элемент с полосами прокрутки, используйте:

Если горизонтальная полоса прокрутки отсутствует, функция вернет 0

Это возвращает высоту полосы прокрутки оси X.

Вы можете определить полосу прокрутки window с помощью document , как показано ниже, используя jquery + javascript:

С ванильным JavaScript.

Если вы ищете простую операцию, просто смешайте обычный dom js и jquery,

Возвращает размер полосы прокрутки текущей страницы. (если он виден или еще вернет 0)

Дает мне 17 на моем сайте, 14 здесь, на Stackoverflow.

Это единственный найденный мной скрипт, который работает в браузерах webkit . :)

И вы должны позвонить, когда документ будет готов . так

Протестировано 2012-03-28 на Windows 7 в последних версиях FF, Chrome, IE & Safari и работает на 100%.

С помощью jquery (проверено только в Firefox):

Но мне больше нравится ответ @ Стива.

Создайте пустой div и убедитесь, что он присутствует на всех страницах (т.е. поместите его в шаблон header ).

Дайте ему этот стиль:

Не нужно ничего вычислять, так как у этого div всегда будут width и height из scrollbar .

Единственным недостатком является то, что в ваших шаблонах будет пустой div . Но, с другой стороны, ваши файлы Javascript будут чище, так как это займет всего 1 или 2 строки кода.

Уже закодированы в моей библиотеке, так что вот оно:

Я должен отметить, что jQuery $(window).width() также может использоваться вместо window.document.documentElement.clientWidth .

Это не работает, если вы открываете инструменты разработчика в Firefox справа, но преодолевает это, если окно разработчика открывается внизу!

Вот более краткое и простое для чтения решение, основанное на разнице ширины смещения:

Читайте также: