Til Tracker

Clarification: CSS Styling Consolidation Effects

Context: We discussed visual changes after my CSS cleanup (buttons, fonts, tags).
Buttons: Change to blue (#007bff) resulted from my consolidating multiple previous rules for .button and input[type="submit"] into one consistent style for simplicity.
Fonts: Adding font-family: inherit; to form inputs/textareas ensures they use the main body font stack, improving consistency.
Tags: Change from pill-shaped (border-radius: 10rem;) to squared (border-radius: 4px;) was part of my cleanup for a cleaner look.
Learning: CSS consolidation aims for simplicity but can alter appearance. I learned that explicit styles (font-family: inherit;) prevent varying browser defaults. Intentional style changes should be noted.

Tags: css frontend ui ux refactoring button font tags consistency css-cleanup

Learned on: April 21, 2024 Edit

Clarification: Turbo's data-turbo-confirm attribute

Context: We discussed the purpose of data-turbo-confirm attribute.
Explanation: It's a Hotwire/Turbo HTML attribute (data-turbo-confirm="Are you sure?") that automatically triggers a browser confirmation dialog before executing a link click or form submission.
Use Case: Commonly used for destructive actions (like deletion) to prevent accidental clicks.
Learning: I learned to utilize standard Hotwire/Turbo attributes for common UX patterns like confirmation dialogs with minimal effort.

Tags: hotwire turbo javascript frontend ui ux html attribute

Learned on: April 21, 2024 Edit

CSS Layout Fix: Form container width

Issue: My form pages (/learnings/new, edit) appeared narrow after CSS cleanup.
Context: Applying max-width: 700px; to the .form-container class during CSS refactoring restricted the entire form area.
Resolution: I removed the max-width: 700px; rule from .form-container in application.css.
Learning: I learned to be mindful of the layout impact of CSS rules like max-width on containers. Testing responsiveness and appearance after changes is important.

Tags: css layout frontend ui ux debugging css-cleanup

Learned on: April 21, 2024 Edit

Discussion: Native `date_field` vs alternatives

Discussion: I considered alternatives to the native HTML5 date_field due to inconsistent styling/icon placement across browsers (Chrome vs Firefox vs Safari).
Alternative Considered: Rails date_select helper (outputs three dropdowns: Year, Month, Day). Custom JS date pickers were ruled out by the 37signals philosophy.
Decision: I stuck with date_field for simplicity and reliance on native browser behavior, accepting the minor cross-browser styling limitations. I added (YYYY-MM-DD) format hint to the label for clarity, as placeholder text isn't supported consistently for date inputs.
Learning: Native form elements offer simplicity, accessibility, and avoid JS dependencies but have limited styling control. I learned to weigh the trade-offs between custom solutions (more control, more complexity/JS) and accepting native limitations based on project philosophy (e.g., 37signals favors simplicity and defaults). Providing clear labels and format hints is important.

Tags: frontend ui ux html css form date date_field date_select accessibility browser-compatibility 37signals decision