Homebrewery allows for an extended Markdown-like syntax for more complex tables which is helpful when building something like D&D class tables. In Basic Tables the regular syntax for simple Markdown tables was covered. Simple tables will likely cover most of your use cases, and everything starts from there, so be sure you have read that if you are new to Markdown. The modified syntax used by Homebrewery enables row and column spanning and setting column widths without CSS.
The extended syntax allows for column and row spanning by modifying the use of the pipe character | for columns and adding the ^ character for rows.
Spanning Cells Across Columns
Columns in Markdown are created with the pipe character | with at least one space between. And, each row must have the same number of pipes.
To indicate that a cell should occupy two columns it is still necessary that the same number of pipes is used in every row, but the neighboring cell should have no space between its pipes. For one row, that looks like this:
| Column 1 | Column 2 |
| My cell that spans two columns ||There are still 3 pipes in each row, but that spanning cell bunches its pipes together at the end.
For a more complicated example, here is the first few rows of D&D class table, where the header has a “Spell Slots Per Spell Level” header grouping that is actually a cell that spans all of the columns below it:
See that large set of |||||||? That is enough pipes to span the “1st” to “9th” columns and lets the group header sit above those columns, centered because the first column that is spanning is set to be centered align (|:--:|).
Spanning Cells Across Rows
To span a cell across a row requires a new symbol, the ^. It needs to be placed at the end of the cell that is going to be spanned, right against the pipe. In this example, “my cell” will expand upwards into the cell above it:
| | |
| my cell ^| |Back up to the Class Table example above, you can see this being used in the first few columns. This is because the “Spell Slots per Spell Level” cell adds a second column to the header, and so the first few header columns need to have their cells expanded across that row as well.
One thing to note is that if both rows have content, that content will be concatenated together in the resulting cell after they are combined. It doesn’t matter if you have your content written in the top line of your spanned cell, or the bottom line, they’ll appear the same way in the result.
Combining the Two
There may be some cases where you want to expand a cell across both rows and pipes, and it’s pretty simple to do so:
I left the content “0” and “300” in their respective Markdown lines to demonstrate that they’ll be concatenated together 0 300 in the result after the row span, and added a border to the cells to really show the layout.
Setting Column Widths
One more addition to the table syntax is percentage-based column widths right in the table Markdown. Typically you would have to use CSS to set the individual column widths using selectors like .page table th:nth-child(1) { ... } to target the first column and apply a width property– and in order to do that per table, you’d likely wrap it in a div with an id and target that specific id. The extended syntax saves that effort, as long as you are satisfied with percentage widths.
In the “separator” line of a Markdown table, where only dashes and colons are generally allowed, you can actually add a n% number to set the width for each column. Any column that doesn’t have one will follow the normal default rules of setting column widths (an algorithm determined the browser).
The width indicator must still be surrounded by at least one dash - on each side.
It will not break words to wrap, at least not without additional css applied. So the width you use, if it’s too small, may not be entirely what you were expecting.
Another Example
A quick example of adding “sub” or conjoined tables, using column spanning:
Closing Thoughts
Creating complex tables is something commonly done in the TTRPG space, and so having that flexibility to span cells is very helpful. And it might be tempting to consider using tables to manage layout, particularly if you are looking at something like a character sheet and thinking that it looks very “table like”. Avoid this; stick to tabular data for tables and using proper layout elements plus styling to manage how your pages are organized.
In the future, I’d like to see absolute column widths allowed in the custom column width syntax. Setting column widths with at least px (if not other length units like cm, in etc) would help with making sure that different tables on the same page have the same layout without relying on CSS.