Как стать автором
Обновить

Комментарии 132

Можно ли использовать в своих проектах? Если да, то это отлично. Работает плавно и красиво. Обожаю минималистичный дизайн. К тому же на iPad тоже работает. К заголовкам нужно привыкнуть, но скролл не хуже чем в gmail.
Да, конечно можно.

Заголовки можно не использовать.
Есть даже форк, где этот функционал вырезан.
Я свернул браузер в окно и вот что вышло :) Chrome 25

Это ошибка в вёрстке самого теста, а не барона… но всё равно спасибо)

PS: Просто нужно чтоб каждый тест создал свой z-index контекст.
а чем не устроил user-select: none (с кросс-браузерными модификациями) для отмены выделения?
css включен у всех, а javascript нет.
user-select — не кроссбраузерное и не стандартное решение. Например, оно не работает в Opera и IE. Более того, там где оно работает, оно может быть в любой момент отменено — так что без гарантий.
В изначальном варианте блокировки выделения, врапперу выставлялся инлайновый стиль с префиксными свойствами user-select. Однако позже выяснилось, что оно, на фоне остальных механизмов, избыточно.

Если у пользователя нет JS, то у него не будет работать не только кастомный скроллбар (но останется системный!), но и 2ГИС-онлайн в целом.
В современном интернете отсутствие JS — нонсенс.
А зачем они включены в плагин по умолчанию? Лучше их сразу отдельным модулем оставить.
По сути это тоже костыль…
В чистом виде, но что делать, если скроллбары все еще являются кошмаром любого разработчика/дизайнера?
Использовать костыли :) Пока ваше решение самое изящное из всех существующих…
Это не мое. Хотя я реализовал поддержку нативного скролла таким же образом в более сложном варианте. Предложенное авторами решение работает в том числе и с touch-устройствами, без дополнительных ухищрений, о чем они забыли упомянуть.
Андроид 2.2 в родном браузере не работает
Решение делалось под iPad и ввиду, отказа заказчика от разработки — не закончено (остановились на beta-версии), поэтому может и не работать, но это легко фиксится, так как работает на дефолтном скроле.
В Андроид 2.2 вроде как нет дефолтного скрола.
так ведь в начале статьи написано, что в стандартах нет возможности кастомизации скроллбара, значит любое решение будет костылем. но верстальщикам не привыкать, если не тормозит и кроссбраузерно — вин.
Единственным существенным минусом этого решения является отсутствие возможности реализовать smooth scroll средствами css transitions.
А для «библиотечности» нужно упростить работу и дать возможность запускаться без настроек: acBar($('.scrollable)), используя только подготовленную верстку и кусок кода. И уж, если функция acBar понимает, что объект завернут в jQuery-обертку, то лучше использовать ее как расширение $('.scrollable').acBar()
Особенность решения в том, что оно не является плагином какой-либо библиотеки, и вообще не имеет жёстких зависимостей.
jQuery легко может быть заменён на что угодно.
Так, например, в одном из форков, ценой IE8, baron сделан полностью независимым от сторонних библиотек. Нам, к сожалению, пока ещё нужно поддерживать этот браузер.

Что касается transition`ов, то это спорный вопрос. Все привыкли к тому, к чему привыкли — системному скроллбару.
А вот, допустим, в IE transition`ы скролла есть по-умолчанию, и это портит жизнь разработчикам.
Если вы реализовали поддержку jQuery, то почему бы и не сделать это решение в стиле jQuery, для этого не придется изобретать костыли, зато упростит жизнь разработчикам. Отсутствие зависимостей — это плюс, но не стоит ради этого отказываться от удобства.

в принципе, можно написать малюсенький адаптер для jQuery и положить рядом на гитхаб
Я не говорю про полный отказ от использования глобальной функции, а лишь про то что библиотека использующая jQuery, должна включать вариант в стиле jQuery. Это вопрос профессионализма — подчиняться принятым стандартам, ради всеобщего удобства.
Многие библиотеки из коробки одновременно поддерживают jQuery, nodejs и AMD. Зачем нужна поддержка jQuery, если в результате используется собственная конструкция? jQuery, тем и красив, что используется одинаково для разнообразных задач. И если бы разработчики jQuery рассуждали так же как автор, то мы бы продолжали заворачивать функцию в функцию, завернутую в функцию…
мне кажется тут где-то недопонимание, у барона нет поддержки jQuery, для уменьшения размера он написан на чистом js, просто в примере показано как передавать в опции элементы при помощи jQuery, если он уже подключен к проекту.

т.е. можно написать baron($('.wrapper')...), а можно baron(getElementById('elementId')...)
На той же версии (но без плагинов) всё ок. Ну или поправили уже.
На той же версии с теми же плагинами проверяли — всё было ок. Видимо, проблема была не в браузере.
А зачем вообще делать кастомный скролл?
Затем что дефолтный скроллбар во вложенных элементах — это уродство?
Не понял что вы хотите сказать. Переформулируйте что ли?
Ну возьмите элемент поместите его по-середине страницы и поставьте overflow:scroll. Что ли.
вот это было бы уродством:

image
вместо тысячи слов ))))
Ну а я бы не хотел, чтобы вы мой маковский скролл заменяли.
А его никто и не хочет заменять. Все хотят скролл как мой маковский ))
И что, ваш скролл умеет исчезать или нет, в зависимости от настроек на «Маке»?
Я имел в виду, что у меня тоже Мак и мне хочется, чтобы все скроллы в мире были похожи на Маковский.
Это интересное желание, но у меня скролл, например, не пропадает, а у кого-то настроено, чтобы пропадал (поведение по-умолчанию). И мне хотелось бы, чтобы переключение этой настройки определяло как будут вести себя все скроллы в системе.
Я ни за что в жизни не хочу, что бы мой scroll был как на Маке, простите уж.
Почему?
Очевидно, потому что он не любит мак)
Хм, я почему-то не нахожу это уродством, нормальный скроллбар. Можно было бы утверждать что системный скроллбар уродство если у вас темный дизайн, но, в случае со светлым дизайном и светлым скроллбаром в виндах, я просто решительно не пойму яростное желание дизайнеров/владельцев сайта закастомизировать скроллбар. W3C на то и ответила «full stop», что скролбар это нечно больше чем элемент дизайна сайта — это системный контрол который люди привыкли видеть таким какой он есть. Ну и как маковод, лично я, например, ненавижу до глубины души когда сайты переиначивают нативный оверлейный/невидимый скроллбар и вставляют свой костыль со своим кастомным дизайном.
В том-то и суть, что сколлбар смотрится нормально только на Маке. И то что w3c ответила «full stop», говорит о том, что они не провели должного анализа и, вместо создания стандарта, отделались отговоркой. Они и пятый html не смогли запустить, пока их whatwg под жопу не пнуло. Так что не о чем разговаривать.
Вкусовщина полнейшая. Я, когда Виндой пользовался, терпеть не мог маковские скроллы, они неестественно смотрятся в винде.
Дизайн скролла полностью задаётся в CSS. То, что демо-дизайн похож на маковский — ни о чём не говорит.

