Настройка колесика в браузере

Обновлено: 06.01.2025

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

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

Сочетания кнопок

Нажмите правую кнопку мыши. Удерживая ее, нажмите левую кнопку.

Нажмите левую кнопку мыши. Удерживая ее, нажмите правую кнопку.

Нажмите Ctrl и прокрутите колесо мыши вперед.

Нажмите Ctrl и прокрутите колесо мыши назад.

Нажмите правую кнопку мыши. Удерживая ее, нажмите левую кнопку.

Нажмите левую кнопку мыши. Удерживая ее, нажмите правую кнопку.

Нажмите Ctrl и прокрутите колесо мыши вперед.

Нажмите Ctrl и прокрутите колесо мыши назад.

Отключение жестов

В блоке Жесты мыши оставьте неактивной опцию Включить .

Невозможно отключить жесты мыши, которые встроены в операционную систему:

Чтобы отключить жесты перелистывания в macOS, нажмите  → Системные настройки  → Трекпад  → Другие жесты и отключите опцию Смахивание между страницами .

Настройки жестов

Вы можете отключить отдельные движения или сочетания кнопок.

Зависает курсор мыши в онлайн-игре

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

В блоке Жесты мыши оставьте неактивной опцию Включить .

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

">,"extra_meta":[>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>],"title":"Жесты мыши. Справка","canonical":"https://browser.yandex.ru/help/useful-features/gestures.html","productName":"Яндекс.Браузер","extra_js":[[],[,"mods":<>,"__func134":true,"tag":"script","bem":false,"attrs":,"__func61":true>],[,"mods":<>,"__func134":true,"tag":"script","bem":false,"attrs":,"__func61":true>]],"extra_css":[[],[,"mods":<>,"__func63":true,"__func62":true,"bem":false,"tag":"link","attrs":>],[,"mods":<>,"__func63":true,"__func62":true,"bem":false,"tag":"link","attrs":>]],"csp":<"script-src":[]>,"documentPath":"/help/useful-features/gestures.html","isBreadcrumbsEnabled":true,"lang":"ru","params":<>>>>'>Движения мыши

Сочетания кнопок

Нажмите правую кнопку мыши. Удерживая ее, нажмите левую кнопку.

Нажмите левую кнопку мыши. Удерживая ее, нажмите правую кнопку.

Нажмите Ctrl и прокрутите колесо мыши вперед.

Нажмите Ctrl и прокрутите колесо мыши назад.

Нажмите правую кнопку мыши. Удерживая ее, нажмите левую кнопку.

Нажмите левую кнопку мыши. Удерживая ее, нажмите правую кнопку.

Нажмите Ctrl и прокрутите колесо мыши вперед.

Нажмите Ctrl и прокрутите колесо мыши назад.

Отключение жестов

Нажмите → Настройки → Инструменты . В блоке Жесты мыши оставьте неактивной опцию Включить .

Невозможно отключить жесты мыши, которые встроены в операционную систему:

Чтобы отключить жесты перелистывания в macOS, нажмите → Системные настройки → Трекпад → Другие жесты и отключите опцию Смахивание между страницами .

Настройки жестов

Вы можете отключить отдельные движения или сочетания кнопок.

Нажмите → Настройки → Инструменты .

Зависает курсор мыши в онлайн-игре

Нажмите → Настройки → Инструменты . В блоке Жесты мыши оставьте неактивной опцию Включить .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Блок contentwrap

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

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

Блоки vscroll и hscroll

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

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

Бегунки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем привет!

К понедельнику мы не успели выпустить сборку — нашли несколько очень неприятных багов, с которыми не хотелось бы вас знакомить. :-)

Но сегодня мы исправляемся и предлагаем вашему вниманию очередную версию — Vivaldi 1.0.209.3. В данной сборке есть много как внешне заметных изменений, так и улучшений, о которых надо бы сказать отдельно. Итак, обо всём по порядку.

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

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

Больше цвета, больше возможностей

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

Настройки клавиатурного управления

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

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

Мышь — это не просто мышь.

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

Также небольшая радость для пользователей Linux: теперь вы можете попробовать использовать кнопки мыши для перемещения по истории посещений текущей страницы или сайта.

Осторожно — баги!

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