что такое скролл бар

Элемент управления ScrollBar

Возвращает или устанавливает значение другого элемента управления на основании положения полосы прокрутки.

Примечания

ScrollBar — это отдельностоящий элемент управления, который можно поместить на форму. Это визуально похоже на панели прокрутки, которые вы видите в определенных объектах, таких как ListBox или выпадаемой части ComboBox. Однако, в отличие от полос прокрутки в этих примерах, элемент ScrollBar не является частью другого объекта.

Чтобы с помощью Панели прокрутки установить или прочитать значение другого управления, необходимо написать код для событий и методов ScrollBar. Например, чтобы с помощью панели прокрутки обновить значение TextBox, можно написать код, который считыет свойство Value из scrollBar, а затем задает свойство Value textBox.

Стандартное свойство объекта ScrollBar — Value. Стандартное событие объекта ScrollBar — Change.

Чтобы создать горизонтальный или вертикальный объект ScrollBar, перетащите его маркеры изменения размерана форме по горизонтали или по вертикали.

См. также

Поддержка и обратная связь

Есть вопросы или отзывы, касающиеся Office VBA или этой статьи? Руководство по другим способам получения поддержки и отправки отзывов см. в статье Поддержка Office VBA и обратная связь.

Источник

Заходят как-то два браузера в скроллбар…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обзор задачи

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

Страница со скроллбаром в Windows

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

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

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

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

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

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

▍Firefox

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

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

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

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

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

Надо отметить, что у вышеприведённого кода есть одна проблема. Она заключается в том, что при установке свойств height или width псевдо-элемента ::-webkit-scrollbar в macOS производится замена нефиксированного скроллбара на фиксированный (происходит переопределение стандартных настроек). Однако это несложно исправить с помощью небольшого фрагмента JavaScript-кода.

CSS и немного JS

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

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

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

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

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

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

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

Источник

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

Содержание

История и прогресс

В 1974 году перемещение курсора к левому краю при использовании Bravo изменило его форму на двунаправленную стрелку, чтобы обеспечить возможность прокрутки. Нажатие левой или верхней красной кнопки прокручивает содержимое вверх, а строка рядом с курсором перемещается в верхнюю часть окна. Нажатие правой или нижней синей кнопки прокручивает содержимое вниз, а строка в верхней части окна спускается до курсора. Удерживание средней желтой кнопки изменяет курсор на большой палец, позволяя перейти к этому проценту документа с индикатором текущего размещения.

В 1977 году Smalltalk включил стабильную полосу прокрутки в левой части окна фокуса. Щелчок по правой половине полосы прокрутки перемещает содержимое вверх, а левая половина перемещает содержимое вниз. Большой палец в центре панели можно было плавно перетаскивать и отображать процент видимого содержимого; первая пропорциональная полоса прокрутки.

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

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

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

Также в 1985 году Viewpoint использовала правую кнопку для перемещения содержимого по процентам или по окну, а не по страницам.

В 1988 году компания Open Look создала большой палец лифта со стрелками прямо на нем. Щелчок по дорожке, перемещаемой по страницам, и автоповтор толкает указатель. Кабельные анкеры размещались в начале и конце документа, а центр лифта можно было перетащить.

В 1989 году NeXT переместил полосу прокрутки обратно в левую часть окна. Большой палец был пропорционального размера со стрелками вместе внизу панели. Действия повторяются автоматически, а нажатие клавиши alt перемещает содержимое по окну. Большой палец можно было перетащить, и использование клавиши Alt во время перетаскивания замедляло его движение.

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

В 2001 году Mac OS X 10.0 использовала пропорциональный большой палец и перемещала обе кнопки со стрелками в нижнюю часть панели.

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

В 2011 году Mac OS X 10.7 удалила кнопки с конца панели и была разработана так, чтобы больше походить на полосу прокрутки iOS. В том же выпуске Mac OS X 10.7 Apple представила «естественную прокрутку», что означает, что экран перемещается в том же направлении, что и пальцы пользователя, когда они используют жест прокрутки двумя пальцами. Если пальцы пользователя перемещаются вверх по трекпаду, контент на странице поднимается вверх, позволяя пользователю читать контент дальше по странице, и наоборот.

В версии Microsoft Word для Mac 2015 года были введены исчезающие полосы прокрутки. Размещение в документе больше не было видно, когда указатель мыши находился за пределами области панели, даже если рассматриваемое окно было в фокусе. Цель этого изменения состояла в том, чтобы соответствовать стандартным методам проектирования Mac по скрытию полосы прокрутки, когда она не нужна немедленно для целей иерархии информации.

Применение

Перетаскивание пальцем

