Form not savable when event has long title

[tyler-dane]

Prerequisites

• [x] Using an up-to-date main branch

Expected Behavior

Title/description in form is truncated, so that the user can still see, hover over, and click the Submit button

Current Behavior

Title takes up the entire view height, hiding the save button. User can TAB until focus is on Save and type Enter (but no one does that).

Steps to Reproduce

1. Create event with long title

2. Open event

3. Notice: No save button viewable

Possible Solution (Not obligatory)

Some ideas:

• Truncate the title using a lineClamp value, similar to how the event rectangle is doing the same on the grid/sidebar.
• Instead of truncating based on the title, create a max line height based on the view height
• See if there is some way to configure the minimum bottom padding for floating UI

Context

User is unable to easily save events because of this 💀

[SuvineetSingh]

Hi @tyler-dane, can you assign this issue to me? I want to try solving this issue.

[tyler-dane]

Hi @tyler-dane, can you assign this issue to me? I want to try solving this issue.

Sounds good!

[tyler-dane]

Unassigned due to inactivity

[MrPand-21]

Hi, I've seen this project recently and implemented in my own project. The systematic approaches and choices are reasonable (probably you made the explanations in other prs but there are +200 of them, you can't blame me :) ), yet I believe there are rooms to improve in terms of frontend design.

I can keep up with that issue if you assign me and see if we can change more in the future ( I hate styled components and migrating this project back to tailwind was... terrible ---could be a personal problem ofc, also defining constants everywhere without a clear order became a bit messy )

[tyler-dane]

Hey @MrPand-21 Thanks for the willingness to help.

This issue is a high-priority one that was already planned to get done by tomorrow, so I'm afraid it's a little too late to reassign this to you.

Please find an issue with the Q1 or Q2 milestone instead that you could finish before the assigned End date. I just created a new view to make that easier to do: https://github.com/orgs/SwitchbackTech/projects/4/views/8

Here is the updated workflow for picking up issues: https://docs.compasscalendar.com/docs/contribute/#workflows.

---

Agree that Tailwind > styled-components. However, we don't have the resources to invest in migrating CSS tools. This is something we can considering doing after becoming profitable at the end of this year.

[MrPand-21]

@tyler-dane Thanks for preparing the view, I will see the other issues as well.

Other than that, what does the "resources" mean in that context? I am aware that the issues you present @ the view are prioritized yet I could migrate the project to Tailwind in a week and believe this won't be problem for me. Consequently, since the codebase will change, if other developers are not in good terms with tailwind, that would bring an impending problem to allocation of "resources" but besides that, I am not sure how that could harm the project overall.

[tyler-dane]

Sure, happy to expand. The resource I'm wary to invest in this CSS rewrite is time. I'm flattered that you'd be willing to do this and impressed that you could do it in a week. However, it'd take hours to properly review the PR, QA it, understand any gotchas, and fix any bugs in the process. That's acceptable for a feature or bug that would benefit the user and make them more likely to pay in 2025. But I don't see how Tailwind would help us get profitable in 2025 any quicker. On the contrary, it seems like it'd just set us back.

There will be a time for investing in more modern tools that better align with our preferences as developers, but we don't have that luxury now unfortunately