Designing a dynamic responsive week calendar

Question

I'm creating a dynamic responsive week calendar, using Twitter Bootstrap.

Here's my current implementation: http://jsfiddle.net/dvirazulay/Lhe7C/ (was a little long to paste in here in full)

And here is a current screenshot of it:

What I'm trying to achieve is a design which will be fully dynamic - generating the initial view from my back-end is no issue, but is a little complicated, as my current implementation uses tables. I fear it will be hard to maintain it on the JavaScript side of things, i.e removing events/adding them on the fly.

Obviously, I picked tables as it made sense to me - a week calendar is basically a table. I'll describe my design:

1. An event may span for more than 30 minutes, so I use rowspan to define how many hours it should span on.
2. There might be two events conflicting (I don't allow more than two). As it currently set-up, they show up next to each other, each taking 50% of the event width and taking as much as height as they need to represent the ending time.
3. On the back-end side, I calculate how many td I need to skip in order not to have extra columns at the end of the table (as rowspan pushes some to the right)

My questions are the following:

• Is this the right approach?
• Should I apply the same back-end logic to the front-end, and re-calculate the amount of tr/td to show according to the amount of events I have, or is there a better solution for this?

Ideally, a good answer should describe how to handle events on the front-end side without complications or an alternate (responsive!) design for this issue.

I don't want to use an existing plugin, as I've searched and tried multiple ones, and I want to keep this really light weight, but if you have a great suggestion for one that fulfills the requirements - I would love to check it out! (jQuery week calendar is too slow and cluttered for example)

Note: I have no intention to support browsers older than IE9.

Answer 1

After researching the issues and consulting with a few front-end experts, I've concluded that keeping it as tables is the best option, even if generating it is not trivial.

While this decision makes it hard to dynamically change the schedule without re-generating the whole table, the benefits of styling elements that should be a table as a table pay up - aligning, widths, heights, borders, etc. are all easy to control and work great cross-browser.

An important note is that this approach is making the responsiveness of the schedule a trivial quality.