Рад, что кому-то статья пригодится. А алерт — это для наглядности. Большинство примеров рассчитаны на то, что их даже не придётся вбивать в браузер — их поведение и так понятно. Да и для начинающих, имхо, легче понять с алертом, чем с логом в консоли.
Собственно, кастомные скроллбары — это пожелание заказчика или требование дизайна. И если в дизайне есть кнопочки, то функционал придётся допиливать вручную, разбираясь в чужом коде — не слишком приятная перспектива, не правда ли?
Помимо этого есть и другие события: скролл мыши над скроллбаром и клики на подложке скроллбара для более быстрой перемотки.
У меня через некоторое время скролл начинает подвешивать браузер Хром (Windows 7 x64, Google Chrome 26).
Функция апдейта, которая заниматся проверкой изменения размера, должна совершать минимальное количество действий, иначе даже при небольшом количестве скроллов на странице, загрузка процессора будет очень большой.
Также, если я изменяю содержимое контейнера (а конекретно — удаляю картинки), скроллы не исчезают, когда размер контейнера становится меньше видимой области.
И, конечно же, 5 вложенных див-ов — это, имхо, нехорошо.
У baron-а есть небольшой недостаток — для работы горизонтального скролла необходимо указывать высоту, будь она в пикселях или в процентах, но быть должна. И, к сожалению, статью до сих пор не обновили, что барон поддерживает и горизонтальный скролл. Также нет контролов — а тут есть их реализация, пусть и минимальная.
Насчёт велосипедов — почему бы и нет, если делается какое-то новое решение? Ведь, как говорится, в споре рождается истина. Видимо в последнее время заказчики стали больше просить делать кастомные скроллбары, и существующие решения не подходили, оттуда и велосипеды.
К сожалению, я не могу принять Ваши изменения, т.к. придерживаюсь политики минимального вмешательства в оригинальное поведение элементов, а данное решение изменяет содержимое оригинального контейнера, оборачивая его содержимое в подконтейнер.
Как Вы видели в обсуждении, даже минимально необходимое вмешательство в структуру HTML может привести к недопониманию «почему мой код раньше изменял элемент, а теперь не работает?», подобное же вмешательство может привести к пересмотру кода и необходимости исправить его с учётом наличия/отсутствия подконтейнера resize-listener.
Пользователь всегда может вручную переинициализировать скролл при изменении содержимого.
Я попробовал воспользоваться методом, используемым в той статье, но, увы, у меня ничего не получилось. Данный метод позволяет обнаружить изменения в размере самого блока, но не изменения размера внутреннего содержимого. К сожалению, пока что придётся оставить обновление по интервалу, а в критичных случаях — вручную пользователем, после какого-либо изменения.
Ширину и высоту обнулил — браузер всё равно продолжает скроллить. В демонстрации даже есть блок, помеченный (bug on text selecton in webkit browsers: chrome & safari), который всё равно продолжает скроллиться. Думаю, что тут дело в видимости внутреннего контейнера.
Не нашёл ссылки на демо с горизонтальным скроллом.
В том-то и проблема. что в нашем случае переинициализация не помогала. Возможно проблема была в том, что менялись стили — контейнер скрывался/показывался с помощью jQuery slideUp/slideDown. После подобного помогает только дестрой и новая инициализация скролла. Помимо этой, были и некоторые другие проблемы, связанные с тем, что данная реализация — это всё же эмуляция скролла, а не родное поведение.
Буду честен, если скажу, что про баг в вебките я узнал именно из вашей статьи. Это свело на нет мою предыдущую реализацию, пришлось тотально пересматривать проблему позиционирования, что отложило выход этого поста на несколько дней. В представленной реализации баг решён только частично, а ваш способ с процентными размерами не подходит для высчитвания высоты контейнера.
Точное значение, на которое прокручивается контейнер при выделении текста, я высчитать пока не могу, но подозреваю, что это около 10-12 пикселей, даже если высота и ширина скролла в вебките выставлена в 0. Так что я нахожусь в активном поиске решения или хака
От использования baron-а остановила незавершённость плагина — отсутствие горизонтального скролла. Кстати, именно с горизонтальным скроллом проблем намного больше, чем с вертикальным, т.к. все браузеры заточены именно на растягивание по ширине, но не по высоте. Либо для элемента необходимо выставлять фиксированную высоту, что, имхо, неправильно. Ну, плюс ещё несколько особенностей, среди которых неперекрывающий и внешний скролл.
Такое поведение наблюдается в Хроме и с родным скроллом. Дело в том, что при достижении конца скролла (т.е. когда контент полностью прокручен в том направлении, в котором Вы его ведёте), скролл перехватывается основным окном, и обратно на элемент уже не возвращается.
Кстати, первый и второй скролл абсолютно одинаковы по функциональности. Различие — применяемые стили.
Насчёт вдавленности: скролл поддерживает изменение стилей для dragged-скролла, просто не добавлены CSS-стили.
Прмеры CSS-изменения цвета в зависимости от hover и от dragged добавлены во втором и третьем примере (Simple outer scrollbar): hover делается нативным CSS, а при нажатии мыши скроллу добавляется класс scroll-draggable.
Чуть позже добавлю пример для скролла в стиле MacOS — из-за изменения системы позиционирования, стили для этого скролла не были переписаны, поэтому пример не был добавлен.
Следует помнить, что для работы стилизованного скроллбара необходима определённая HTML структура, для которой исходный контейнер JavaScript-ом оборачивается в другой контейнер при инициализации.
При изменении содержимого контейнера не стоит обращаться к контейнеру по классу, т.к. эти классы будут использоваться и контейнером-обёрткой
Фукнцоинал скролла родной — браузерный, т.е. все нативные фукнции работы со скроллом работают.
Обновил плагин и добавил поддержку удержания мыши. Хотя поведение немного и отличается от родного, но работает почти также.
Отличие в том, что родной скролл перестаёт работать если убрать мышь за пределы стрелочки. В JavaScript-е это сделать нельзя, т.к. событие mouseleave не происходит, если кнопка мыши не отпущена. Но думаю, что это событие можно отследить через mousemove.
Спасибо за наводку. Прежде не сталкивался с оптимизацией анимации, но в данном случае мне хватает возможностей, предоставляемых jQuery. В данном плагине я стараюсь свести количество используемой анимации к минимальному, либо вообще отказаться от анимации.
Рад, что кому-то статья пригодится. А алерт — это для наглядности. Большинство примеров рассчитаны на то, что их даже не придётся вбивать в браузер — их поведение и так понятно. Да и для начинающих, имхо, легче понять с алертом, чем с логом в консоли.
Помимо этого есть и другие события: скролл мыши над скроллбаром и клики на подложке скроллбара для более быстрой перемотки.
Функция апдейта, которая заниматся проверкой изменения размера, должна совершать минимальное количество действий, иначе даже при небольшом количестве скроллов на странице, загрузка процессора будет очень большой.
Также, если я изменяю содержимое контейнера (а конекретно — удаляю картинки), скроллы не исчезают, когда размер контейнера становится меньше видимой области.
И, конечно же, 5 вложенных див-ов — это, имхо, нехорошо.
А так, описание задумки хорошое, постарался.
Насчёт велосипедов — почему бы и нет, если делается какое-то новое решение? Ведь, как говорится, в споре рождается истина. Видимо в последнее время заказчики стали больше просить делать кастомные скроллбары, и существующие решения не подходили, оттуда и велосипеды.
Однако его легко обратно включить — достаточно закомментировать условие на строке 249 (не забывая про закрывающую скобку):
if(d == 'y'){ИМХО, стоит обновить статью и добавить горизонтальный скроллбар в демо.
К сожалению, я не могу принять Ваши изменения, т.к. придерживаюсь политики минимального вмешательства в оригинальное поведение элементов, а данное решение изменяет содержимое оригинального контейнера, оборачивая его содержимое в подконтейнер.
Как Вы видели в обсуждении, даже минимально необходимое вмешательство в структуру HTML может привести к недопониманию «почему мой код раньше изменял элемент, а теперь не работает?», подобное же вмешательство может привести к пересмотру кода и необходимости исправить его с учётом наличия/отсутствия подконтейнера resize-listener.
Пользователь всегда может вручную переинициализировать скролл при изменении содержимого.
.scroll-simple_inner > .scroll-element.scroll-draggable .scroll-bar { display: block; }Вечером внесу изменения в демо.
Не нашёл ссылки на демо с горизонтальным скроллом.
Точное значение, на которое прокручивается контейнер при выделении текста, я высчитать пока не могу, но подозреваю, что это около 10-12 пикселей, даже если высота и ширина скролла в вебките выставлена в 0. Так что я нахожусь в активном поиске решения или хака
Кстати, первый и второй скролл абсолютно одинаковы по функциональности. Различие — применяемые стили.
Насчёт вдавленности: скролл поддерживает изменение стилей для dragged-скролла, просто не добавлены CSS-стили.
Прмеры CSS-изменения цвета в зависимости от hover и от dragged добавлены во втором и третьем примере (Simple outer scrollbar): hover делается нативным CSS, а при нажатии мыши скроллу добавляется класс scroll-draggable.
Чуть позже добавлю пример для скролла в стиле MacOS — из-за изменения системы позиционирования, стили для этого скролла не были переписаны, поэтому пример не был добавлен.
Фукнцоинал скролла родной — браузерный, т.е. все нативные фукнции работы со скроллом работают.
Решения два:
Отличие в том, что родной скролл перестаёт работать если убрать мышь за пределы стрелочки. В JavaScript-е это сделать нельзя, т.к. событие mouseleave не происходит, если кнопка мыши не отпущена. Но думаю, что это событие можно отследить через mousemove.