Template talk:Sticky header

Archives

This page has archives. Sections older than 90 days may be automatically archived by when more than 5 sections are present.

Overwriting of style attributes for rows

With sticky header

Host country

Without sticky header

Host country

Games	Athletes	Gold	Silver	Bronze	Total	Gold medals	Total medals
1896 Athens	14	11	7	2	20	1	2
1900 Paris	75	19	14	15	48	2	2
1904 St. Louis	526	76	78	77	231	1	1
1908 London	122	23	12	12	47	2	2

Unfortunately, when using the sticky header template, the style attribute for an entire row is overwritten (like the border attribute in the example here). Would it be possible to fix this? Miria~01 (talk) 13:33, 16 August 2024 (UTC)[reply]

@Miria~01: Wikipedia collapses borders. When elements are sticky, some borders are missing. To fix this, this template separates the borders. Because of the fix, you won't be able to apply borders to the table row (tr), only the table header and data cells (th and td).

Also, using a border as the only means to indicate data is not accessible for screen readers. Maybe add "(host)" to the games data and make the cell bold or add a background-color. Then the legend can be removed. Jroberson108 (talk) 16:54, 16 August 2024 (UTC)[reply]

Thanks for the explanation. Unfortunately, since this visualization is used in several articles (United States at the Olympics, Germany at the Olympics, Japan at the Olympics etc.) a consensus would first be needed for a different representation of the host. Nevertheless, thanks for the quick reply Miria~01 (talk) 19:14, 16 August 2024 (UTC)[reply]

@Miria~01: You're welcome. If there is a discussion about accessibility, the info I mentioned can be found at MOS:COLOR, specifically "Ensure that color is not the only method used to communicate important information.". Another option is to add a "(*)" or better an "(h)" next to the games along with a legend. Just some ideas. Jroberson108 (talk) 22:59, 16 August 2024 (UTC)[reply]

Top sticky is not in the right place in Firefox

Chrome, Edge, and Opera are working fine in Win 10 11 Pro PC monitor. Top sticky bumps up against the top of the screen as it should. Firefox top sticky does not bump up against the top of the screen.

I noticed this first on a couple homicide tables.

I then checked What Links Here, and it is true for all uses of Template:Sticky header as I went down the list a little:

Special:WhatLinksHere/Template:Sticky header

--Timeshifter (talk) 08:32, 18 August 2024 (UTC)[reply]

@Timeshifter: Looking at Assault#Statistics. I'm logged in using the Vector (2022) skin on Windows 10. The template styles were built so that when any browser (including Firefox) is less than 1000px wide, the table row sticks to the top of the page with a sticky hamburger button above and to the left. I cannot change the hamburger button. At 1000px or wider, a sticky bar appears at the top with the page title "Assault" and buttons, and the table row sticks under it. It looks like Wikipedia changed their styles so the hamburger button isn't replaced by the bar at 1000px anymore, but at 1120px. So from 1000px to 1119px, the row is sticky under the hamburger button instead of the top of the page. Is this what you are talking about? Jroberson108 (talk) 18:02, 18 August 2024 (UTC)[reply]

It was actually my Win 11 Pro PC that has the problem. In Vector 2022 on a 27 inch screen. My Win 10 Pro PC does not have the problem on a 43 inch screen. It is also using Vector 2022 since I am signed in on both.

What I notice is that the table is stuck below the hamburger button on Win 11 Pro. That hamburger button is no longer on the title row as it is on the Win 10 Pro PC.

I thought there was some kind of Z-index setting that could be set to make the title bar be on top of the hamburger button.

https://www.google.com/search?q=Z-index+setting+that+could+be+set+to+make+the+title+bar+be+on+top

I am clueless about that stuff though.

Is this a viewport thing, or something? I don't know what you are referring to with the pixel sizes. Tell me what you need, and how to get it.

I noticed some interesting things about Template:TOCright. I copied it to some other wikis. I like how at a certain narrower screen width the TOC moves to the left like a regular TOC. Instead of staying on the right and causing some weird stringy wordwrap next to it. And I think it is done without Javascript. I don't know if this is of help or not with this. But you have talked of the need for non-javascript ways to react to screen and viewport width.

The problem exists here too, and I can't substitute {{sticky table start}}:

