Issue 2264: Cleaner markup
Status:  Done
Owner: ----
Closed:  Aug 2014
Reported by c.mac...@gmail.com, Aug 29, 2014
I don't understand why the markup goes as follows:
table > thead > tr > td > div > table > head > tr > th
table > tbody > tr > td > div > div > div > div > table > tbody > tr > td

When it could be as simple as:
table > thead > tr > th
table > tbody > tr > td

I think it would make adding a custom css to the component much easier.
There would even be no need to change/delete any of the already used classes, just transfer them from the divs to the actual table tags.
Aug 29, 2014
Project Member #1 adamrs...@gmail.com
The markup was much simpler in previous version, but it was also limiting. More advanced features needed a more complex DOM structure. I don't have time to list all the issues/features that required it, but some of them are here:

https://code.google.com/p/fullcalendar/issues/list?can=1&q=milestone%3Dskeleton

I tried to make the DOM structure as simple as possible but also solve those issues.


If you want to target a table cell, it might be simpler to do this:

    .fc-row .fc-bg td

or event more simply:

    .fc-day

I tried to put classnames on commonly referenced elements. please let me know if you need classnames on certain elements.
Status: Done
Sep 1, 2014
Project Member #2 adamrs...@gmail.com
 Issue 2267  has been merged into this issue.
Sep 1, 2014
Project Member #3 adamrs...@gmail.com
 Issue 2268  has been merged into this issue.
Sep 1, 2014
Project Member #4 adamrs...@gmail.com
Since this seems to be a common question, I'll outline the reasons I made the DOM more complicated.

In month view, you'll see the "rows" that represent each week are <div>'s with tables inside. One table is responsible for holding the events, another is responsible for displaying the rectangular cells. This setup is required to make the event rendering truly liquid-width without the need for absolute positioning ( issue 809 ). This was important to solve numerous printing problems ( issue 35 ) because rendering for printers really screws up with absolute positioning as well as condensing/screwing-up the calendar's width if it is not liquid.

(FWIW, Google Calendar uses this same technique)

As far as the top level `.fc-view > table` with a single-celled thead and tbody, that was done for  issue 35  as well. When there is too much event content that flows to other pages, this structure is required to have the table headers displayed on following pages. I tried to use <div>s with display:table-header and whatnot, but FF had some major bugs with that.

Also, I needed extra wrappers around the month view's day-content in order to make scrolling work ( issue 728 ). A single unified table structure would not work for this.

@bushidodesigns, your proposed DOM structure does not take into account multi-day events and the complex vertical stacking problems that go along with that. Those mandatory features makes it impossible for an event to be a simple sibling of a day's table cell.

As far as accessibility, v2 has some improvements actually. I have made the header buttons actual <buttons> that can be tabbed. All events are <a> tags that can be tabbed too (if they have a url).

In terms of screen readers, there have got to be alternate solutions to adding semantic meaning to the markup without having to dumb down the rendering. I've created  issue 2271  specifically to continue the discussion for screen readers.

Drag-n-drop accessibility has very little to do with the HTML markup.  We can arrive at a solution w/o having to dumb down the skeleton. @bushidodesigns, those keyboard drag-n-drop links are helpful. I have created  issue 2270  to deal with mouseless drag-n-drop.

Please star the relevant new issues I've created.
Sep 1, 2014
Project Member #7 adamrs...@gmail.com
PS- as previously stated, if you want to style a certain element in the DOM structure, you should target the className directly (instead of doing sibling selectors like "table > thead > tr > td" etc), like ".fc-day" or whatever. If you want to target something and it does not have a className for you to grab onto, please request that as a feature request.