| Issue 2264: | Cleaner markup | |
| 3 people starred this issue and may be notified of changes. | Back to list |
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
Status:
Done
Sep 1, 2014
Issue 2267 has been merged into this issue.
Sep 1, 2014
Issue 2268 has been merged into this issue.
Sep 1, 2014
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
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. |
|
| ► Sign in to add a comment |