Вы можете сделать скроллбар в стиле Windows XP — и он таким будет на маках и линуксах ))
Я не понял зачем вы мне это говорите.

Я вам говорю, что в каждой системе чужой скролл смотрится неестественно. Желание «осчастливить» пользователей Винды маковским скроллбаром понятно не будет. Меня такие попытке на винде всегда раздражали.
А как вы поступите если есть макет дизайна с кастомным скроллбаром и нет возможности оставить нативный, так как и дизайнер и заказчик настаивает на его реализации?

Я не думаю что ваши аргументы убедят одного и другого в обратном.
Я никак не поступлю. Не занимаюсь этим. Меня как пользователя это бесить будет. Так и передайте вашему дизайнеру с заказчиком :)
Сколько людей, столько и мнений. Спасибо за фидбек!
W3C ответила по поводу скроллбара всей страницы в контексте того ужаса, который творился в IE заменой цветов, на красно-чёрный, например.

Сейчас ситуация меняется. Если FF реализует кастомизацию скроллбара, то такая кастомизация станет де-факто стандартом, к которому со временем подтянется ИЕ. Весь webkit это уже поддерживает.
это бесконечный спор, почему можно кастомизировать кнопки, но нельзя скроллбар? или вообще ничего нельзя менять в интерфейсе?

