MediaWiki talk:Gadget-StickyTableHeaders.css

"and firefox's sticky support seems completely broken"

It's not completely broken, but it doesn't currently work on table cells much like how you point out that Chrome's support doesn't work on <thead>. It looks like the upstream bug for that is 975644. Anomie⚔ 14:55, 28 March 2017 (UTC)

Testing...
...
...
...
...
...
...
...
...
...

Div Header

...
...
...
...
...
...
...
...
...
...

Div Footer

...
...

<th> Header
...
...
...
...
...
...
...
...
...
...
<th> Footer

...
...
...
...
...
...
...
...
...
...

Firefox 59 supports sticky headers

I know the change was made a while ago in the gadget, but release channel Firefox 59 only popped out this week. Yay! You might consider tweaking the gadget description, which says it requires Safari or Chrome.

However, it looks like Timeless doesn't play well with it? No headers are sticky. :( Vector works. --Izno (talk) 23:01, 17 March 2018 (UTC)

Still clobbers borders too, but that's a minor offense. --Izno (talk) 23:02, 17 March 2018 (UTC)

Is it that no headers are sticky, or that they "stick" underneath Timeless's own non-scrolling page header where they're not normally visible? Anomie⚔ 14:17, 18 March 2018 (UTC)

@Anomie: It looked to me (with two rows with of headers, one of which was two lines, ref test page) that they weren't sticky, not that Timeless was clobbering them. I haven't tried with three or four rows of headers. --Izno (talk) 16:22, 18 March 2018 (UTC)

Headers now sticky in Timeless. Yay. However, references apparently have a higher z-level, so the headers end up displaying with references in front. Firefox 60.0.2. Found this one on ...Baby One More Time (song). --Izno (talk) 14:44, 14 June 2018 (UTC)

So, the headers are sticky but there's something going on with some weird whitespace displayed only in monitor resolutions. (At sub-monitor resolution, no issue.) The change corresponded with a Thursday deploy I'd guess. --Izno (talk) 18:07, 28 October 2018 (UTC)

@Anomie and TheDJ: The heights were changed some while ago in Timeless. At least in Firefox, 3.3em fits a lot better for me in the resolutions above 1100px rather than the 6em in the current gadget (the whitespace above is not actually whitespace but the 'background' of the rest of the page). (The 850px-1100px region is still fail.) Would one of you mind adjusting that and/or checking Safari? --Izno (talk) 01:20, 22 November 2018 (UTC)

Bug: rowspan in headers does not propagate into table

As found at Help talk:Table#Non-rectangular tables example broken, code such as:

{| class=wikitable
!a
!rowspan=2|b
!c
|-
|x
|z
|}

a	b	c
x		z

does not leave space for column 2 in row 2 (where "b" should spread due to rowspan=2), but instead "z" is immediately adjacent to "x" and the third cell in row 2 is blank. DMacks (talk) 19:30, 28 June 2018 (UTC)

Well that's not what you are supposed to do with tables. If you stand on your head, things will be upside down. ;) —TheDJ (talk • contribs) 00:46, 29 June 2018 (UTC)

It's an example from Help:Table. And it gives valid HTML and renders correctly with the gadget off and does not appear to be forbidden or recommended against in the standards. DMacks (talk) 02:37, 29 June 2018 (UTC)

Tables are also used to layout entire pages. also allowed, renders, just not what they were made for. —TheDJ (talk • contribs) 07:53, 29 June 2018 (UTC)

@DMacks: So, I've been working to understand TheDJ's argument about why the markup in question is "wrong", and after a lot of investigation, I have to say: I agree.

The issue comes down to how the table renders into HTML, and then how the browser in turn parses that HTML. While the table "looks right" with the sticky-tables gadget turned off, that's only by pure luck, because it's already in an invalid state within the browser's DOM tree. Turning on the gadget merely exposes that invalid state. Using Special:ExpandTemplates, here's the raw HTML for that example table above:

<div class="mw-parser-output"><table class="wikitable">
<tr>
<th>a
</th>
<th rowspan="2">b
</th>
<th>c
</th></tr>
<tr>
<td>x
</td>
<td>z
</td></tr></table>
</div>

But the real problem comes in when Chrome (or any standards-compliant browser) parses that HTML. Because the first row is made entirely of <th> cells, the browser wraps a <thead> around that row. The second row, being that it only contains body cells, goes into <tbody>. Which means that the <thead> and <tbody> are not discrete, because the middle cell occupies both. That's invalid. And since the gadget manipulates the <thead> block of the table, when it's enabled the rendering of that invalid structure breaks.

In the HTML, the table can be corrected by converting the <th rowspan=2> into <td rowspan=2>. When that's done, there are no longer any pure header rows in the table, so the table is parsed as having an empty <thead> and the entire structure in the <tbody>. That's perfectly valid, and displays correctly even with the gadget enabled:

<div class="mw-parser-output"><table class="wikitable">
<tr>
<th>a
</th>
<td rowspan="2">b
</td>
<th>c
</th></tr>
<tr>
<td>x
</td>
<td>z
</td></tr></table>
</div>

a	b	c
x		z

Wikitable syntax doesn't allow mixing regular data cells into column header rows — when a row starts with ! Header !!, all of the cells are header cells even if they have || separators. But, it does allow data rows with header cells mixed into them, via scope="row". Which means that a version of our original nonrectangular table example from Help:Table which is fully compatible with the gadget would look like this:

{| class="wikitable" style="border: none; background: none;"

! scope="row" | Year
! scope="row" | Size 
| rowspan="5" style="border: none; background: none;"|
! scope="row" | Year
! scope="row" | Size 
| rowspan="5" style="border: none; background: none;"|
! scope="row" | Year
! scope="row" | Size 
|-
| 1990 || 1000<br />(est) || 2000 || 1357 || 2010 || 1776
|-
| 1991 || 1010 || 2001 || 1471 || 2011 || 1888
|-
| colspan="2" style="text-align: center;"|⋮
| colspan="2" style="text-align: center;"|⋮
| colspan="2" style="text-align: center;"|⋮
|-
| 1999 || 1234 || 2009 || 1616 || 2019 || 1997<br />(est)
|}

Year	Size		Year	Size		Year	Size
1990	1000 (est)		2000	1357		2010	1776
1991	1010		2001	1471		2011	1888
⋮			⋮			⋮
1999	1234		2009	1616		2019	1997 (est)

Here again, the table is parsed by the browser as having an empty <thead>. The entire structure is enclosed in the <tbody>, which means it's ignored by the sticky-headers gadget. -- FeRD_NYC (talk) 12:33, 5 July 2018 (UTC)

In fact, I just tested and the same thing works, and renders correctly, if scope="col" is used on the header cells instead of scope="row". Which is arguably more correct semantically, since the header cells are meant to apply to their column. -- FeRD_NYC (talk) 12:54, 5 July 2018 (UTC)

Borders in sticky headers

Border=1 is in HTML5. Rules=all and cellpadding=x are not. Just wondering if any of this might help.

---

{| class=wikitable

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

---

{|

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

---

{| border=1

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

---

{| rules=all

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

---

{| border=1 rules=all

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

---

{| border=1 rules=all cellpadding=3

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

---

It looks like rules=all might somehow solve the header borders problem. -- Timeshifter (talk) 22:36, 31 May 2019 (UTC)

border-collapse works and is HTML5 compliant

I forgot to mention I am using Firefox.

border=1 is also HTML5 compliant, and must also be used for this to work.

{| border=1 style=border-collapse:collapse;

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

By the way, for those who don't know, the table is from the "insert a table" button on the 2006 editing toolbar. A similar table can be had from clicking the table button in the advanced menu of the 2010 editing toolbar.

See: Special:Preferences#mw-prefsection-editing. There one can enable this:

• Enable the editing toolbar. This is sometimes called the '2010 wikitext editor'.

I normally have the 2006 editing toolbar (plus extensions) enabled. I have the following 3 gadgets enabled in the editing section of gadget preferences:

• Enable the legacy (2006) editing toolbar. This will be overridden by the "Enable the editing toolbar" option in the Editing tab.
• refToolbar: add a "cite" button to the editing toolbar for quick addition of commonly used citation templates
• Add extra buttons to the old (non-enhanced) editing toolbar

They just add more buttons to the 2006 editing toolbar. Unfortunately, both toolbars can not be enabled at the same time. The 2010 preference will override the 2006 preference setting. --Timeshifter (talk) 09:26, 1 July 2019 (UTC)

Row headers in sticky

You might want to take a look at what turning stick on does to the row headers in this table in Firefox. As you scroll up the page, the row headers in the bottom half of the table start to overlap and obscure those in the top of the table. SpinningSpark 18:27, 2 May 2020 (UTC)

Character	1	2	3	4	5	6
А	П
Б	Л
В
Г
Д
Е
Ж
З
И
К
Л
М
Н
О
П
Р
С
Т
У
Ф
Х
Ц
Ч
Ш
Щ
Ъ
Ы
Ь
Э
Ю
Я

Sticky headers not working with scrollable tables (Timeless)

So, it doesn't work with Timeless anymore. While I'm really not sure how to fix this, from a brief investigation, it looks like the issue is with the css - position:sticky appears to not play well with overflow:hidden/scroll or some such, for whatever reason?

Dunno, but I'm about to have entirely too much fun attempting to implement sticky scrollbars, and as a result of this rather stupid limitation that might just need to go full CodeMirror... mind you, if this actually does turn out to work, that might actually be the way to go here for better cross-skin and -browser support anyway. Maybe. -— Isarra ༆ 21:04, 14 December 2020 (UTC)