Как называется полоса прокрутки в браузере
Обновлено: 04.07.2024
Хочу рассказать об одной, на мой взгляд, удобной и красивой вещи - возможности скрытия полосы прокрутки в браузере Google Chrome.
Для корректности следуют отметить, что версия браузера 69.0.3497.92 (Официальная сборка), (64 бит).
Данная возможность относится к экспериментальным или бета версиям функционала или настроек. Для активации необходимой перейти на страницу chrome://flags/ . Лучше это сделать путем копирования и вставки в омнибокс (адресная строка с расширенной функциональностью, да, давайте называть вещи своими именами, учиться и узнавать новое. Компьютерная грамотность довольно-таки полезная штука😊) данной ссылки.
В открывшейся вкладке через поисковую строку находим параметр Overlay Scrollbars . Кстати, присмотритесь к "скролбару" справа на вашей странице или снимке экрана снизу.
Как видно, по нашему поиску найдено целых три параметра:
Overlay Scrollbars
Flash Overlay Scrollbars After Any Scroll Update
Flash Overlay Scrollbars When Mouse Enter
В выпадающим меню всех трех настроек нужно выбрать Enabled и RELAUNCH NOW для активации взнесенных изменений. При перезагрузке браузера все ваши окна восстановятся.
После перезагрузки мы видим, какие функции у нас активны. Так же стали заметны изменения в полосе прокрутки.
. её просто нет. Появляется scrollbar в уменьшенном виде при использования колесика мыши. При наведении курсора полоса прокрутки увеличивается в размерах. Цвет полосы будет противоположным цвету фона страницы (темная или светлая.) Работает на Windows, Linux, Chrome OS.
Возникает вполне логичный вопрос: "Если эта штука работает, экономит свободное место и просто красиво выглядит, то почему она не активна по умолчанию? " На мой взгляд дело в не удобности изначального скрытия элементов управления на незнакомых ресурсах и понимании того, что браузером пользуется разные группы людей. Используя эту настройку 3+ месяцев сталкивался с подобным на новых для себя сайтах, особенно где присутствует еще и и горизонтальная прокрутка. Однако такая настройка имеет право на существование и со временем прежний вид полосы прокрутки будет вам казаться громоздким и устаревшим. Минимализм во всей красе!
На этом всё! Спасибо, что дочитали, подписывайтесь на канал и ставьте лайки чтобы не пропустить новые статьи и нарративы.
Прокрутка — одно из самых древних взаимодействий в вебе. Задолго до появления методов pull-to-refresh и списков бесконечной загрузки скромная полоса прокрутки решила изначальную проблему масштабирования в вебе: как взаимодействовать с контентом, который распространяется за пределы доступной области просмотра?
Сегодня прокрутка всё ещё остаётся самым фундаментальным взаимодействием в Сети, и, возможно, самым неправильно понятым. Например, вы знаете разницу между следующими сценариями?
- Пользователь прокручивает страницу двумя пальцами на тачпаде
- Пользователь прокручивает одним пальцем на тачскрине
- Пользователь прокручивает колесо мыши
- Пользователь щёлкает по полосе прокрутки и тянет её вниз и вверх
- Пользователь нажимает стрелки «вверх», «вниз», PageUp, PageDown и «пробел» на клавиатуре
Чтобы ответить на этот вопрос и понять, как реализовать наиболее плавную прокрутку для своего сайта, отступим на шаг понять и разберёмся, как браузеры разбираются с многопоточностью и вводом.
Концептуально, веб является однопоточной средой. 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) мы получили следующие результаты:
| Два пальца тачпад | Тач | Колесо мыши | Полоса прокрутки | Клавиатура | |
|---|---|---|---|---|---|
| Edge 14 (Windows) | Есть | Есть | Есть | Есть | Нет |
| Chrome 56 (Windows) | Есть | Есть | Есть | Нет | Нет |
| Firefox 51 (Windows) | Нет | Нет | Нет | Нет | Нет |
| Chrome 56 (MacOS) | Есть | N/A | Есть | Нет | Нет |
| Firefox 51 (MacOS) | Есть | N/A | Есть | Нет | Нет |
| Safari 10.1 (MacOS) | Есть | N/A | Есть | Нет | Нет |
Как демонстрирует* эта таблица, поведение прокрутки может драматически изменяться от браузера к браузеру, и даже от одной ОС к другой. Если вы тестируете один метод прокрутки только в одном браузере, то получите весьма неполные результаты производительности своего сайта, по сравнению с тем, как в реальности с ним работают пользователи!
В целом должно быть ясно, что у прокрутки особенное место в вебе и браузеры очень много работают, чтобы сделать её быстрой и восприимчивой. Однако, есть тонкие способы, как веб-разработчик может непреднамеренно отключить встроенные в браузер оптимизации. Посмотрим на то, как веб-разработчики могут влиять на прокрутку в браузере, по-хорошему и по-плохому.
Фоновая прокрутка даёт ощутимую прибавку в эффективности — прокрутка и JavaScript полностью разделены, позволяя им работать параллельно без помех друг другу.
Но каждый, кто немного разрабатывал веб-страницы, знает, как установить связь между JavaScript и прокруткой:
Когда мы добавляем прослушивающий процесс wheel, который вызывает event.preventDefault() , то он на 100% блокирует прокрутку, как для колеса мыши, так и для тачпада. И очевидно, если прокрутка заблокирована, то фоновая прокрутка тоже заблокирована.
Менее очевидно влияние такого примера:
Вы можете наивно подумать, что если функция не вызывает preventDefault() , то она вообще не может блокировать прокрутку или, в худшем случае, блокирует её только на время выполнения самой функции. Однако правда в том, что даже пустой прослушивающий процесс полностью блокирует прокрутку, пока не закончены все процессы JavaScript на этой странице, что вы можете проверить в этом демо.
Прослушивание колеса мыши не взаимодействует с нашей большой блокирующей операцией JavaScript, но у них общий цикл событий, так что фоновый поток выполнения должен ждать, пока закончится более длительная операция JavaScript, прежде чем получит ответ от функции прослушивания событий.
Почему он должен ждать? Ну, JavaScript — это динамический язык программирования, и браузер не может знать наверняка, что preventDefault() никогда не вызовут. Даже если для разработчика очевидно, что функция делает просто запись console.log() , разработчики браузеров предпочитают не оставлять шансов. На самом деле, даже пустая function() <> вызовет тот же эффект.
Обратите внимание, что это относится не только к колесу мыши: на тач-устройствах прокрутка тоже может быть заблокирована прослушивающими процессами touchstart или touchmove.
Нужно быть осторожным, добавляя прослушивающие события на страницу, потому что они влияют на производительность!
Есть несколько интерфейсов JavaScript API, связанных с прокруткой, однако они не блокируют прокрутку. Событие scroll, хотя это в чём-то нелогично, не может блокировать прокрутку, потому что оно запускается после прокрутки, и поэтому является неотменяемым. Также и новый Pointer Events API, представленный в IE и Microsoft Edge, и который недавно начали внедрять в Chrome и Firefox, изначально спроектирован с целью избежать неумышленного блокирования прокрутки.
Даже в тех случаях, когда нам действительно нужно прослушивать события wheel или touchstart, есть определённые хитрости, как веб-разработчики могут гарантировать работу прокрутки с максимальным качеством. Посмотрим на некоторые из этих хитростей.
В предыдущем примере мы видели случай глобального прослушивающего процесса (то есть прикреплённого к window или document). Но что насчёт прослушивающих процессов для индивидуальных элементов прокрутки?
Другими словами, представьте страницу, для которой работает прокрутка, но на странице есть отдельная область с собственной независимой прокруткой. Блокирует ли браузер прокрутку для всей страницы, если вы добавите прослушивающий процесс только в этой области?
Если вы проверите на простой демонстрационной странице, то заметите, что Microsoft Edge и Safari оставят плавную прокрутку для целого документа, если прослушивающий процесс для прокрутки находится в div с независимой прокруткой.
Вот таблица браузеров и их поведения:
| Два пальца тачпад | Тач | Колесо мыши | Click-and-drag | Клавиатура | |
|---|---|---|---|---|---|
| Десктопный Edge 14 (Windows) | Есть | Есть | Есть | Есть | Нет |
| Десктопный Chrome 56 (Windows) | Нет | Есть | Нет | Нет | Нет |
| Десктопный Firefox 51 (Windows) | Нет | Нет | Нет | Нет | Нет |
| Десктопный Chrome 56 (MacOS) | Нет | N/A | Нет | Нет | Нет |
| Десктопный Firefox 51 (MacOS) | Есть | N/A | Есть | Нет | Нет |
| Safari 10.1 (MacOS) | Есть | N/A | Есть | Нет | Нет |
Результаты показывают*, что для веб-разработчиков есть доступные оптимизации, чтобы получить пользу от этих функций браузеров. Вместо использования прослушивающих процессов wheel/touch для всего документа, предпочтительно добавить прослушивающие процессы в конкретный подраздел документа, так что прокрутка останется плавной для всех остальных частей страницы. Другими словами, вместо делегирования прослушивающих процессов wheel/touchstart на максимально высокий уровень, лучше всего изолировать их для элемента, где это нужно.
К сожалению, не все фреймворки JavaScript допускают такую практику — в частности, React, как правило, добавляет глобальный прослушивающий процесс ко всему документу даже если тот должен относиться только к части страницы. Однако есть открытый тикет конкретно для этой проблемы, и парни из React сказали, что с радостью примут пулл-реквест. (Уважение парням из React, которые так быстро среагировали на наше предложение)
Уход от глобальных прослушивающих процессов wheel/touchstart — это хорошая практика, но иногда такое просто невозможно, в зависимости от эффекта, которого вы пытаетесь добиться. И в некоторым роде выглядит глупо, что простое прослушивание событий заставляет браузер остановить весь мир, просто потому что существует гипотетическая вероятность вызова PreventDefault() , и он его ждёт.
К счастью, в браузерах начала появляться новая функция, когда веб-разработчики могут явно пометить прослушивающий процесс как «пассивный» и поэтому избежать ожидания:
С таким подходом браузер будет обрабатывать прокрутку так, как будто прослушивающий процесс 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 во всех тестах, за исключением скроллинга полосой прокрутки. Надеемся, остальные браузеры тоже сделают улучшения в реализации прокрутки и сделают веб быстрее и более восприимчивым!
Анимации, имеющие отношение к скроллингу веб-страниц, существуют уже многие годы. В последнее время подобные анимации стали распространённее. Возможно, дело тут отчасти в том, что устройства, используемые для работы в интернете, стали мощнее. Эти устройства способны нормально обрабатывать и выводить больше визуальных эффектов, чем раньше.
Существует множество технологий, связанных со скроллингом. Цель этой статьи заключается в том, чтобы дать обзор таких технологий и инструментов, которые помогут подобрать и создать то, что нужно в каждой конкретной ситуации. Я разделил бы технологии скроллинга на две широкие категории. В первую входят технологии для реализации специфических механизмов скроллинга, во вторую — технологии скроллинга общего назначения.
Технологии для реализации специфических механизмов скроллинга
В CSS существует несколько простых стандартных эффектов скроллинга, поддерживаемых современными браузерами. В некоторых случаях их применения может быть достаточно для того чтобы обеспечить особенные нужды некоего проекта.
▍CSS-свойство position: sticky
Если вам нужно, чтобы некий элемент не прокручивался бы вместе с остальным содержимым страницы, то при стилизации этого элемента достаточно применить свойство position: sticky . Это — простой и понятный приём, его поддержка встроена в современные браузеры. Но для того, чтобы это работало бы в IE и в некоторых мобильных браузерах, понадобится полифилл. Если вам интересна эта тема — взгляните на данный материал.
Синий элемент «упирается» в верхнюю часть контейнера и не прокручивается вместе с остальными элементами
Вот демонстрация такого скроллинга.
▍Эффект параллакса
Эффект параллакса — это, скорее, не особая технология, а специальный технический приём. Но, как бы там ни было, этот эффект может оказаться весьма кстати в тех случаях, когда нужно, чтобы при скроллинге разные части страницы двигались бы с разной скоростью. Данный приём хорошо описан в этом материале. Существует и немало примеров его реализации. Например — этот. Для меня главный минус этого приёма заключается в том, что сложно понять то, какие значения, дающие правильный эффект параллакса, нужно использовать для настройки перспективы и трансформаций.
Эффект параллакса: элементы движутся с разной скоростью.
Вот демонстрация эффекта параллакса.
▍Прокрутка с привязкой к определённым точкам
Использование скроллинга с точками привязки позволяет браузеру автоматически настраивать положение элементов, перемещая их в определённую позицию после того, как пользователь завершил обычную операцию скроллинга. Это может оказаться полезным в случаях, когда нужно, чтобы после завершения прокрутки некий элемент находился бы целиком в поле зрения пользователя. Однако соответствующий API пока ещё нестабилен, поэтому постарайтесь пользоваться самыми свежими его реализациями и с осторожностью относитесь к применению этого подхода к скроллингу в продакшне. Вот хорошая статья на эту тему.
Если пользователь, прокручивая содержимое, уводит элемент за верхнюю границу контейнера, браузер автоматически изменит положение элемента так, чтобы он был бы виден целиком
Вот демонстрация работы скроллинга с точками привязки.
▍Плавная прокрутка
Плавный скроллинг поддерживается средствами браузера при прокрутке страницы до определённого раздела с использованием метода window.scrollTo() в JavaScript, или даже с применением CSS-свойства scroll-behavior. В настоящее время для реализации плавного скроллинга со сглаживанием движений колеса мыши требуются специальные JavaScript-библиотеки. Но при применении таких библиотек нужно обеспечить их нормальное взаимодействие с другими технологиями скроллинга. Кроме того, использование плавного скроллинга — это далеко не всегда хорошая идея.
Технологии скроллинга общего назначения
В настоящее время нет способа, применяя лишь CSS, запускать какие-либо анимации скроллинга общего назначения, основываясь на позиции прокрутки (хотя имеется предложение, в соответствии с которым в отдалённом будущем в нашем распоряжении могут появиться некие анимации, основанные на технологиях скроллинга общего назначения). В результате, если вы хотите анимировать элементы при скроллинге, вам нужно, как минимум, использовать некоторый объём JavaScript-кода для достижения требуемого эффекта. Существуют два метода применения JavaScript для анимирования элементов при скроллинге. Первый заключается в использовании API Intersection Observer, второй — в обработке события scroll .
▍Использование API Intersection Observer
API IntersectionObserver позволяет с успехом решать различные задачи, связанные со скроллингом, в том случае, если всё, что нужно для запуска анимации, — это знание о том, видим ли элемент в области просмотра, а так же о том, какая именно часть элемента видима. Это делает API IntersectionObserver отличным инструментом для запуска анимации, сопровождающей появление элемента на экране. Но, даже так, некоторые эффекты очень сложно (хотя и можно) реализовать с помощью этого API. Например — это запуск разных анимаций в зависимости от направления движения элемента. Этот API, кроме того, не особенно полезен в ситуации, если при скроллинге нужно запускать анимацию тогда, когда элемент находится где-то в середине области просмотра, то есть, не появляется в области просмотра и не исчезает из неё.
▍Использование события scroll
Перед тем, кто, для реализации анимации при скроллинге, использует событие scroll , открываются очень большие возможности. Этот приём позволяет, при прокрутке, воздействовать на элемент при любом положении элемента относительно границ области просмотра. Используя событие scroll , можно очень точно, в соответствии с нуждами проекта, задавать позиции начала и окончания анимации.
Учитывая это, нужно отметить, что данный подход к анимации скроллинга может создать немалую нагрузку на систему. Так происходит в том случае, если разработчик не заботится о производительности и не ограничивает частоту обработки события scroll . Кроме того, в распоряжении программиста, который решит пользоваться событием scroll , не будет удобного API, позволяющего реализовывать различные сценарии скроллинга. Именно поэтому часто, вместо того, чтобы реализовывать механизмы обработки события scroll самостоятельно, есть смысл применить специализированную библиотеку, авторы которой уже позаботились и о влиянии обработки события scroll на производительность, и об API. Некоторые из этих библиотек даже способны помочь разработчику при возникновении проблем с размерами элементов
Инструменты для создания механизмов скроллинга общего назначения
Существует несколько мощных библиотек для реализации скроллинга, которые нацелены на то, чтобы дать разработчику полный контроль над анимациями, выполняемыми при прокрутке страниц, а так же на то, чтобы как можно сильнее облегчить разработчику жизнь, не заставляя его самостоятельно заниматься сложными вычислениями.
▍ScrollMagic
Библиотека ScrollMagic даёт нам сравнительно простой API, позволяющий создавать различные эффекты при скроллинге. Эта библиотека может работать совместно с различными библиотеками для анимации, наподобие GSAP и Velocity.js. Правда, в последние несколько лет эта библиотека недостаточно хорошо поддерживается. Это привело к тому, что была создана библиотека ScrollScene.
▍ScrollScene
ScrollScene — это, в сущности, обёртка, которая направлена на то, чтобы повысить удобство работы с библиотекой ScrollMagic и (или) с API IntersectionObserver. Здесь используется собственная версия ScrollMagic, которая отличается лучшей поддержкой, чем обычный вариант библиотеки. Тут имеются и дополнительные возможности, наподобие проигрывания видео и поддержки контрольных точек, влияющих на анимацию. Кроме того, эта библиотека использует GSAP.
▍ScrollTrigger
Библиотека ScrollTrigger — это официальный GreenSock-плагин для GSAP. Эта библиотека отличается большим набором возможностей, её API кажется мне самым простым из API существующих библиотек для скроллинга. Используя эту библиотеку, вы полностью контролируете то, где именно начинается и заканчивается анимация скроллинга, вы можете анимировать при прокрутке всё что угодно (WebGL, canvas, SVG, DOM), можете закреплять элементы на время выполнения анимации. Этим возможности данной библиотеки не ограничиваются. Кроме того, эту библиотеку поддерживает GreenSock, получить помощь по её использованию можно на форумах GreenSock.
▍Библиотека, достойная упоминания: Locomotive Scroll
Библиотека Locomotive Scroll не стремится к реализации столь же широкого набора возможностей, как другие библиотеки, о которых мы говорили. Её основная цель — реализация плавной прокрутки. Используя её, кроме того, можно анимировать некоторые свойства DOM-объектов, используя атрибуты data-* , или пользоваться обработчиком onscroll для анимирования объектов других видов.
Сравнение технологий и инструментов
Вот сравнение технологий скроллинга.
| API Intersection Observer | Плавная прокрутка | Точки привязки в CSS | CSS-эффект параллакса | CSS-свойство position: sticky | |
| Закрепление элементов | - | - | - | - | + |
| Эффект параллакса | - | - | - | + | - |
| Управление динамикой анимации | ± | - | - | ± | - |
| Использование контрольных точек | ± | - | + | - | - |
| Динамическая пакетная обработка элементов | + | - | - | - | - |
| Поддержка эффектов горизонтального скроллинга | + | + | + | + | + |
| Подходит для продакшна (хорошая браузерная поддержка) | ± | ± | ± | + | ± |
| Полная свобода в анимировании | - | - | - | - | - |
| Поддержка разработчиком | n/a | n/a | n/a | n/a | n/a |
| Работа с DOM, Canvas, WebGl, SVG | + | - | - | - | - |
| Поддержка изменения размеров элементов | + | + | + | + | + |
| Ограничивает анимацию только релевантным разделом | + | + | + | - | + |
| Различает направления скроллинга | ± | - | - | - | - |
| Технология, встроенная в браузер | + | + | + | + | + |
Вот сравнение рассмотренных библиотек.
| ScrollTrigger | Locomotive Scroll | ScrollScene | ScrollMagic | |
| Закрепление элементов | + | ± | + | + |
| Эффект параллакса | + | + | + | + |
| Управление динамикой анимации | + | ± | ± | ± |
| Использование контрольных точек | + | ± | ± | ± |
| Динамическая пакетная обработка элементов | + | - | + | - |
| Поддержка эффектов горизонтального скроллинга | + | + | + | + |
| Подходит для продакшна (хорошая браузерная поддержка) | + | ± | + | + |
| Полная свобода в анимировании | + | ± | + | + |
| Поддержка разработчиком | + | + | + | - |
| Работает с DOM, Canvas, WebGl, SVG | + | ± | + | + |
| Поддержка изменения размеров элементов | + | + | + | ± |
| Ограничивает анимацию только релевантным разделом | + | - | ± | ± |
| Различает направления скроллинга | + | ± | + | + |
| Технология, встроенная в браузер | - | - | - | - |
Итоги
Для реализации некоторых особых механизмов скроллинга, вроде закрепления элементов и эффекта параллакса, может быть достаточно стандартных возможностей CSS. По меньшей мере — это так при условии использования полифиллов для браузеров, которые соответствующие возможности CSS не поддерживают.
Я обычно, для настройки скроллинга, рекомендую использовать библиотеку ScrollTrigger. Она позволяет достичь всего, на что способен чистый CSS, а так же — многого другого. Эта библиотека берёт на себя заботу о браузерной поддержке тех или иных технологий, облегчает выполнение вычислений, что позволяет тому, кто её использует, просто заниматься своими делами.
Какие технологии вы используете при настройке скроллинга в своих проектах?
Скроллбар (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-решений.
В компьютерных дисплеях , кинопроизводстве , телевизионном производстве и других кинетических дисплеях прокрутка - это перемещение текста, изображений или видео по монитору или дисплею по вертикали или горизонтали. «Прокрутка», как таковая, не изменяет макет текста или изображений, но перемещает ( панорамирует или наклоняет ) вид пользователя по тому, что, по-видимому, является более крупным изображением, которое не полностью видно. Обычный спецэффект для телевидения и кино - это прокрутка титров, оставляя фон неподвижным. Прокрутка может происходить полностью без вмешательства пользователя (как в фильмах) или, на интерактивном устройстве, запускаться с помощью сенсорного экрана или нажатия клавиш и продолжаться без дальнейшего вмешательства до следующего действия пользователя или полностью контролироваться устройствами ввода .
Прокрутка может происходить дискретно (возможно, одна или несколько строк текста за раз) или непрерывно ( плавная прокрутка ). Частота кадров - это скорость, с которой повторно отображается все изображение. Это связано с прокруткой в том смысле, что изменения положения текста и изображения могут происходить только так часто, как изображение может быть повторно отображено. Когда частота кадров является ограничивающим фактором, одним из методов плавной прокрутки является размытие изображений во время движения, которые в противном случае выглядели бы «скачущими».
СОДЕРЖАНИЕ
Вычисление
Реализация
Парадигмы пользовательского интерфейса
В графическом интерфейсе пользователя (GUI) в стиле WIMP прокрутка, управляемая пользователем, осуществляется путем манипулирования полосой прокрутки с помощью мыши или использования сочетаний клавиш , часто клавиш со стрелками . Прокрутка часто поддерживается текстовыми пользовательскими интерфейсами и интерфейсами командной строки . Старые компьютерные терминалы изменяли все содержимое дисплея по одному экрану («странице») за раз; этот режим подкачки требует меньше ресурсов, чем прокрутка. Прокрутка дисплеев часто также поддерживает страничный режим. Обычно определенные клавиши или комбинации клавиш пролистывают вверх или вниз; на ПК-совместимых клавиатурах используются клавиши перехода по страницам вверх и вниз или пробел ; ранее компьютеры часто использовали комбинации клавиш управления . У некоторых компьютерных мышей есть колесо прокрутки , которое при прокрутке прокручивает дисплей, часто вертикально; у других есть шарики прокрутки или колеса наклона, которые позволяют как вертикальную, так и горизонтальную прокрутку.
Некоторое программное обеспечение поддерживает другие способы прокрутки. В Adobe Reader есть режим, обозначенный маленьким значком руки (« ручной инструмент ») на документе, который затем можно перетаскивать, щелкая по нему и перемещая мышь, как если бы он сдвигал большой лист бумаги. Когда эта функция реализована на сенсорном экране, это называется кинетической прокруткой . Сенсорные экраны часто используют инерционную прокрутку , при которой прокрутка объекта продолжается в затухающем режиме после отпускания касания, имитируя появление объекта по инерции . Ранняя реализация такого поведения была в КПК "Star7" компании Sun Microsystems ок. 1991–1992 гг.
Прокруткой можно управлять другими программно-зависимыми способами с помощью мыши ПК. Некоторые колесики прокрутки можно нажимать, работая как кнопки. В зависимости от программного обеспечения это позволяет выполнять как горизонтальную, так и вертикальную прокрутку путем перетаскивания в желаемом направлении; когда мышь перемещается в исходное положение, прокрутка останавливается. Несколько колесиков прокрутки также можно наклонять, прокручивая их по горизонтали в одном направлении, пока не отпустите. На устройствах с сенсорным экраном прокрутка - это жест с несколькими касаниями , выполняемый путем проведения пальцем по экрану вертикально в направлении, противоположном тому, куда пользователь хочет прокрутить.
Если какой-либо контент слишком велик для отображения на экране, для его просмотра требуется горизонтальная прокрутка. В таких приложениях, как графика и электронные таблицы, часто бывает больше содержимого, чем может поместиться либо по ширине, либо по высоте экрана в удобном масштабе, и необходима прокрутка в обоих направлениях.
Текст
На языках, написанных горизонтально , таких как большинство западных языков, текстовые документы длиннее, чем умещаются на экране, часто отображаются в упакованном виде и имеют размер, соответствующий ширине экрана, и прокручиваются по вертикали, чтобы отобразить желаемый контент. Можно отображать слишком длинные строки для отображения на экране без переноса, горизонтальная прокрутка для просмотра каждой строки целиком. Однако для этого требуется неудобная постоянная построчная прокрутка, в то время как вертикальная прокрутка нужна только после прочтения всего экрана.
Программное обеспечение, такое как текстовые процессоры и веб-браузеры, обычно использует перенос слов для отображения в одной строке такого количества слов, которое соответствует ширине экрана или окна или, для текста, организованного в столбцы, в каждом столбце.
Прокрутка текста, также называемая текстами прокрутки или скроллерами , сыграла важную роль в зарождении компьютерной демонстрационной культуры . В программном обеспечении крекеры часто использовали свои глубокие знания компьютерных платформ для преобразования информации , которая сопровождала их выбросы в трещинах интро . Единственная роль этих заставок заключалась в впечатляющей прокрутке текста на экране.
Многие скроллеры были простыми горизонтальными скроллерами, но разработчики демонстрационных программ также уделили много внимания созданию новых и различных типов прокрутки. Например, персонажи могут постоянно изменять свою форму, летать по необычным траекториям или использовать цветовые эффекты, такие как растровые полосы . Иногда это делает текст почти нечитаемым.
Кино и телевидение
Прокрутка обычно используется для отображения титров в конце фильмов и телепрограмм .
Видеоигры
В компьютерных и видеоиграх прокрутка игрового поля позволяет игроку управлять объектом в большой смежной области. Ранние примеры этого метода включают гоночную видеоигру Taito с вертикальной прокруткой 1974 года Speed Race , гоночные игры Moto-Cross ( Fonz ) и Road Race от Sega 1976 года с прямой прокруткой и Super Bug .
Namco Galaxian аркадная система введена с Galaxian в 1979 году впервые в спрайт систему, анимированный предварительно загруженных спрайтов над прокруткой фона, который стал основой для Nintendo «s Radar Scope и Donkey Kong аркадная оборудования и домашних консолей , таких как Nintendo Entertainment System .
Параллаксная прокрутка , которая впервые была представлена в Moon Patrol , включает несколько полупрозрачных слоев (называемых игровыми полями), которые прокручиваются друг над другом с разной скоростью, чтобы создать раннюю псевдо-трехмерную иллюзию глубины.
Прокрутка на поясе - это метод, используемый виграхbeat 'em upсбоковой прокруткойс направленным вниз углом камеры, где игроки могут перемещаться вверх и вниз, а также влево и вправо. Ранее широко использовавшейся альтернативой прокрутке видеоигр был методпереворота экрана.
Исследования
В статье 1993 года Джорджа Фицмориса изучались карманные компьютеры с функцией пространственного управления . У этих устройств был 3D-датчик, и перемещение устройства приводило к перемещению содержимого, как если бы содержимое было зафиксировано на месте. Это взаимодействие можно назвать «перемещением для прокрутки». Кроме того, если пользователь отодвинул устройство от своего тела, он увеличил бы масштаб; и наоборот, устройство уменьшится, если пользователь приблизит устройство к себе. В настоящее время этот метод используется в камерах смартфонов и при анализе изображений « оптического потока ».
В исследовательской статье 1996 года Джуна Рекимото операции наклона анализировались как методы прокрутки на интерфейсах с маленькими экранами. Пользователи могли наклонять не только для прокрутки, но и для выбора пунктов меню. Эти методы оказались особенно полезными для полевых работников, поскольку им нужно было держать устройство и управлять им одной рукой.
В более позднем исследовании 2013 года, проведенном Селиной Шармин, Олегом Шпаковым и Кари-Йоуко Ряихя, изучается действие чтения текста на экране во время автопрокрутки текста на основе паттернов отслеживания взгляда пользователя . Контрольная группа просто читала текст на экране и вручную прокручивала его. Исследование показало, что участники предпочитали читать в основном в верхней части экрана, поэтому экран прокручивался вниз всякий раз, когда глаза участников начинали смотреть в нижнюю часть экрана. Эта автопрокрутка не вызвала статистически значимой разницы в скорости чтения или производительности.
Читайте также: