perfect-scrollbar v1

[hatashiro]

Hello there,

I'm planning to work on the next major release(v1.0). It will have completely different structure and code from how it is now. I'm thinking about making code as simple and intuitive as possible. Here are some main changes.

1. Stop saying 'call update() everywhere'. Instead, use MutationObserver.
2. Drop support for IE < 11. (MutationObserver is not supported)
3. Use modern JavaScript and Web APIs. Won't provide fallbacks for old browsers.
4. Simpler (maybe less) functionality.
5. Better styling.
6. Tests.

Some may wonder about items. I'd like to comment for each.

1. Actually it's suggested quite a while ago, but I've recently tested it out and found it very proper to be used in PS. It may be able to provide auto update for most cases. For the other cases, PS will surely provide update() like it does now.
2. Mainly for 1 and 3. To be honest, even now PS doesn't work well in IEs anyway 😳
3. Why not? I may consider using Babel though.
4. This is a quite important point. I will write about this below.
5. At the very beginning, I'd like to make PS easy to style and customise. However, I cannot say it worked well. This time, I'd like to provide better way to actually be used by users.
6. Frontend tests are difficult. But till now there has been no way to make sure a patch doesn't break other parts. I think it's the very time to prepare one.

About 4, let me make clear one thing.

The goal of PS is not completely replacing the browser scrollbars

You may think it's stupid, but I really think it's not. Usually, in most cases, scroll hooking is bad practice. Web design and implementation should be done in what web basically suggests us to do. However, there are still needs for customisation, and I think PS is one of those. So PS provides scroll emulations for wheel, keyboard, left-click, touch, etc. But there are some scrolls really difficult to emulate, mid-click or selection for example. I've once tried to implement selection scrolling, and it did bad more than good. It creates a lot of bugs and malfunctions. And I thought that, if it's really important to support such scrolls in a web site, the native scroll should be used. In conclusion, PS will only support some basic scroll emulations, and focus on what it can do well. Instead, some bridge API to connect PS to user's own scroll logic may be provided. I'm sorry for those disappointed by this news, but I'm sure this makes PS easy to use, customise, and maintain. I will make this point clear in README of the next version.

Long story, but it's not a closed discussion. Please leave comments and tell me about your opinion. Thanks for reading.

P.S. As it may be expected already, this may take quite a while, as I suppose. In a while, I may not able to be writing code to fix the current or future issues. But I can still accept PR or write a very quick fix, so please don't mind uploading issues or PRs. Cheers!

[zomp]

Hi noraesae, many thanks for the comment on PS future. I like your decisions, they are very wise.

P.S. Personally I wouldn't mind even the current styling (5) – people who know how to use PS usually know even how to modify it.

[hatashiro]

Here are some more detailed contents.

• Full-stretched scrollbar customisation
  
  
  
  • Geometries including width, height, padding, margin, etc.
  
  
  • Will make scrollbar DOM simpler to make it easy to write CSS.
  
  
  • Scrollbar mount location (even outside container!)
  
  
  • This enables user to place scrollbars literally anywhere.
  
  
  • This disables silver-bullet CSS style. Thus, a default CSS won't be provided(!).
  
  
  • Wide range of example CSS will be provided for users to refer to.
  
  
• Scroll handling
  
  
  
  • PS will handle only the scroll event, no wheel, keydown, click, etc.
  
  
  • Use requestAnimationFrame to optimise performace.
  
  
  • For any other scroll emulation, a plugin API will be provided.
  
  
  • PS.createEmulator(...)
  
  
  • Each emulator must define actions for init, pause, resume, destroy events.
  
  
  • For each event, essential information will be passed as parameters. (TBD)
  
  
  • Don't worry, current scroll emulations will be ported and maintained as official plugins. But users can always write and release their own scroll emulations!
  
  
• update() method
  
  
  
  • Still support manual update.
  
  
  • But MutationObserver will be used to update responsively. This will actually cover most cases where update() needs to be called now.
  
  
• Won't use Babel, to support basic Browserify or Webpack usage.
• Drop jQuery adaptor
  
  
  
  • The new API will not look adequate with jQuery.
  
  

Now I'm just brainstorming how to make the next release awesome. Please feel free to leave a comment and discuss!

[KingSora]

Hello! :)

