"List", "Gantt"... (view type) buttons are unclickable on narrower screens #2022

Open
opened 2023-03-09 10:00:01 +00:00 by WofWca · 2 comments
Contributor

Description

They are covered by the "filters" element. On screen widths from 800 to 1000 when the sidebar is open.

Vikunja Frontend Version

0eb78e32

Vikunja API Version

v0.20.1+150-4f62e978ef

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

image

### Description They are covered by the "filters" element. On screen widths from 800 to 1000 when the sidebar is open. ### Vikunja Frontend Version 0eb78e32 ### Vikunja API Version v0.20.1+150-4f62e978ef ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? Yes ### Screenshots ![image](/attachments/d263fce3-8afb-4f0d-9bbc-832958ff0782)
WofWca added the
kind/bug
label 2023-03-09 10:00:01 +00:00
Member

Good catch. We have some open branches that would conflict with a too invasive change here. There is a lot that could be optimised. For a quick-fix I think adding using grid or flex on switch-view-container seems to do the trick.

For this we would need to remove the absolute position from the .filter-container.
@konrad Is there any reason why that is still absolutely positioned? We refactored that area a bit so I think the original reason for that being absolute doesn't apply anymore.

What I also do not understand is, why the min and max-width here is needed: fd3e7e655d/src/styles/components/list.scss (L13-L18)

Good catch. We have some open branches that would conflict with a too invasive change here. There is a lot that could be optimised. For a quick-fix I think adding using grid or flex on `switch-view-container` seems to do the trick. For this we would need to remove the absolute position from the `.filter-container`. @konrad Is there any reason why that is still absolutely positioned? We refactored that area a bit so I think the original reason for that being absolute doesn't apply anymore. What I also do not understand is, why the min and max-width here is needed: https://kolaente.dev/vikunja/frontend/src/commit/fd3e7e655dbbd59f9a94db0f18a3ef4876cec059/src/styles/components/list.scss#L13-L18
Owner

Is there any reason why that is still absolutely positioned? We refactored that area a bit so I think the original reason for that being absolute doesn't apply anymore.

Not sure. I think the original reason was so that the search input animation works but also the positioning of the filter form. Since that's now a modal it should be fine to make this not absolutely positioned.

We need to make sure the kanban buckets height works on all screen sizes. There's too much calculation involved so that might break when we start to change things around the buttons.

> Is there any reason why that is still absolutely positioned? We refactored that area a bit so I think the original reason for that being absolute doesn't apply anymore. Not sure. I think the original reason was so that the search input animation works but also the positioning of the filter form. Since that's now a modal it should be fine to make this not absolutely positioned. We need to make sure the kanban buckets height works on all screen sizes. There's too much calculation involved so that might break when we start to change things around the buttons.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: vikunja/vikunja#2022
No description provided.