Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: position of the default spinner #42

Open
dhunink opened this issue Jul 24, 2019 · 4 comments
Open

Suggestion: position of the default spinner #42

dhunink opened this issue Jul 24, 2019 · 4 comments

Comments

@dhunink
Copy link

dhunink commented Jul 24, 2019

Hi,

I've used this awesome snippet a lot in various websites. Love it, you did an amazing job!
I know that several elements, such as the progress-bar, can be positioned.
The default spinner can't tough. I recently run into an issue where the overlay is shown into a particularly div element. No matter how large the dive, the user is always scrolled to the top of it, before the loading overlay shows. Therefore it makes sense to position the spinner at the top, instead of center, as well. Checking the currently online demo, the following code does that trick:

.loadingoverlay{ flex-flow: unset; align-items: flex-start; }

I thought I'd share the suggestion; perhaps there are more people looking for this flexibility.
Once again: keep up the good work!

@gasparesganga
Copy link
Owner

Thanks a lot for your feedback!
Actually, I had already thought about this feature, which will be included in the next major release, in the form of some options named imageFixedPosition, textFixedPosition, etc. They will behave the same way as progressFixedPosition, which I understand is what you are looking for, right?

If you have any suggestion or request about it, please share them here.

Cheers,
Gaspare

@dhunink
Copy link
Author

dhunink commented Jul 25, 2019

Great to hear you had already given it some thought. I think your suggested options would do the trick indeed!

@drnasin
Copy link

drnasin commented Nov 12, 2019

any news on the next release where this is included?

@gasparesganga
Copy link
Owner

I had started to work on a new major release that used the Intersection Observer API, but it became clear that in order to fully take advantage of it (and get rid of interval polling), it had to implement the Resize Observer API too.
While the former is quite mature and there is wide browser support, the same cannot be said for the latter. I decided to postpone that major release, waiting for a decent browser support.

If things don't get better in a few months, I will probably release a new minor version that includes some new features like this one (even thought I wanted to implement and expose them in a totally different way), leaving the complete overhaul for better times...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants