You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm embarrassed to say that way multi-day events are rendered doesn't work with days that have a defined background color due to my completely forgetting about the z-index stacking context (which is different for each day since the events are grandchildren of the day they start).
There seem to be only two solutions:
Draw the calendar grid twice, once for borders and background colors and again for days and events, using the same metrics for both. This would put the events on a plane that is transparent, allowing them to "spill over" on top of siblings of their grandparent element. We can still use z-index to avoid vertical spilling.
Position each event relative to the grid upper-left corner, separately from rendering the grid. This can still be done with classes indicating the week number, day of week, and event number on that day. This would require having a hard-set day and event height, providing the end developer no flexibility in margins, padding, font size, or border size unless they override a significant number of classes.
The final solution is to simply not support background colors by the day. It would still be safe to do so to the day number row, but not the area where the events live. This may be the best short-term solution.
The other open issue is how to handle staggering of the "slots" for each day. The current approach minimizes overlap, but doesn't completely avoid it. To avoid overlap, each day must be rendered with knowledge of which "slots" are already spilling over from previous days of that week, and thus not reuse them. This is making me lean toward solution (2).
Not sure when I'll have time to work on this.
The text was updated successfully, but these errors were encountered:
Resolved by rewriting the component to (a) render by week and (b) move the events out of the day blocks, positioning them over the week using a calculated vertical and horizontal offset. This also gave me the opportunity to fix proper utilization of each slot on each day. Also improved drag and drop.
I'm embarrassed to say that way multi-day events are rendered doesn't work with days that have a defined background color due to my completely forgetting about the z-index stacking context (which is different for each day since the events are grandchildren of the day they start).
There seem to be only two solutions:
Draw the calendar grid twice, once for borders and background colors and again for days and events, using the same metrics for both. This would put the events on a plane that is transparent, allowing them to "spill over" on top of siblings of their grandparent element. We can still use z-index to avoid vertical spilling.
Position each event relative to the grid upper-left corner, separately from rendering the grid. This can still be done with classes indicating the week number, day of week, and event number on that day. This would require having a hard-set day and event height, providing the end developer no flexibility in margins, padding, font size, or border size unless they override a significant number of classes.
The final solution is to simply not support background colors by the day. It would still be safe to do so to the day number row, but not the area where the events live. This may be the best short-term solution.
The other open issue is how to handle staggering of the "slots" for each day. The current approach minimizes overlap, but doesn't completely avoid it. To avoid overlap, each day must be rendered with knowledge of which "slots" are already spilling over from previous days of that week, and thus not reuse them. This is making me lean toward solution (2).
Not sure when I'll have time to work on this.
The text was updated successfully, but these errors were encountered: