Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Drop down panels drift away from their buttons on zooming

+0
−0

Note: This is not related to the recent code release - I noticed this before that.


The panels that appear when clicking on the Notifications or Communities buttons at the top right of the page are positioned correctly regardless of zoom level (they automatically appear in the right place for the current zoom). However, if the zoom level is changed while the panel is open, it drifts horizontally and ends up far away from the button it is associated with.

This is much less of a problem following the recent release, now that the button that opened the panel is no longer the only way to close it, so I now see this as more of an aesthetic bug.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

1 answer

+3
−0

This is pretty much by-design.

Zooming in web browsers is not "really" just enlarging the displayed parts, but instead changes a lot of settings/properties for the web page, such as screen resolution/size and base font size. This is generally useful, because it allows websites to adapt to these changes (such as by eventually displaying their mobile layout), but it also makes things more complicated in this case, because the position of both the panel and their button divert.

This means, that the positioning code would have to check for every screen resize event and then recalculate the position and re-apply. The current implementation sets the position when the panel is opened, which is a good-enough bet IMO.

Given that changing this would likely make the code more error-prone and would probably only result in some stuttery movement (have not tested, but re-rendering due to a browser-resize/scroll event is generally discouraged AFAIK), and given that zooming in while a panel is open is IMO very rare and that the issue can be easily resolved by closing and reopening the panel, I don't think this change would be worth the development effort to implement.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

I'm happy with this. Anyone who's not, please say. (1 comment)

Sign up to answer this question »