к примеру, на нашем проекте все наши дизайнеры сошлись в мнении, что стандартный скролл выглядит убого внутри попапа, поэтому мы договорились, что главный скролл на сайте должен быть стандартным (потому что он скроллит контент внутри стандартного окна и пользователю это привычно), а внутренние элементы интерфейса должны быть в стиле сайта.
Лучше бы плавность скролла колёсиком в левом меню исправили, а не меняли внешний вид.
У меня нет возможности колёсиком нормально прокручивать, дергается и прыгает список.

А на телефоне, его так вообще невозможно промотать :(
извините, я погорячился… хотя у меня действительно скролл дергается и в Опере он не исчезает в левой панели, хотя его там не должно быть, т.к. контет может аш 2 раза там поместиться.
О какой левой панели идёт речь?

На maps.2gis сейчас используется FleXcroll, который будет заменён на baron где-то в марте.
НЛО прилетело и опубликовало эту надпись здесь
Это сложнее, т.к. «облачко» может иметь внутри все что угодно. Скриншот вверху лишь один из вариантов его контента.
НЛО прилетело и опубликовало эту надпись здесь
Так мы можем уйти далеко в философию.
Применение скролла очевидно. Если есть интерфейс, размещающийся строго на одном экране, внутри всегда будут области, в которых необходим скрол. Возьмите тот же айпад и откройте настройки.
Я согласен, что «облачко» надо дорабатывать. Но скрол здесь не при чем.
НЛО прилетело и опубликовало эту надпись здесь
> Я о том и говорю, что если скроллбар попал в окружение таким образом то, что-то пошло не так.

Никак нет) Тенденция превращения длинных многостраничных сайтов в одностраничное приложение есть, и это факт. В таких приложениях у окна скролла нет вообще.
НЛО прилетело и опубликовало эту надпись здесь
в проводнике весь интерфейс в таком же стиле, как и скроллбар. а на сайте дизайн совсем не такой как в ОС.
НЛО прилетело и опубликовало эту надпись здесь
Например, на андроиде скроллбар не виден у какого-либо элемента, только у всей страницы. На андроиде 2.3 вообще такое понятие, как скроллбар, знает только страница, а элементы не понимают overflow: scroll. Я тоже этим вопросом занимался, искал решение — а решений не было вменяемых, т.к. всё тормозило. Но данный скролл достаточно хорошо себя показал.
Не всегда есть возможность влиять на дизайнерские решения, для некоторых проектов кастомный скролл «ОЧЕНЬ важен!!!111», к сожалению.
Chrome 24 Mac OS X 10.8 трекпад — скролл какой-то дерганный, не то что бы совсем, но сразу бросается в глаза.
Chrome 24, Mac OS X 10.8, трекпад — скролл в демке плавный.
Так я и не говорю что он не плавный, но такое ощущение что нет 60-ти фпс
Если вы об этой ссылке diokuz.github.com/baron/
то небольшое подтормаживание возможно на слабых системах из-за наложения двух градиентов поверх скроллируемого контента.

Например, на Mac Air 2012 i5, fps в Chrome падает ниже 60 только в самом начале скролла. А вот на десктопе с дискретной видеокартой не происходит и этого — fps всегда выше 60.
Нет, здесь явно что-то не так, оно то нормально скроллится, то фпс явно проседает, несмотря на то что инспектор показывает 60 фпс всегда, MacBook Pro 13 late 2011.
Кажется такое есть только если скролл доходит по инерции до конца, и когда курсор стоит внизу, потом начинаешь крутить вверх.
Сафари 6.0.2, Мак. Застревает скролл в некоторых положениях и не реагирует на прокрутку двумя пальцами.
Проблема не воспроизводится. Попробуйте посмотреть текущую версию baron diokuz.github.com/baron/

Сам по себе скролл не может застрять в принципе, потому что он — системный.
Сбой может происходить только при выходе курсора за пределы «окна» скроллируемого контента.
Всё ок сейчас.
htmlpreview.github.com/?https://github.com/Diokuz/baron/blob/master/demo/index.html

Не понял куда смотреть. Скролл у меня дефолтный, только колесом почти не крутится.
Попробуйте вот сюда: diokuz.github.com/baron/
Это самая новая, но нестабильная версия baron.
А почему на Mac не скрывается сам скроллбар?
Всё скрывается. Тот бежевый, что вы видите справа — и есть кастомный.
По-умолчанию в демо-дизайне кастомный скроллбар виден всё время.
Можно настроить в CSS чтоб он делался более прозрачным (сейчас 0.6 и 0.8 при ховере).
Вы кстати как нибудь боролись с кастомный скролом внутри текстарии, или вам это не нужно было?
Это хороший вопрос, но пока ничего сказать не могу — исследований не было.