A very important thing to me would be hotkeys as they are in the native scroll behavior. This might be a bit complicated since they are different in different operating systems. There is also one thing which would be nice: In windows you can press the "middle mouse button" (you can press the mouse wheel itself) and you will get a cool scroll behavior. Its hard to explain for me, the best thing would be if you try it out by yourself.

Touch support should be also a thing.

Also a nice thing would be if your scrollbar could be applied to textareas (if this is the case ignore this suggestion, havent tested this so far)

Best regards,
Sora

P.S.: I am currently developing my own Scrollbar plugin, and there are a few things which cause me stomach pains... :D

[hatashiro]

Considering to use Flow. If using it, may consider Babel again as anyway the source should be bulit.

[hatashiro]

I've just written a design draft for PS v1. Please take a quick look if interested, and feel free to drop a comment!

https://gist.github.com/noraesae/b5202b6131509a46c7e041791036ca86

[bck2207]

Hi noraesae,

Really good news! I was planning to use perfect-scrollbars for a project, which is basically a css framework with some custom-elements. (like this one). Currently, we do also have a custom-scrollbar component, which was created years ago and doesn't satisfy our requirements any more! (it become also almost unmaintainable).

My idea was to use perfect-scrollbars in a custom-element basically like:

<custom-element class="required-styles-for-perfect-scrollbar">
    ...
</custom-element>

and innerly by custom-element script:

var ps = require('perfect-scrollbar');
ps.initialize(root); // initialize ps on custom-element

The problem with update(), which you also wanted to solve through MutationObserver came to my mind and i could easily set it manually to my custom-element.

And actually, it was done except the IE11 bug :(. #160. We must support >IE11 in our project, so without solving that, it was impossible to use this in production. I loved perfect-scrollbars because of clean and wise design with correct principles, so I wanted to figure out a way to solve (or at least to by-pass) this issue. At the end, I came to this crazy idea.

Since you are working on a stable version of perfect-scrollbars, I hope that this bug won't be an issue anymore :)

Emulators

Separation of emulators (I would call them plugins, since they will be optional), is a very good idea. (For example, we don't really need touch support).

Update

Like you said, MutationObserver covers almost all cases, except flex-box. I used this npm package to cover that too in my custom element, but honestly, this was a pragmatic approach.

So, i can offer you any help, if you need ;).

[hatashiro]

Today I've looked into the current issues. Many of them have been marked as wont-fix because they can be resolved with v1. I somewhat feel like I spammed 'will be resolved in v1' too much 😅. I feel really sorry that I cannot help the issues in the current version, but nowadays I'm too busy to focus on both versions because of my professional works and other projects. Implementing v1 is also kinda slow because of them, but I promise I will do my best on it.

Thanks.

[wujekbogdan]

Better styling.

Did you consider using BEM methodology?

[hatashiro]

I can finally continue working on this again! Sorry for everyone that I haven't been on this very actively.

I recently found that building 1.0 from scratch is hard enough. The features discussed above will remain, the goal won't change, but I am thinking about starting from modifying the current code base.

[wujekbogdan]

(...) but I am thinking about starting from modifying the current code base.

Good strategy, here's an interesting post about it: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Yes, the post is old, but it's still valid.

[Tigerino]

Hey noraesae,

any update on when you plan to implement this concept (or any timeline in mind)? Are you still working on it, or is it on hold? I really do like your library, yet, I would love to see the requestAnimationFrame changes in.

cheers
Tigerino

[Robinjoeh]

Hello,

Also wanted to check, will there be a new version 1, or is this project abandoned? If you don't have the motivation, please feel free to provide us with your PayPal address or other ways to donate. I'm sure a lot of us would appreciate the new version of perfect scrollbar.

Ping @noraesae

[hatashiro]

Hi,

I am really sorry that I have not contributed on PS recently. This year, I started to work on several other projects, both personal and professional. I usually check PRs, accept them, and release a new version, but I do not really have time to resolve issues for the time being. It is not really about funding, but about priority.

About 1.0, as I have mentioned in the previous comment, I may not consider rewrite the code base from the scratch and publish a new breaking release. Rather than that, it would be better to refactor and improve the current code base. So specifically said, the next release may be 0.7 or 0.8, and 1.0 is far.

I may close this issue for the time being. I cannot promise the improvement work will be done in the close future, but will do my best. If anybody's interested, PS's always open on PRs and new contributors.

Thanks again for your interests.