HTML question. As I understand it, there's only supposed to be at most one thead and one tbody in an html table. What's the best practice structure for a table that groups by some query column, and repeats the column labels after every group header?

The spec allows multiple <tbody /> elements. This is documented on MDN too: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/tbody

Worth noting (per the MDN spec) that you can only have one

<thead>

and one

<tfoot>

, but you can mimic header rows using

<tr><th>...</th><th>...</th></tr>

tags.

Thanks folks. You're right that there can be multiple TBODYs, but without a corresponding header element I don't get the point. It has no semantic meaning, far as I know. Yes, a TR containing THs is what I'm doing now. It looks right, I was just checking if that's best practice, or if there's some other better strategy. Sounds like no.

Nothing prevents tables in tables right? Or am I missing the point here? (Not totally unlikely 😃)

Multiple tbody is so you can group related fields, but the table heading/footer should be consistent. The MDN article gives some examples. As far as tables-in-tables go, you should be fine as long as the child table is inside a td/th element.

The table headers are consistent, but the table's tall enough that they should be repeated for each group. I don't think nested tables is the right answer here, the data is all the same, just need to repeat the column headers.

What is the effect you're going after? Is it so that when scrolling through the table the thead always remains visible?

No, here's a pic. Table is potentially quite tall, column labels only at the top is no good.

It sounds like you really want multiple tables, but just with a fixed column widths (so the column widths stay constant). For this case, multiple tables should help out a ton with the render time, because large table can require a ton of work to render.

Hi Dave, interesting. It is possible to make this using one table, but would require css property changes for each row. For example using styled div elements inside each TD element. Your loop can include logic that knows how to paint each row. But a basic (and more semantic) solution is to use three tables, then maybe add static widths to the TD elements to keep the column widths the same. To help modernize your table, using zebra striping makes sense, but consider removing (or deemphasizing) the rule lines.

For context, that pic is a small section of the page, this particular run has 600-700 rows, and lots more sections than this. Rendering is done by a generic query rendering cfc, so the logic and table structure, and even the css aren't specific to this data. Specific pages that use it can have their own css, which I suppose could have customized column widths. But in general I'd rather be able to just throw any data at it, and have it be ok. I can see what it looks like as separate tables, without trying to force a common width. Or maybe just set the overall table width, and let the columns auto adjust. The rows are striped, with the exception of the break header and col labels rows, it's just hard to see in this small sample. The top section shows it most clearly.

FWIW, I use multiple <tbody> tags to group and style related data, such as if an employee can have multiple records

I could do that, but it looks like there's no semantically significantly way to repeat the column labels for each one, beyond <tr><th> etc. Separate tbody tags doesn't really by you anything at that level.

Would using some css to make the headers sticky help? Or does this get printed?

If some of the semantics is for a11y, CSS won't help, but I'm a fan of sticky headers for usability (u11y? 😃).

The pic above shows what it looks like now, and visually I'm good with that. It's just repeated tr/th/th etc for each group, no need for sticky headers. All that's missing is a more semantically significant equivalent, which doesn't seem to exist. Thanks for the ideas folks, think I've spent my allotment of unproductive time on this 🙂

Semantically tables in tables seems like what you'd want, if the idea is that someone might want to select a table's worth of data, so to speak, versus all the tables data. Another way of looking at it would be from a "slurper" perspective. If you wanted to be able to "slurp" data, how would you make that easy? Tables in a table imho. FWIW it was fun to think about, and learn about (I wasn't sure what the latest was), productivity be damned! (Technically is research, so it counts as productive, if not high priority lol) 😜