refactor(datepicker): use relative units for datepicker sizing

[spliffone]

---

Documentation.
Examples.
Dashboards Demo.
Playwright report.

Coverage Reports:

• charts-ng
• dashboards-ng
• element-ng
• element-translate-ng
• maps-ng
• native-charts-ng

[gemini-code-assist]

Code Review

This pull request refactors the datepicker styles by replacing fixed pixel values with relative units (rem and ch) and correcting a comment in the SCSS file. A critical issue was identified where units were omitted for block-size and line-height in the .selection class, which would result in invalid CSS.

[dr-itz]

this is too much as there are also some px based margin/paddings. Since we want to avoid calc here (nightmare to maintain):

• add a rem-based min-block-size to the .calendar ::ng-deep table
• add a min-block-size with calc for the footer in day-selection and empty dummy footers to the year/month selections

(and also we're showing too many weeks e.g. for February/March 2026)

[spliffone]

I will have look.

(and also we're showing too many weeks e.g. for February/March 2026)

Showing so many weeks is on purpose - it was requested from Timo.

[dr-itz]

@timowolf why? I think this is confusing. Showing half of March when the selected month is February...i.e. what is the added value?

/cc @panch1739

[panch1739]

@dr-itz i think is how it works now? Our current date range is already showing all the off-month days. Im not sure why it was decided this way 🤷

[spliffone]

@panch1739 @dr-itz as far as I remember it was introduced with the date-range two-month view. In worst case - one view hat 6 rows since the month started and ended in the middle of a week and on the other side it ended exactly on the last day of the week (only 5 rows). Means the two views had a different height and the divider was on different positions or it looked somehow unbalanced. @timowolf Correct me if I am wrong.

[github-actions]

⬇️ Download VRTs