Wikipedia:Reliable_sources/Perennial sources#Sources

Due to the problems discussed here:

Template talk:Sticky table start#Expanded table is not sticky. Also, background colors removed

I notice in Chrome on the Win 11 Pro PC that the hamburger button is also separated from the title bar. The button overlaps the sticky header. So the sticky header can bump up against the top of the screen. Fortunately, the column header for the leftmost column is center aligned. --Timeshifter (talk) 01:02, 19 August 2024 (UTC)[reply]

Viewport width in pixels is what I'm referring to. I fixed the width in the template styles. I looked at {{TOC right}}, but it doesn't look to be working according to its talk page and its usage on Alien. Its documentation also says it doesn't work on Vector 2022. I've tried in the past to change the hamburger button so it's behind with z-index or moved closer to the top and/or left side of the page so it's more out of the way, but no luck. FYI, it's not an issue with {{sticky table start}} since the table elements stick to the div, not the page. For Wikipedia:Reliable_sources/Perennial sources#Sources, as discussed on the talk page you linked to, the TOC link problem was fixed and their styles just needs "!important" added to the five background-colors. Jroberson108 (talk) 06:43, 19 August 2024 (UTC)[reply]

Problem is solved now. Thanks.

It looks like {{TOC right}} is only being used on disambiguation pages. And it looks like it is being treated like __TOC__ is treated in Vector 2022. It is ignored. It makes sense since it is not really needed in Vector 2022. Vector 2022 already has a TOC that is out of the way.

On Fandom and Shoutwiki wikis {{TOC right}} is working. Neither of those 2 wikis has implemented a standard 2022 Vector skin. --Timeshifter (talk) 09:29, 19 August 2024 (UTC)[reply]

This template stops another from working without the wikitable class

Moved from Template talk:Row hover highlight § Doesn't work when using sticky headers without wikitable class

~~Link: Template talk:Row hover highlight#Doesn't work when using sticky headers without wikitable class.~~ George Ho (talk) 18:11, 26 October 2024 (UTC); struck, 19:05, 27 October 2024 (UTC)[reply]

When I added the {{sticky header}} and "sticky-header" class, as I noticed, the {{row hover highlight}} and the "mw-database" class don't work without also using the "wikitable" class. I tested this out in previews. George Ho (talk) 18:10, 26 October 2024 (UTC)[reply]

I just tested both templates together at:

"mw-datatable" and "hover-highlight" work with {{sticky header}} on wikitable tables. They don't work on non-wikitable tables when combined with the "sticky-header" class, but do work with "sticky-header-multi", which requires the table to be sortable. As far as I recall on non-wikitable non-sortable tables, there is a transparency issue where data shows through the sticky headers and so the table has a white background applied, which gets inherited by the rest of the table's elements excluding cells (th, td). I don't see many non-wikitable tables being used.

A solution would be to add "!important" to {{row hover highlight}}'s "tr.hover" "background-color" style. Jroberson108 (talk) 20:29, 26 October 2024 (UTC)[reply]

@George Ho: I adjusted the {{sticky header}} styles. It should work now. Jroberson108 (talk) 21:01, 26 October 2024 (UTC)[reply]

This edit that aimed to fix that problem broke background-colors for the WP:PRS table as noted at Wikipedia talk:Reliable sources/Perennial sources#Sticky header, loss of color. Pinging Jroberson108. DMacks (talk) 10:43, 27 October 2024 (UTC)[reply]

@DMacks: Seems the sticky headers were removed from the table at Wikipedia:Reliable sources/Perennial sources#Sources, so not sure if consensus is there to add it back. There are two prior conversations about the "perennial sources" pages background-color:

The "perennial sources" have a separate style sheet at Wikipedia:Reliable sources/Perennial sources/styles.css, which having multiple style sheets can have conflicting styles. In both conversations I recommended adding ... !important to the five colors to fix any conflicts with the styles of {{sticky header}}, {{sticky table start}}, and any other styles.

I'll take another look at the {{sticky header}} styles to see if there is another solution. Jroberson108 (talk) 13:45, 27 October 2024 (UTC)[reply]

Thanks. One of the reasons noted for removing sticky-headers on PRS was because it broke coloring. I don't think that's the main objection (therefore low-priority if this is the only such case of the breakage) and obviously there may not ever be a fully clean solution when different classes from different features and support scopes are fighting. DMacks (talk) 13:56, 27 October 2024 (UTC)[reply]