На первый взгляд кажется, что должно работать, но это догадки, и надо проверять.
Было дело, изучал это и писал для этого скрипт.
Для упрощения просто доработал (расширил) для этого jScrollPane.

Это было давненько, в 2007 году, делал я это для проекта yatv.ru

Вот как это выглядит:

image

Кстати, посмотрел сейчас код и вспомнил, что принцип тот же, что и у автора статьи — я увеличивал размер textarea, чтобы он выходил за пределы блока и поэтому всё было нативно. Если этого не делать, то textarea вроде не переносит overflow:hidden, как-то так, уже не помню, если точно =)

Пользуйтесь js, css

Вызывать так $('textarea').jScrollPane({showArrows:true, scrollbarWidth: 13, scrollbarMargin:0, wheelSpeed: 60});
На iPad'е прведение вашего скролла отличается от поведения системного — если скролл системный, то резким движением страница скроллится до предела, а у вас только на небольшой фрагмент.
Да, пока нет инерции, к сожалению.
Вдоль всех комментариев меня мучает вопрос. Почему в iУстройствах не оставить стандартный скролл, и только в других сделать кастомный? Как я понял, и вам, и пользователям нравится стандартный скролл iУстройств.
Почему же нет? Ничто вполне не мешает оставить стандартный скролл в iOS.
Для этого достаточно проверять в JS платформу, и инициализировать baron только на не маках.

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

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

На OS X, кстати, скролл элементов по механизму идентичен скроллу окна — пользователи трекпадов уже оценили.
Попробуйте overflow: auto; и -webkit-overflow-scrolling: touch; — инерция вернется, но немного изменится механизм рендеринга.
При -webkit-overflow-scrolling: touch скроллбар не стилизуется.
Изменение размера страницы не приводит к пересчету размера хреновинки скроллера, зато она пересчитывается при первой попытке прокрутить. Выглядит не очень, но, вроде бы как, должно быть нетрудно исправить?
Это баг, будем править. Спасибо за наводку.
Отличное решение, спасибо

Пример очень сильно шатает при изменении высоты окна браузера, из-за динамической высоты блока (70%). Высота скоролл-бара тоже пересчитывается только после вызова события (mousewheel у вас, вроде). Если это критично ресайз, наверно, придется тоже какой-то слушать.
window.resize уже слушается не чаще каждых 200 мс.
Это баг.
Баг исправлен.
А как он реагирует подгруженный через ajax контент? высота скролла меняется, новый контент можно прокрутить?
хороший вопрос, завел тикет, чтобы автор не забыл)
можно в комплите ajax-a дергать $(window).resize();
В новой версии уже всё сделано) На днях вкомитаю в гитхаб.
Ужас получается, когда на странице, которая выше окна браузера, встраивается еще pane с прокруткой, высотой чуть ниже видимой части страницы.

Эти страдают очень многие сайты, и прокрутка становится мучением. Вариант один — жить с браузером ровно того размера, как у автора такой поделки.
Проблема подобных скроллов в том, что они никак не реагируют на выделение текста. Однажды я взял первый попавшийся scroll-плагин для jQuery и попробовал исправить этот недостаток.
Что из этого получилось, можно посмотреть здесь narod2.ru
Не могли бы вы подробнее описать проблему? У меня выделение текста скроллит — как и положено.

Или ваш пост относился к коментарию про nicescroll?

