While looking around for common responsive patterns to build with CSS Grid Layout, I came across this Responsive Calendar example.
I rebuilt the pattern using CSS Grid Layout, you can take a look at the CodePen below however you will need to enable CSS Grid Layout in your browser.
See the Pen Responsive Calendar Pattern by rachelandrew (@rachelandrew) on CodePen.
However this pattern seems not to be ideal from an accessibility standpoint. Marked up as a list, the day names are disassociated from the days themselves. I’ve always felt a table to be a more semantic representation of a calendar – but tables are hard to make responsive. It is not surprising that people choose another type of mark-up when needing to add a calendar to an application.
As an experiment I turned the list markup back into a table, and then used CSS Grid on the various table elements so the browser was now displaying the table using display: grid and associated properties rather than display: table.
See the Pen Responsive Calendar with a table by rachelandrew (@rachelandrew) on CodePen.
A few points:
- I have had to declare grids “all the way down”, due to lack of subgrid support meaning I could not just declare a grid on table and use it through all of the children. Only direct children become grid items of the container with
display: grid(just like flex items anddisplay: flex) - I think
display: contentswould actually work in this scenario, if it were implemented in Chrome. - Anonymous elements (such as the
tbody) not explicitly added to my mark-up were becoming child elements of the grid container so needed to be accounted for. - If this wasn’t an experiment it could be further simplified by using the regular table display when at full width, and then gridifying it only for the narrower viewport versions.
Grid is a good candidate for doing this kind of thing, as it is conceptually “table like”. It’s a pretty easy mapping from the logical table structure in HTML to Grid Layout, it would be excellent if this enabled far better responsive table patterns in the future.
The problem of multiple day events
Something that is a difficult issue in calendaring is dealing with multiple day events. We have this come up in Perch from time to time. People would like to be able to use the Calendar App to display multiple day events but other than simply adding the event to each day, there isn’t a great way to do that. A way that makes sense semantically and is also possible to template.
Building this example makes me wonder if Grid could be used to layout out a highlighting box around multiple days to show the span of an event in a better way, however I still don’t have a good answer for how that should be marked up. If you have a suggestion, pop it in the comments.
8 Comments
Maybe the challenge is to dispense with some of the idea’s of the traditional calendar. Let’s face it, the design has been pretty rigid, and everyone approaches with the same assumptions.
“How do I, make my calendar, look like every other calendar”
In my opinion, most miss an opportunity to add value. It’s great you are working on this, but play with the concept, I’d love to see what alternatives might be acceptable, and hope think you could potentially make everyone’s lives easier.
@Lewis I think you missed the point of the article. What I am interested in doing is finding common patterns and seeing how they can be implemented using the new layout tools that I am experimenting with.
If you believe there are better ways to lay out a calendar then it would be a great idea for you to post your own experiments, but it isn’t something I am working on.
Also consider trying out how display:contents could be incorporated into the demo in order to simplify the grid code. If it works well, that would be a good argument for the other browsers to implement it.
@Šime: I mentioned in my notes that I think display: contents would work here. Although I do not think it a panacea for lack of subgrid support. It would work in this example because we’re doing very simple inheritance of the grid.
Why not address accessibility using the WAI–ARIA standards which have been widely supported for a long time, even by old browsers, instead of struggling with experimental CSS?
Or perhaps what you in fact meant by “accessible” was “tabbing”?
Tabbing alone won’t help you pass VPAT.
@stephane – see “First Rule of ARIA use” at https://www.w3.org/TR/aria-in-html/#first-rule-of-aria-use
I explained in the post what I meant by “accessible”, I wasn’t inferring any particular level of support, just that it is never a great idea to strip semantic mark-up just to get a visual effect. As for “struggling with experimental CSS”, no-one is struggling. I’m experimenting to see what is possible with a new specification, because that’s how we figure stuff out here on the web.
Would be nice if the month and weekdays didn’t scroll. Or stated differently, does grid provide a solution for fixed table headers and scrolling table bodies?
Would be nice if the month and weekdays didn’t scroll. Or stated differently, does grid provide a solution for fixed table headers and scrolling table bodies?