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.

Sign up for GitHub

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

Jump to bottom

Rationale behind absolute position on html, body, page-wrapper, content-wrapper? #84

Open
xoofx opened this issue Jan 11, 2021 · 3 comments
Open

Rationale behind absolute position on html, body, page-wrapper, content-wrapper? #84

xoofx opened this issue Jan 11, 2021 · 3 comments
Assignees
@halfmoonui
Labels
v1 Version 1.x.x

Comments

@xoofx
Copy link

xoofx commented Jan 11, 2021

Hey,

I'm evaluating to migrate my projects from bootstrap to halfmoon and so far I like it a lot! I love the usage of CSS variables, good job!

So, one issue I have been through is that for example I'm using tocbot which was working all fine with boostrap, but then with halfmoon the update of the toc was not working.

I discovered that halfmoon is setting absolute position to several top level elements (html, body, page-wrapper, content-wrapper) that are making it incompatible with tocbot (I don't think they can fix it in tocbot, I haven't followed the reason but it is likely that absolute is messing with scroll notifications or top position in some sort)

So I was able to override these positions to restore them to static, but the question is why halfmoon made the choice of making this containers absolute?
@halfmoonui
Copy link
Owner

Sorry for the late response, and thanks for bringing this up. The rationale was to support a few older browsers, and also fix some unexpected bugs that pop up here and there with the custom scrollbars. Admittedly, this has caused new issues like the one you mentioned, and also some other scroll issues, because the <body> does not scroll, the .content-wrapper does.

One option was attaching the .dark-mode class to the <html> element rather than the <body> and styling from there. This fixes the scrollbar issues and that can hopefully accommodate the default position property for the top level elements as well. Since these are essentially structural changes, I am going at this in a slow and methodical method so that nothing accidentally breaks. All that said, this should hopefully be fixed in one of the upcoming updates.

@halfmoonui halfmoonui self-assigned this Feb 6, 2021
@Achilles1515
Copy link

It's been some months since I looked into this, but I think at one point I concluded that scrolling (of .page-wrapper) is blocked while hovering over the table of contents on the Halfmoon docs site had something to do with these absolute positions. I unfortunately forget the finer details, but it's really annoying not being able to scroll (mouse wheel) while hovering over the table of contents.

@ThaUnknown
Copy link

guessing this is related to #49 the fix I proposed works, I guess I'll make a PR will all my fixes for halfmoon

@halfmoonui halfmoonui added the v1 Version 1.x.x label Aug 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@halfmoonui halfmoonui

Labels
v1 Version 1.x.x
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@xoofx @ThaUnknown @Achilles1515 @halfmoonui