PS: Ещё один плюс baron`а detected)
Проверил в хроме — скроллит, в опере у меня не скроллит
В опере не работает такой скролл внутри элементов. Это баг оперы, а не барона.
Некоторые отщепенцы, типа меня, пользуются плагином для FX Grab and Drag. Так вот ваш плагин один из немногих, кто не конфликтует и продолжают нормально работать. Колесико, конечно, панацея, но далеко не всегда, особенно если отсутствует кинетическая прокрутка (чем быстрее крутим, тем больше шаг прокрутки).
Просто это не плагин, поэтому конфликты невозможны)

Что касается кинетической прокрутки — на нормальном железе всё давно реализовано. Например на маках, или на некоторых сенсорных мышках (тот же Genius с «синим глазом» вместо колеса).

Идеология барона простая: как крутить — лучше знает железяка под управлением операционки, а как это показывать — дизайнер приложения.
Так и вижу минималистичную версию статьи:
«Кроссбраузерная кастомизация системного скроллбара. …демо…, …аннотированный код…».
Мне кажется, без js должен быть виден нативный scroll:

<noscript>
<style>
.wrapper {overflow:auto;}
.scroller {overflow-y:visible;}
</style>
</noscript>

А так хорошая идея, напоминает то, как сделали оформление кнопки «обзор» для загрузки файла — там эту кнопку скрывают и двигают над мышью, чтобы при клике она работала нативно =)
НЛО прилетело и опубликовало эту надпись здесь
Ничего подобного (noscript) здесь нет diokuz.github.com/baron/
скрин (js отключён) — прокрутки не видно.
НЛО прилетело и опубликовало эту надпись здесь
да, в IE видно, в Хроме нет.
НЛО прилетело и опубликовало эту надпись здесь
Автор, пожалуйста, оформите код в виде плагина. jquery plugin patterns
Засорять window плохая практика.
Это можно сделать форком, но независимость baron от jQuery — ключевая его особенность и одно из основных наших требований.

Скажу больше: в будущей стабильной версии, скорее всего, baron вообще никогда не будет использовать jQuery у себя внутри, поскольку требование IE8+ делает возможным использование plain js для добавления классов, стилей и обработчиков событий без заметного увеличения объёма кода.

Сейчас единственный объект в глобальном пространстве — baron с двумя методами. Всё остальное в замыканиях. О других библиотеках baron js мне не известно, поэтому ограничение — только на глобальную переменную baron.
То есть, пользователь крутит колесо мыши, под курсор попадает заголовок, фиксируется, и, внезапно, скролл перестаёт работать (точнее, скроллиться начинает вся страница).

Кстати, интересное решение на css, имхо:
pointer-events: none;


Конечно, не настолько таргетированное, как ваше, но со своими достоинствами.

А вообще за статью спасибо. W3C — редкостные мудаки, что не дают стилизировать скроллбар.
НЛО прилетело и опубликовало эту надпись здесь
К счастью, в webkit браузерах (а нам требовалось обратиться только к ним) есть такая возможность:

Тот же кусок.
Шикарное решение! Правда, кроме неподдержки ie8, есть ещё один досадный недостаток — заголовки вообще перестают реагировать на мышь, и в них даже текст нельзя выделить. Но в комментарии CSS добавлю.
О найденных багах в WebKit сообщали?
Нет. Баг горизонтального скролла можно назвать фичей, которая позволяет просматривать скрытый контент.

Есть опыт общения с багтрекерами вебкита и ff — тикеты висят годами, ибо не критичные.

Один только баг анимации псевдоэлементов в вебките правили 2 года и 3 месяца — и это только до попадания в канарейку хрома.
Кстати, ещё overflow:hidden можно скроллить хитрым способом в ВебКитах)
Нажимаем колёсико мышки на скроллабл-блоке и двигаем её.
Есть вот такой баг.
image
barTop: 40, // Ограничитель позиции скроллбара сверху

А есть ли возможность сделать оступы сверху и снизу? Я сейчас верстаю макет и вот у меня примерно такая задача… + трек.

Теперь можно)
barTop отменён, позиционирование делается через css родителю bar`а (см. папку demo в текущей версии baron)

Спасибо за пул-реквест)
оу еее! Спасибо тебе друг! А то такой костыль в верстке пришлось делать…
Может поздновато, но думаю кому-нибудь это будет любопытно:
www.noinimod.ru/52/ — неплохое, давно созданное, решение.
Реально ли отключить Барона на iPad, так как там уже стоит webkit-overflow-scrolling: touch для скроллера?
Конечно!

Детектим iOs stackoverflow.com/questions/9038625/detect-if-device-is-ios

Далее если iOs — не инициализируем барона.

Можно сделать ход конём и задисплейнонить кастомный скроллбар на ретинистых устройствах. Но там вроде лиса есть.
Пока ждал вашего коммента, реализовал похожим способом через Modernizr (https://gist.github.com/danott/855078), так как он уже подключен к странице. Добавляю класс на iPad'e и при его наличии скрываю скролл.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий