Hanjiewu
September 11, 2026, 6:49am
1
When using a MultiQC custom content table, I noticed that column headers containing strings such as h1 and h2 are displayed with a different font size in the generated HTML report.
For example, if the custom table contains column headers such as:
h1, h2, and other normal column names
the h1 and h2 headers are rendered with noticeably different/larger font sizes compared with the other column headers.
ewels
September 11, 2026, 7:29am
2
hah, that’s kind of hilarious
Could you please attach an example file that I can use to reproduce this? Or better still, post it as a bug report issue on the MultiQC GitHub repository.
Thanks!
ewels
September 11, 2026, 7:44am
3
Follow up: I was able to replicate the bug myself locally, so no need to do anything. I’ll get a PR up to fix and let you know when it’s done.
ewels
September 11, 2026, 8:07am
4
Pull-request to fix this issue is up:
main ← claude/quirky-ramanujan-1j77pw
opened 08:05AM - 11 Sep 26 UTC
### Problem
Reported on the community forum: [Header contains h1 font size](h… ttps://community.seqera.io/t/header-contains-h1-font-size/2760). A custom content table with columns called `h1` and `h2` renders those column headers at heading size.
A table's column anchor was used verbatim as the CSS class on its header cell, its data cells and its row in the column-config modal:
```html
<th id="header_h1" class="h1" ...>
```
The anchor is derived from the column ID, so any column whose ID happens to match a Bootstrap utility class picks up that class's styling. Custom content is the easy trigger because it has no namespace, so the anchor is the raw column name.
<details>
<summary>Details</summary>
Measured in Chromium, `default` template:
| column ID | header before | after |
| --- | --- | --- |
| `h1` | 34px | 13.6px |
| `h2` | 27.2px | 13.6px |
| `small` | 11.9px | 13.6px |
| `row` | cells become `display: flex` with -12px side margins | `table-cell` |
| `table` | 16px bottom margin, `vertical-align: top`, stretched width | normal |
### Fix
Prefix the class with `mqc-column-` via a `_col_cls()` helper, and update the six matching jQuery selectors in `default/src/js/tables.js` and `original/assets/js/tables.js` (column show/hide, and the table scatter plot's value lookup). The `default` and `disco` compiled bundles are rebuilt.
The prefix deliberately avoids a `col-` substring. Bootstrap 3, used by the `original` template family, matches its grid classes with `table td[class*="col-"], table th[class*="col-"] { display: table-cell }`, which outranks `th.column-hidden { display: none }`. A `mqc-col-` prefix would therefore have made *every* column impossible to hide in `original`/`geo`/`sections`/`simple`/`gathered`. There is a comment on the helper to that effect.
### Testing
- [x] Code is tested and works locally
Driven through the real jQuery handlers in Chromium, on both the `default` and `original` templates, comparing against a build of the parent commit: column show/hide (including server-side `hidden: True` columns and the `numcols` counters), drag-reordering in the config modal, the table scatter plot (identical data points) and violin plot sync all behave exactly as before, with no console errors. Computed styles were diffed across every `th`/`td`: every change is a Bootstrap style being removed from a colliding column, landing on the same value as a normal column.
Checked that no CSS rule in either template family matches the prefixed class, for 58 candidate column names. The bare names collide 49-57 times, which is the bug.
All seven templates smoke-tested. `pytest`, `prek run --all-files` and `.github/workflows/code_checks.py` are clean.
### Note for anyone upgrading
`custom_css_files` that targets a table column by its bare ID as a class selector now needs the `mqc-column-` prefix.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_016XQgrcKcMe8nwQRQANa5sz
---
_Generated by [Claude Code](https://claude.ai/code/session_016XQgrcKcMe8nwQRQANa5sz)_
</details>
This will be included in the next release (v1.36) when it comes out.
Thanks again for reporting!