@DMacks: I added a test at Template:Sticky header/testcases#Test perennial sources and adjusted the sandbox styles. It looks to be fixed now with no transparency issues on all tests.

@George Ho: I did notice at Template:Sticky header/testcases#Test template row hover highlight (sticky-header-multi) that with the use of .sticky-header-multi, after sorting, any rows with .sorttop don't have the :hover "background-color". It works before sorting. That might be tricky to fix on the {{sticky header}}'s styles where the above mentioned !important fix should be easier for a hover effect that you don't want overridden. Doesn't seem like a big problem though? Jroberson108 (talk) 15:56, 27 October 2024 (UTC)[reply]

As I see, the recent change to fix the hovering issue must have affected the sorting. Let's see how fixing the cause/effect goes. You can revert back to the revision before the changes made if it's too complicated for you to fix. Nonetheless, one problem was fixed, so I wonder how another will be fixed. George Ho (talk) 16:15, 27 October 2024 (UTC)[reply]

@George Ho: I found one selector that wasn't needed and removed it from the sandbox styles, which fixed it. I tested all skins and don't see any issues. Let me know if you see any issues I missed. Jroberson108 (talk) 17:08, 27 October 2024 (UTC)[reply]

Have you tested the sorting of every table in the testcase yet? I see most tables' sorting still not working yet, especially ones using the hover template. George Ho (talk) 17:15, 27 October 2024 (UTC)[reply]

Of course, I was using the desktop view on an iPad to test this out. George Ho (talk) 17:18, 27 October 2024 (UTC)[reply]

@George Ho: Most of the cells have "data" as a value, so that might be what you are seeing. I changed the first columns that have "data" to numbers so you can see sort working. This template doesn't change the sort functionality, so didn't see a need to test if sort actually sorts the values.

I tested all testcases for all skins on my Windows 10 desktop and the default mobile MinervaNeue skin on my Android phone, both in the Chrome browser. For Android, I have to zoom all the way out due to a prior issue described at Template:Sticky header#Known issues. Everything works for me. Jroberson108 (talk) 17:46, 27 October 2024 (UTC)[reply]

Not seeing any more issues, so the styles are live now. Will see if any other issues get reported. Jroberson108 (talk) 20:40, 27 October 2024 (UTC)[reply]

As far as RSP, I recall it was sticky header, but colors worked as of sometime last week. Then yesterday, I noticed color wasn't working. I personally prefer RSP w/o sticky header but will leave that to community decision. Graywalls (talk) 21:12, 27 October 2024 (UTC)[reply]

Sticky header covering jump result

See diff that adds this to "Known issues":

"Jumping to an {{Anchor}} (or similar mechanism for creating an anchor) in a table causes that location of the table to be at the top of the screen, where the sticky header covers it."

@DMacks: Where is this happening currently with {{sticky header}}? And in what browser, OS, device, etc.. --Timeshifter (talk) 17:31, 27 October 2024 (UTC)[reply]

@Timeshifter and DMacks: Template:Sticky header/testcases#Test perennial sources has some anchor/jump links above the table. Note, only "0-9" and "A" work due to the partial copy of the table. I see the issue in all skins except Vector (2022). The links don't show on the MinervaNeue skin (mobile) when the browser width is less than 640 pixels. Jroberson108 (talk) 18:17, 27 October 2024 (UTC)[reply]

Thanks Jroberson108. I compiled related discussion and help links here:

Wikipedia talk:Reliable sources/Perennial sources/styles.css

Related to:

Wikipedia:Reliable sources/Perennial sources#Sources

For testing of the sources table with {{sticky header}} see also this older version of the perennial sources article.

--Timeshifter (talk) 19:19, 27 October 2024 (UTC)[reply]

@DMacks, Graywalls, and Jroberson108: I see that this is the same problem Graywalls is describing here when using shortcuts to specific source names used in Wikipedia:Reliable sources/Perennial sources#Sources (WP:RSPSOURCES). Graywalls gives the shortcut example of WP:ADFONTES. Click it to see where you end up in the current sources table. Click here to see where you end up in the version of sources table with {{sticky header}}:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Reliable_sources/Perennial_sources&oldid=1253585215#Ad_Fontes_Media

