-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
The djdt handle shouldn't be stuck at the top of the browser window initially #1853 #1871
Conversation
@@ -220,7 +220,7 @@ | |||
background-color: #fff; | |||
border: 1px solid #111; | |||
border-bottom: 0; | |||
top: 0; | |||
top: 268px; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about using a relative position rather than an fixed value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that would work too. Let me try it out and see the changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or what if instead of changing the position, I adjust the y translation?
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried it out and the handle was still stuck at the top. Maybe I did something wrong, but it seems to me that a better way would be to change the fallback in ensureHandleVisibility
to not be 0
but something like 200
:
I like Tim's idea of using a relative value for the default but maybe it will be harder to implement the handle dragging since you'd have to convert pixels to relative values there as well.
I noticed that if I use position relative, I will have to make numerous changes however I decided to leave the button as is because it was always getting overridden by the fallback function. You and @tim-schilling can test it out now to see if it works now. |
Thank you! |
Happy to help. |
Description
The issue was as much as the toolbar can be moved, it would be preferred if its position was on the upper top instead of the top.
Fixes # (issue)
The issue is mentioned here #1853
Checklist:
docs/changes.rst
.