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

North positioning issues #181

Closed
LufoX11 opened this issue Jan 20, 2022 · 3 comments
Closed

North positioning issues #181

LufoX11 opened this issue Jan 20, 2022 · 3 comments
Labels
By Design Issues that are not bugs in the software.

Comments

@LufoX11
Copy link

LufoX11 commented Jan 20, 2022

Hi! I'm getting some wrong positioning when using the "north" setting. I noticed that when the page is longer than the screen space and there are paddings/margins in other elements, the positioning for north (n, ne, nw) are wrongly calculated. At first I thought it was something related to the use of LightGalleryJS plugin, since in the website I'm building it only occurred after attaching the gallery to the elements (which adds some hidden elements in the DOM), but I tested it with this fiddle in your page and it's also happening, not even changing anything at all. I've reproduced your fiddle in a test.html and tested it in Chrome and Firefox (2 different engines) with the same results. For some reason, in the fiddle doesn't happen, neither in all pages in my website, which is strange.

My screen resolution: 1600x900
Chrome (Ubuntu & Windows): Versión 96.0.4664.45
Firefox (Ubuntu): 95.0b12
OS tested: Linux (Ubuntu 18.04) and Windows 10
PowerTip: 1.3.1 (tried also with 1.3.0 and 1.2.0)
jQuery: 3.6.0 (tried also with 1.x and 2.x)

The test.html file (a copy&paste of your fiddle + cdn for the libraries + margin-top: 200px just to make it more noticeable)
test.zip

In Chrome (Windows) it doesn't even show at all the north labels (the other ones work as expected):
image

In Chrome (Ubuntu) it shows off over the element (the other ones also work as expected). Same in FF:
image

I've been looking around the reported issues and I found this one and this one which are very similar to what's happening here, with the difference that the body tag is static by default here.

Do you see it wrong too in the attached test.html? Thank you!
@stevenbenner
Copy link
Owner

The file in your example is missing the HTML DOCTYPE declaration, which throws the browser in to quirks mode, an unsupported scenario because of all of the... quirks.

Adding this line to the beginning of the test.html file resolves the issue for me:

<!DOCTYPE html>

@LufoX11
Copy link
Author

LufoX11 commented Jan 20, 2022 •
edited
Loading

Thank you for your fast answer. You are right. I've also realized that this other plugin is wrongly changing the body tag to "relative" and that's the root cause. So nevermind... PS: Wouldn't this fix this issue with relative position?

@stevenbenner
Copy link
Owner

That makes sense. If the other plugin is adding position: relative; to the HTML <body> tag then it would cause a similar failure. I'm glad that you have a resolution coming for that issue.

And yes, that pull request you linked is an attempt to support the cases where there is a non-default CSS position value set on the <body> tag. But it is a big and high risk pull request that touches a lot of moving parts, and fixes a relatively small edge case. I have been sitting on that PR for too long, but I haven't followed up with the lengthy and detailed review/testing pass it would take to land it. At this point I'm not sure that I ever will, but I'll take this conversation as a vote to merge it. :)

Closing this issue as resolved.

@stevenbenner stevenbenner added the By Design Issues that are not bugs in the software. label Jan 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
By Design Issues that are not bugs in the software.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@stevenbenner @LufoX11