Исторически сложилось так, что перетаскивание большого пальца является традиционным способом управления полосой прокрутки. Переместив курсор на большой палец на экране, а затем нажав и удерживая, большой палец можно перетащить. Это часто делается с помощью трекпада или левой кнопки мыши на обычной мыши или сенсорной панели. Перемещение курсора при нажатии вниз перемещает ползунок полосы прокрутки для просмотра различных разделов страницы. В приложениях, родных для OS X 10.11 (и некоторых предыдущих версий OS X), полосы прокрутки не отображаются в пользовательском интерфейсе, пока пользователь не использует другой метод прокрутки, например прокрутку двумя пальцами или клавиши со стрелками. Следовательно, пользователь должен сначала выполнить прокрутку с помощью одного из этих методов, а затем переместить курсор на ползунок, где бы он ни появился.

В Microsoft Windows перемещение мыши слишком далеко от большого пальца при перетаскивании приведет к сбросу положения прокрутки на предыдущее.

Колесо прокрутки

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

Клавиши со стрелками

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

Щелчок по желобу

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

Экранные кнопки со стрелками

В BeOS экранные кнопки прокрутки для обоих направлений появляются на обоих концах полосы прокрутки. В некоторых программах Microsoft Office дополнительные кнопки ⏪ и ⏩ могут использоваться для постраничной навигации.

Различные кнопки мыши

Тачпад Windows

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

Трекпад Mac

Альтернативные конструкции

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

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

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

Одновременная 2D-прокрутка

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

Настройка

WebKit также предоставляет множество псевдоклассов для изменения стиля полос прокрутки.

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

Ограничения и проблемы

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

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

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

Исследования

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

Источник

Прокрутка в вебе: букварь

Автор — Нолан Лоусон, менеджер проекта Microsoft Edge

Прокрутка — одно из самых древних взаимодействий в вебе. Задолго до появления методов pull-to-refresh и списков бесконечной загрузки скромная полоса прокрутки решила изначальную проблему масштабирования в вебе: как взаимодействовать с контентом, который распространяется за пределы доступной области просмотра?

Сегодня прокрутка всё ещё остаётся самым фундаментальным взаимодействием в Сети, и, возможно, самым неправильно понятым. Например, вы знаете разницу между следующими сценариями?

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

Многопоточный веб

Концептуально, веб является однопоточной средой. JavaScript блокирует DOM, а DOM блокирует JavaScript, потому что оба борются за один и тот же поток, часто называемый «основным потоком» или «потоком UI».

Например, если вы добавите этот (ужасный) сниппет JavaScript на страницу, то немедленно заметите ухудшение в работе:

Пока этот JavaScript крутится в бесконечном цикле, кнопки не работают, элементы форм не реагируют и даже анимированные GIF’ки тормозят — во всех смыслах и отношениях страница зависла. Можете изучить эффект в действии в простом демо.

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

Есть забавная аномалия: если попробовать прокрутку через тачскрин, то страница отлично прокручивается вверх и вниз, хотя JavaScript и блокирует всё остальное на странице. То же самое относится к прокрутке с тачпада, колесом мыши и прокрутке после захвата страницы курсором click-and-drag (в зависимости от браузера).

Каким-то образом некоторые действия по прокрутке могут изменять состояние страницы, в то время как всё остальное — кнопки, поля ввода данных, GIF’ы — полностью зависло. Как мы можем совместить это с нашей теорией однопоточного веба?

История двух потоков выполнения

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

С годами разработчики браузеров осознали, что выгрузка вспомогательной работы в фоновые потоки может дать значительную выгоду по плавности работы и чувствительности. Прокрутка настолько важна для ключевого опыта работы с браузером, что эту задачу быстро выбрали для такой оптимизации. В наше время все основные браузерные движки (Blink, EdgeHTML, Gecko, WebKit) поддерживают прокрутку за пределами основного потока выполнения в той или иной степени (Firefox последним присоединился к клубу, с версии Firefox 46).

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

Правда, у асинхронной прокрутки есть распространённый побочный эффект, который называют эффектом шахматной доски (checkerboarding). Он впервые проявился на в Safari для iOS в виде серых и белых клеток, словно с шахматной доски. В большинстве современных браузеров эффект проявляется как пустое пространство на экране, если вы осуществляете прокрутку быстрее, чем браузер может отрисовать страницу. Это не идеально, но это приемлемый компромисс, по сравнению с заблокированной, дёргающейся или неоткликающейся прокруткой.

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

Здесь будет поучительной небольшая история. Когда впервые вышли операционные системы вроде Windows и macOS, они допускали только один поток выполнения, и мало кто предвидел необходимость предусмотреть одновременный ввод. Только когда появились многоядерные машины, операционные системы начали встраивать параллелизм в свою архитектуру.

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

Однако в группе разработки Microsoft Edge мы делаем успехи, чтобы гарантировать плавный и восприимчивый скроллинг, независимо от его метода. В EdgeHTML 14 (который вошёл в состав Windows 10 Anniversary Update) мы поддерживаем фоновую прокрутку для следующих методов:

По результатам тестирования в Windows 10 (14393, Surface Book) и macOS Sierra (10.12, MacBook Air) мы получили следующие результаты:

Как демонстрирует* эта таблица, поведение прокрутки может драматически изменяться от браузера к браузеру, и даже от одной ОС к другой. Если вы тестируете один метод прокрутки только в одном браузере, то получите весьма неполные результаты производительности своего сайта, по сравнению с тем, как в реальности с ним работают пользователи!

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

Как прослушивающие процессы мешают прокрутке

Фоновая прокрутка даёт ощутимую прибавку в эффективности — прокрутка и JavaScript полностью разделены, позволяя им работать параллельно без помех друг другу.

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

Менее очевидно влияние такого примера:

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

Обратите внимание, что это относится не только к колесу мыши: на тач-устройствах прокрутка тоже может быть заблокирована прослушивающими процессами touchstart или touchmove.

Нужно быть осторожным, добавляя прослушивающие события на страницу, потому что они влияют на производительность!

Есть несколько интерфейсов JavaScript API, связанных с прокруткой, однако они не блокируют прокрутку. Событие scroll, хотя это в чём-то нелогично, не может блокировать прокрутку, потому что оно запускается после прокрутки, и поэтому является неотменяемым. Также и новый Pointer Events API, представленный в IE и Microsoft Edge, и который недавно начали внедрять в Chrome и Firefox, изначально спроектирован с целью избежать неумышленного блокирования прокрутки.

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

Глобальные и локальные прослушивающие процессы

В предыдущем примере мы видели случай глобального прослушивающего процесса (то есть прикреплённого к window или document). Но что насчёт прослушивающих процессов для индивидуальных элементов прокрутки?

Другими словами, представьте страницу, для которой работает прокрутка, но на странице есть отдельная область с собственной независимой прокруткой. Блокирует ли браузер прокрутку для всей страницы, если вы добавите прослушивающий процесс только в этой области?

Если вы проверите на простой демонстрационной странице, то заметите, что Microsoft Edge и Safari оставят плавную прокрутку для целого документа, если прослушивающий процесс для прокрутки находится в div с независимой прокруткой.

Вот таблица браузеров и их поведения:

Результаты показывают*, что для веб-разработчиков есть доступные оптимизации, чтобы получить пользу от этих функций браузеров. Вместо использования прослушивающих процессов wheel/touch для всего документа, предпочтительно добавить прослушивающие процессы в конкретный подраздел документа, так что прокрутка останется плавной для всех остальных частей страницы. Другими словами, вместо делегирования прослушивающих процессов wheel/touchstart на максимально высокий уровень, лучше всего изолировать их для элемента, где это нужно.

К сожалению, не все фреймворки JavaScript допускают такую практику — в частности, React, как правило, добавляет глобальный прослушивающий процесс ко всему документу даже если тот должен относиться только к части страницы. Однако есть открытый тикет конкретно для этой проблемы, и парни из React сказали, что с радостью примут пулл-реквест. (Уважение парням из React, которые так быстро среагировали на наше предложение)

Пассивный прослушивающий процесс

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

С таким подходом браузер будет обрабатывать прокрутку так, как будто прослушивающий процесс wheel вообще отсутствует. Эта функция уже доступна в последних версиях Chrome, Firefox и Safari, и должна скоро появиться в будущем релизе Microsoft Edge. (Обратите внимание, что нужно применять feature detection для поддержки браузеров, которые не распознают пассивные прослушивающие процессы).

Для некоторых событий (в том числе touchstart и touchmove) Chrome с версии 56 принял решение вмешиваться и сделал их пассивными по умолчанию. Имейте в виду эту незначительную разницу между браузерами, когда добавляете прослушивающие процессы!

Заключение

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

Во-первых, лучше не добавлять прослушивающие процессы wheel или touch к глобальным объектам document или window, а вместо этого добавлять их к меньшим элементам с индивидуальной прокруткой. Разработчикам также следует использовать пассивные прослушивающие процессы, где только возможно, с применением feature detection, чтобы избежать проблем совместимости. Использование Pointer Events (там есть polyfill) и прослушивающих событий scroll — тоже верный способ избежать непреднамеренной блокировки прокрутки.

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

Наша группа Microsoft Edge продолжит инновации в данной области, чтобы обеспечить плавную прокрутку для большего количества сайтов и пользователей. Скажем это для скромного скроллбара — самого старого и неоднозначного взаимодействия в вебе!

* Результаты получены на последней версии каждого браузера в феврале 2017 года. С тех пор Firefox 52 обновил поддержку прокрутки, и теперь соответствует поведению Edge 14 во всех тестах, за исключением скроллинга полосой прокрутки. Надеемся, остальные браузеры тоже сделают улучшения в реализации прокрутки и сделают веб быстрее и более восприимчивым!

Источник