Да, лёвский тоньше, но я тут руководствовался рекомендацией, что элементам UI не гоже быть меньше, чем площадь курсора. А с reversed scrolling'а надо бы разобраться. Ещё пунктик в 2do :)
В маке он тонкий, потому что дизайнеры, как мне кажется, руководствовались правилом «есть крутой тачпэд и есть крутая мэджик маус, поэтому скролл можно сделать тоненьким, чисто чтобы ориентироваться в каком месте страницы мы сейчас, а не чтобы кликать по нему».
При всей моей любви к Lion-у, я бы рекомендовал воздержаться от применения такого решения на сайтах. После Snow Leopard-а к Lion-у надо было привыкать от 1 до 3 дней.
Но на сайте:
1) Тратить сутки на привыкание к одному единственному сайту? Да кому это надо?!
2) У обычного взрослого человека будет единственная реакция: «чозанафиг???!» и это явно выходит за рамки того, что вам хотелось бы слышать от пользователя.
3) Пользователь всегда ожидает нативные, привычные, понятные элементы управления. Все эти закосы винды под мак, мака под винду и линукса под и то, и другое выглядят в лучшем случае нелепо.
P.S: нет реакции на клик над полосой скроллбара для пролистывания страницы.
К тому же под самим лайоном это будет работать крайне убого. Хотя бы потому, что у половины пользователей включен прямой скроллинг, у половины обратный. И JS-ом это не выяснить.
Именно это решение вряд ли будет использовано широкой аудиторией. Проект, где эта штука используется предназначен для узкого круга лиц. Насчёт нативных элементов я уже даже не знаю что сказать, поэтому пока без комментариев. А насчёт закосов не совсем понял. Это решения для браузеров, а они, как бы, везде похожи.
1. Если скроллить колесиком мыши, до упора вниз, то происходит скачок. Будет возможность, попробуйте медленно прокрутить.
2. Если начать скроллинг и убрать курсор с полосы прокрутки, то текст не виден внизу и полоса прокрутки исчезает.
Может все так и должно быть, не знаю, но не удобно.
PS: Данный скроллинг будет не привычен и его польза только в единичных случаях.
Намного проще было бы просто прятать полосу прокрутки и все. Я так сделал на всех страницах с помощью расширения в хроме. Очень доволен. Особенно хорошо на сайтах с темным фоном, где полоса прокрутки сильно выделялась и отвлекала внимание. Появление и пропадание полосы в данном случае ничем не лучше, а возможно даже еще сильнее отвлекает внимание.
Одной из решаемых задач было сохранение ширины контента, вне зависимости от наличия скроллинга. Расширения браузеров не использовали по понятным причинам.
От малейшего прикосновения улетает к чертям. При началае прокрутки полоса должна появляться незамедлительно, а не через пол секунды. К вопросу о размере — попадать мышью в скролбар не нужно, он элемент управления раз в год, в остальное время он индикатор.
Такие решения — попытка замены стандартных контролов, как правило порождает много проблем, с которыми можно пытаться бороться долго и безуспешно.
К примеу jScrollPane использовал — в центре странице блок с вертикальным скроллом. сама страница свой скролл собственный имеет. проблема — если при скролле в этом блоке не заблокировать общий скролл — ясно что будет. если же заблокировать — то открыв страницу и если мышка окажется в центре — то долго будешь думать — почему страница не скроллится.
Кастомизировать скроллбар нужно очень осторожно. Прежде чем начать, стоит пять раз подумать, получится ли у вас сделать лучше чем заложено системно. У вас не получилось скролл всегда работает не в ту сторону: во всех системах это не предусмотренный системно reverse scroll, а на OSX Lion это скролл в прямом направлении, хотя должен работать reverse.
Chrome 15 стабильная ветка, скролл работает очень странно… дерганье и скачки в пределах 20% рабочей области. Скролл осуществлялся жестом (2-а пальца) на тачпаде
Вообще-то, большая глупость делать подобные плагины. Почему? Потому что рассмотрим пример Гугл докс с новым дизайном. Там красивые скругленные линейки сделаны только в Хроме. Почему? потому, что в Хроме они реализуются через CSS, без всякого яваскрипта, подозреваю, гугловцы тупо браузер оптимизируют под свои продукты (вот тебе и честная конкуренция). У гугловцев хватило мозгов понять, что прокрутку страницы нельзя делать на яваскрипте (точнее, они понимают, что плохо что-то менять в ДОМе по событию onscroll, это ломает плавную прокрутку например в Опере), они просто встроили нужный им функционал по внешнему виду линейки в браузер.
Но авторы то об этом не знают, и все пытаются вместо этого написать уродливый тормозящий, плохо работающий в ИЕ, Опере и фаерфоксе костыль на jQuery. Печально. Наглядным глазом видна разница между уровнем и направлением мышления авторов подобных плагинов и разработчиками Гугл.
А ваш, уважаемы автор, пример, даже не поддерживает деградации — без яваскрипта вообще текст не прокрутить. Да горите вы в аду с таким подходом.
Отвечу всем пачкой. +18 за топик, насколько я понимаю, выдано авансом. Спасибо. Это действительно не самый удачный топик и не самый удачный скрипт. Буду реабилитироваться.
А теперь внимание: Antiscroll (по ссылке демка). Выглядит точно как на леве. Поддерживает как reversed scrolling, так и обычный. Fade in/fade out самого скролл бара сделаны на css animations.
Скролл бар как вертикальный, так и горизонтальный. Работает почти везде: IE7+, FF3+, Chrome, Safari.
Не работают все стандартные контролы — пробел, вверх/вниз и так далее.
Попробуйте не заменять полосу прокрутки на кастомную, а скрыть ее с помощью родительского блока. А элементы управления перерисовать. В итоге скроллер будет вести себя как нативный.
Есть рабочее решение, но его нужно выдрать из проекта и причесать (:
Вертикальный скроллинг содержимого страницы в стиле Mac OS X Lion