Извиняюсь, обдумывал другую проблему, поэтому не до конца вник в смысл предыдущего комментария.
Сейчас довольно сильно отличается прокрутка колёсиком мыши основного контента, от эмулируемой прокрутки (когда указатель мыши находится над скроллбаром — упомянуто в топике), и отличия не только в различии шага прокрутки, но и в не очень хорошей поддержке JavaScript-обработки событий скроллинга мыши. Насколько я знаю, не во всех браузерах указывается отдельно указывается прокрученное растояние по осям X/Y (по крайней мере так написано в док-е по jQuery MouseWheel event).
Так что управление колёсиком мыши горизонтальным скроллом — это действительно нестандартное поведение. Меня всегда удивляло, почему если мышь находится над горизонтальным скроллом, прокрутка колёсиком продолжает прокручивать контент вертикально, а не горизонтально. Думаю, что подобное поведение было бы логичным.
Другой вопрос — то, что есть мыши, позволяющие прокручивать и по горизонтали, как в Вашем примере. Исходя из того, что я возможно не смогу отличить скролл по вертикали от скролла по горизонтали средствами JavaScript, считаете, что стоит отключить подобное поведение?
Планирую добавить по возможности отключение скролла всей страницы, если у контента прокручивается, т.к. мне тоже не нравится подобное поведение. Однако текущей задачей стояло сохранение родного поведения скролла браузера.
Изменил поведение на mousedown — это действительно удобнее, чем клик. Однако насколько необходима поддержка удерживания кнопки мыши нажатой на данном элементе — вот в чём вопрос.
А как именно начинает глючить? В чём проявляется?
Просто у меня во время тестирования на такой же конфигурации никаких отклонений от стандартного поведения не наблюдалось. Возможно я что-то упустил во время тестов.
Возможно тормозит изменение позиции бегунка скроллбара, но скролл контента тормозить не должен. Отличие JavaScript обёртки от полной эмуляции скролла в том, что в полной эмуляции вначале генерируется событие, которое изменяет всё почти одновременно, а в обёртке вначале браузер производит действие, потом генерирует событие, обрабатываемое JavaScript-ом.
Если же речь идёт об изменении размеров содержимого, то там стоит задрежка в 300 мс для пересчёта размеров скроллбара. Другого способа автоматически отловить изменение размеров контейнера я не нашёл.
Можно, конечно же, вызывать переинициализацию скролла и вручную сразу после изменения размеров контейнера/содержимого, но задача стояла именно в том, чтобы «подключить и забыть». По этой причине я не стал делать переинициализацию сразу же, а показываю то, что ожидает пользователя при практическом применении.
Если задержка критична, можно вручную вызывать переинициализацию нужного контейнера после обновления.
Довольно сложно обработать все нативные события скролла. Для обработки подобных событий необходимо подключать дополнительную библиотеку обработки событий мыши, чего мне очень не хотелось делать так же, как и увеличивать размер плагина. По этой причине я ограничился минимальным необходимым для эмуляции фукнцоиналом.
Если честно, то сейчас меня больше интересует проблема несоответствия прокручивания когда мышь находится над стилизованным скроллом по той причине, что в большинстве дизайнерских проектов у скролла стрелочек нет вообще, да и сами пользователи редко пользуются функционалом, выходящим за рамки простого клика.
На самом деле этот вопрос довольно сложен — в некоторых случаях необходимо избавиться от скроллбара в центре сайта, т.к. это портит весь дизайн. Про замену системного скроллбара, который скроллит всю страницу, здесь речи не идёт.
jScrollPane отличный плагин, сталкивался с ним. Но на тот момент, когда мы им пользовался, сталкивался с проблемами переинициализации скролла, после того, как контейнер становился невидимым или изменял свой размер.
Что именно тормозит? Какие действия производите?
Для сравнения справа есть две кнопки Init и Destroy для возможности сравнить с оригинальным поведением скролла.
Сейчас довольно сильно отличается прокрутка колёсиком мыши основного контента, от эмулируемой прокрутки (когда указатель мыши находится над скроллбаром — упомянуто в топике), и отличия не только в различии шага прокрутки, но и в не очень хорошей поддержке JavaScript-обработки событий скроллинга мыши. Насколько я знаю, не во всех браузерах указывается отдельно указывается прокрученное растояние по осям X/Y (по крайней мере так написано в док-е по jQuery MouseWheel event).
Так что управление колёсиком мыши горизонтальным скроллом — это действительно нестандартное поведение. Меня всегда удивляло, почему если мышь находится над горизонтальным скроллом, прокрутка колёсиком продолжает прокручивать контент вертикально, а не горизонтально. Думаю, что подобное поведение было бы логичным.
Другой вопрос — то, что есть мыши, позволяющие прокручивать и по горизонтали, как в Вашем примере. Исходя из того, что я возможно не смогу отличить скролл по вертикали от скролла по горизонтали средствами JavaScript, считаете, что стоит отключить подобное поведение?
Просто у меня во время тестирования на такой же конфигурации никаких отклонений от стандартного поведения не наблюдалось. Возможно я что-то упустил во время тестов.
Если же речь идёт об изменении размеров содержимого, то там стоит задрежка в 300 мс для пересчёта размеров скроллбара. Другого способа автоматически отловить изменение размеров контейнера я не нашёл.
Можно, конечно же, вызывать переинициализацию скролла и вручную сразу после изменения размеров контейнера/содержимого, но задача стояла именно в том, чтобы «подключить и забыть». По этой причине я не стал делать переинициализацию сразу же, а показываю то, что ожидает пользователя при практическом применении.
Если задержка критична, можно вручную вызывать переинициализацию нужного контейнера после обновления.
Если честно, то сейчас меня больше интересует проблема несоответствия прокручивания когда мышь находится над стилизованным скроллом по той причине, что в большинстве дизайнерских проектов у скролла стрелочек нет вообще, да и сами пользователи редко пользуются функционалом, выходящим за рамки простого клика.
Для сравнения справа есть две кнопки Init и Destroy для возможности сравнить с оригинальным поведением скролла.