какая основная функция полосы прокрутки

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

Автор — Нолан Лоусон, менеджер проекта 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 во всех тестах, за исключением скроллинга полосой прокрутки. Надеемся, остальные браузеры тоже сделают улучшения в реализации прокрутки и сделают веб быстрее и более восприимчивым!

Источник

history 9 ноября 2014 г.

Для вставки элементов управления на лист необходимо отобразить вкладку Разработчик.

Обратите внимание, что в этом меню можно также вставить Элементы ActiveX, которые расположены ниже интересующих нас Элементов управления формы. У обоих типов есть одни и те же элементы Кнопка, Список, Флажок и т.п. Разница между ними следующая: чтобы использовать Элементы ActiveX необходимо использовать VBA, а Элементы управления формы можно напрямую привязать к ячейке на листе.

Вставка Полосы прокрутки

После этого выпадающее меню закроется, а курсор вместо обычного толстого крестика

превратится в тонкий крестик.

Кликнув левой клавишей мыши в нужное место на листе, элемент Полоса прокрутки будет помещен на лист (вертикально).

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

Выделение Полосы прокрутки

Перемещение Полосы прокрутки и изменение ее размеров

Если навести курсор на углы прямоугольника или на маленькие квадратики на границе, то можно изменить ее размер.

Связываем Полосу прокрутки с ячейкой

Как было сказано выше, все Элементы управления формы возвращают значение. Это значение помещается в ячейку определенную пользователем. Чтобы связать Элемент управления с ячейкой, кликните на него ПРАВОЙ клавишей мыши, в появившемся контекстном меню выберите Формат объекта. Появится диалоговое окно, выберите вкладку Элемент управления (если такая вкладка отсутствует, то Вы вставили Элемент ActiveX, а не Элемент управления формы, об этом см. выше).

Также установим минимальное значение =1, максимальное =101, шаг изменения =2, шаг изменения по страницам =10.

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

Использование Полосы прокрутки

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

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

При нажатии на Полосу прокрутки (кнопки), значение в связанной ячейке А1 будет увеличиваться/ уменьшаться на 1 (шаг), следовательно, будет отображен следующий/ предыдущий месяц. При нажатии на Полосу прокрутки (полоса), значение в связанной ячейке А1 будет увеличиваться/ уменьшаться на 3 (шаг страницы), следовательно, будет отображен месяц, отстоящий на 3 месяца вперед или назад. Это реализовано с помощью формулы =СМЕЩ($B19;;$A$1-1) в ячейке В8 и ниже.

Этот месяц будет выделен в исходной таблице.

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

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

Прячем Полосу прокрутки на листе

Включите Область выделения ( Главная / Редактирование/ Найти и выделить )

В Области выделения можно управлять отображением не только Элементов управления, но и других объектов на листе, например рисунков.

Нажмите на изображение глаза напротив имени объекта и объект исчезнет/ появится.

Расширяем возможности Полосы прокрутки

Чтобы иметь возможность изменять значение в ячейке с шагом 0,1 используйте формулу =A31/10 ( Полоса прокрутки связана с ячейкой А31 ).

Источник

Полоса прокрутки. Эффективное использование элементов управления

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

Бегунок полосы прокрутки – маленький, перемещаемый прямоугольник, который указывает текущее положение и нередко масштаб «территории», по которой может быть осуществлено перемещение.

Недостатки применения полосы прокрутки

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

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

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

Возможности полосы прокрутки

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

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

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

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

Узнайте как эффективно использовать все элементы управления на нашем тренинге “Эффективное использование элементов управления”

Материалы по теме

Источник

Элементы управления «Средство прокрутки»

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

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

В зависимости от ситуации, полоса прокрутки средства прокрутки использует две различные визуализации, показанные на следующем рисунке: индикатор сдвига (слева) и традиционную полосу прокрутки (справа).

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

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

Примеры

Если у вас установлено приложение галереи элементов управления XAML, щелкните здесь, чтобы открыть приложение и увидеть ScrollViewer в действии.

Создание средства прокрутки

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

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

ScrollViewer в шаблоне элемента управления

Обычно элемент управления ScrollViewer является составной частью других элементов управления. Объект ScrollViewer с классом поддержки ScrollContentPresenter будет отображать окно просмотра вместе с полосами прокрутки только тогда, когда пространство макета основного элемента управления имеет меньший размер, чем размер развернутого содержимого. Такая ситуация часто возникает со списками, поэтому шаблоны ListView и GridView всегда содержат ScrollViewer. Шаблоны TextBox и RichEditBox также включают ScrollViewer.

Если в элементе управления имеется ScrollViewer, основной элемент управления зачастую имеет встроенную функцию обработки событий для определенных событий и манипуляций ввода, позволяющую прокручивать содержимое. Например, GridView интерпретирует жест прокрутки, что приводит к горизонтальной прокрутке содержимого. События и необработанные манипуляции ввода, получаемые основным элементом управления, считаются обработанными элементом управления, а события более низкого уровня, такие как PointerPressed, не будут вызываться и не будут передаваться в какие-либо родительские контейнеры. Вы можете изменять некоторые параметры обработки встроенных элементов управления, переопределяя класс элементов управления и виртуальные методы OnEvent для событий или изменяя шаблон элемента управления. Но в любом случае не рекомендуется просто воспроизводить исходное поведение по умолчанию, которое обычно там присутствует, чтобы элемент управления мог расширенно реагировать на события и на выполняемые пользователем действия и жесты ввода. Поэтому необходимо подумать о том, нужно ли вам на самом деле, чтобы это событие ввода срабатывало. Вы можете проверить, имеются ли другие события ввода или жесты, которые не обрабатываются элементом управления, и использовать их в своем приложении или схеме взаимодействия элементов управления.

Чтобы позволить элементам управления, имеющим в своем составе ScrollViewer, влиять на поведение и свойства, имеющие отношение к ScrollViewer, элемент ScrollViewer определяет несколько подключенных свойств XAML, которые можно настраивать в стилях и использовать в привязках шаблонов. Подробнее о подключенных свойствах см. в разделе Общие сведения о подключенных свойствах.

Подключенные свойства XAML для ScrollViewer

ScrollViewer определяет следующие подключенные свойства XAML:

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

Например, вот как можно сделать вертикальные полосы прокрутки всегда видимыми во встроенном средстве прокрутки в ListView.

Источник