I tested it in Vector 2022 and Vector 2010 in Win 11 Pro in Firefox, Chrome, Edge. The shortcut works fine in Vector 2022. In Vector 2010 the result point is covered by the sticky header. Same as clicking on the alphabet links in the horizontal table of contents.

The anchor template variation used in the WP:RSPSOURCES table is this:

{{Wikipedia:Reliable sources/Perennial sources/Shortcut}}
{{Wikipedia:RSPSHORTCUT}}

A specific example:

{{WP:RSPSHORTCUT|WP:ADFONTES}}

In the sources table it produces this:
WP:ADFONTES 📌

Can this problem be fixed for the older skins? And why does it work correctly in Vector 2022? --Timeshifter (talk) 08:45, 29 October 2024 (UTC)[reply]

@Timeshifter: See Template talk:Sticky header/Archive 1#Headings cover the row when you link an anchor in a table. Jroberson108 (talk) 13:48, 29 October 2024 (UTC)[reply]

Thanks for the link. We are currently up to 51 articles using both {{Compact TOC}} and {{sticky header}}.

Would it be possible to create a separate {{Compact TOC}} just for use with {{sticky header}}?

Would that solve the problem?

One solution I see has the anchors removed altogether from the tables. See: Solubility table.

It has {{sticky header}} for each of the constituent tables. The A-Z links from {{compact TOC}} go to the A-Z section headings between the tables.

In Windows 11 Pro on my PC the A-Z links work in the browsers and skins I tested so far: Firefox, Chrome, Edge. In Vector 2022 and Vector 2010. --Timeshifter (talk) 12:11, 30 October 2024 (UTC)[reply]

Template:Flat list and sticky header

Table using {{sticky header}}. I can't figure out why the anchors embedded in this state-by-state table work correctly in Vector 2022 and Vector 2010:

Legality of cannabis by U.S. jurisdiction#By state

It uses {{flatlist}} for its horizontal table of contents.

It is discussed here:

Help:Tables and locations#Horizontal table of contents for a table of states or countries.

--Timeshifter (talk) 12:28, 30 October 2024 (UTC)[reply]

@Timeshifter: This is a continuation of the discussion above and the linked discussion does not add anything new. When I test that table in Vector 2010, I see the same issue mentioned above where jumping to "Alabama" hides the top part of the row's content. In this case, the "Main article: Cannabis in Alabama" line in the "Notes" column is too far up. {{Flatlist}} does not do anything with anchor links. That table has the standard links with "#" above the table with id attributes in the table's rows for them to jump to. Jroberson108 (talk) 13:07, 30 October 2024 (UTC)[reply]

@Jroberson108: OK. I guess in Vector 2017 I didn't really notice it since it only covers one line at the top of the notes. The row header (state name) is not covered at all.

So for the horizontal TOC templates using "id" as the anchor inside the table I don't see a problem with using these TOC templates with tables with only one sticky row of text. As long as the table row headers going down the left column are centered, and are down at least one row due to multiple lines of text in each row.

People can't use 2010 Vector unless they are logged in. So there aren't that many people who are effected. The benefits of having the sticky header outweigh the small inconvenience for a few people of having to scroll up one row to see that missing text. The sticky header helps tremendously with many tables.

--Timeshifter (talk) 14:06, 30 October 2024 (UTC)[reply]

@Timeshifter: The table content is aligned middle vertically and the contents in the "Notes" cell is taller than the other cells in most cases, so that is why its top is covered and not the state name. For "Michigan", three cells are covered with two being partial lines. If the states were top aligned, then they would be covered too. This occurs in all skins except Vector 2022. The taller the sticky rows are (multiple rows and/or wrapping), the more that is covered. For Vector 2022, the top line of the row is partially covered if there are three sticky rows with non-wrapped headers. The reason this works for the most part in Vector 2022 is because they fixed it in commons. They need to do the same for the other skins, which I'm sure someone can request. When logged out, Vector 2022 is used on the desktop version. For mobile, MinervaNeue is used and that table's TOC does show. On my Android, the links jump way below the target unless I zoom all the way out either before or after the jump, most likely related to the Android issue under the "Known issues" section. Jroberson108 (talk) 18:03, 30 October 2024 (UTC)[reply]