Template talk:Sticky header
|
|
This page has archives. Sections older than 90 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present. |
On creating a simple template with both row and column sticky headers
[edit]Jroberson108 and all interested. In various browsers on my iphone SE 2020 I looked at the scrolling tables with sticky headers linked from these 2 table help sections:
- Help:Table/Advanced#Advanced scrolling tables with sticky headers
- Template:2020 monthly cumulative COVID-19 death totals by country - wide table good for testing sticky row headers.
- Help:Table/Advanced#Table with sticky header in simple scroll window
- this version of List of countries by firearm-related death rate has 3 long tables in scroll windows.
They all work well in all mobile browsers tested: Safari, Firefox, Chrome, Edge, Opera.
I linked to Graham87 comments about there being no problems with accessibility with the 2 methods in those 2 help sections.
As you know the location columns with flags do not sort correctly in cell phones whether the sticky tables are in scroll tables or not. You solved that problem by putting the flags in a separate column in the Covid tables. Later note: Location column with flags does not sort correctly in mobile only for tables using {{sticky header}} alone (not combined with the Covid CSS).
I wonder if a class=sticky-row (or similar simple class name) could be added somehow to {{sticky-header}} such that it would only work if the flags were in a separate column? Or if there were no flags. Or maybe the flags could be in the second column. --Timeshifter (talk) 17:48, 6 July 2024 (UTC)
- @Timeshifter: Why would a "sticky-row" class be needed when there are two classes already to make rows top sticky? How is making a row sticky related to sorting a column? As for Template:2020 monthly cumulative COVID-19 death totals by country, I recall moving the non-critical flags to a separate column not because of sorting issues, but to reduce the width of the critical location column that is left sticky. It was to minimize the amount of space the locations took up when left sticky on small devices like mobile in portrait orientation so that more non-sticky data can be viewed when scrolling.
- From the discussion's title, it sounds like you want to make a column left sticky? If so, then you should know that it is only possible if the "sticky-header-scroll" div class wraps the table. If that is there, then something like "sticky-header-col1" and "sticky-header-col2" classes can be created where only one can be added to the table's class attribute. Using both would make them overlap. I've never seen a need for a col3, but col2 is usable in some cases like in the table mentioned above with flag and location columns. It won't work correctly if one of the column's cells spans multiple columns or is spanned by another. Jroberson108 (talk) 19:01, 6 July 2024 (UTC)
- See User:Timeshifter/Sandbox259.
- I removed {{sticky header}} from that article table, and used the Covid CSS instead. This fixed the sorting problem in mobile browsers for the location column with flags.
- I have been involved with this discussion which uses the Covid CSS:
- Wikipedia talk:WikiProject Tennis#1000 title leaders charts
- See the wikitext in the table by Qwerty284651:
- Wikipedia talk:WikiProject Tennis#Qwerty284651's table
- It uses the Covid CSS:
- Template:COVID-19 pandemic data/styles.css
- Here is the relevant wikitext from the Qwerty284651 table:
<nowiki><templatestyles src="COVID-19 pandemic data/styles.css"/></nowiki> <div class="covid19-container" role="region" tabindex="0"> <div class="scroll-container"> {{mw-datatable}}{{sort under}}{{table alignment}} {| class="wikitable sortable mw-datatable defaultcenter col1left sort-under-center sticky-col1" style="margin:0; font-size: 90%" |- class="sticky-row"
- I got confused by the meaning of class="sticky-row". Ignore that mistake. I struck it out in my previous comment.
- I am wondering if it is possible to create something like Template:Sticky header full (or similar simple name) that somehow adds the divs without the editors having to see it, or deal with it. In other words the relevant wikitext would be a lot shorter:
{{mw-datatable}}{{sort under}}{{table alignment}}{{sticky header full}} {| class="wikitable sortable mw-datatable defaultcenter col1left sort-under-center sticky-col1" style="margin:0; font-size: 90%" |- class="sticky-row"
- Another benefit, besides simplicity, would be a full documentation page, if the CSS were part of Template:Sticky header full
- Would it be possible to substitute class=sticky-header and class=sticky-header-multi for class=sticky-row? And to keep those classes with the line of other classes in the top line of the table wikitext?
- That way people could easily convert from {{sticky header}} to {{sticky header full}}. Just by adding "full" and adding sticky-col1 or sticky-col2 to the long line of classes.
- Better yet, if all of this could be incorporated into {{sticky header}}. Then the only change people would need to make to get sticky row headers is to add sticky-col1 or sticky-col2 to the long line of classes.
- I am wondering why {{sticky header}} is necessary in the full sticky table at the link below, but is not in the above wikitext.
- Iga Świątek career statistics#Wins against top 10 players
- Its relevant wikitext:
<nowiki><templatestyles src="COVID-19 pandemic data/styles.css"/></nowiki> <div class="covid19-container" role="region" tabindex="0"> <div class="sticky-header-scroll" style="max-height:50vh"> {{mw-datatable}}{{sticky header}}{{sort under}} {| class="wikitable mw-datatable plainrowheaders sortable sort-under-center sticky-header sticky-col2" style="margin:0" |-class="sticky-row"
- I tried removing {{sticky header}} in preview, but it broke the table.
- --Timeshifter (talk) 01:57, 7 July 2024 (UTC)
- @Timeshifter: I do see an issue with sorting on mobile, but it doesn't look like it has anything to do with sticky headers. I tested the below two links in Chrome and Firefox on Windows 10 and the mobile version sorts Palestine at the top even when I remove all the classes except wikitable and sortable in the edit preview.
- The issue appears to be {{flagg}} on the mobile version since sorting works on the desktop version. Jroberson108 (talk) 06:38, 7 July 2024 (UTC)
- As far as adding divs through a template, an editor would have to add two templates, one for the opening div before the table and one for the closing div after the table. Something like
{{sticky header start}}
and{{sticky header end}}
could be created. Editors would still need to add the specific classes to the table. It doesn't seem simpler, especially if someone wants to style the opening div with less height like withstyle="max-height:50vh"
, which now would require passing it through the template properties. Jroberson108 (talk) 07:36, 7 July 2024 (UTC)- I need to test some more flag templates with {{sticky header}}.
- I forgot to point you to this:
- User:Timeshifter/Sandbox259#Partially-sticky table. Not in scroll window
- I don't know if you saw it. It also uses the Covid CSS. It seems that removing this line of wikitext also removes the top sticky headers from desktop PC browsers:
- <div class="scroll-container">
- The sticky row headers still work in both desktop and mobile. But the top sticky headers only work in mobile browsers.
- See again: Wikipedia talk:WikiProject Tennis#Timeshifter's table - Uses the Covid CSS.
- I summarized my test results: The table there (when nowrap is ignored or removed) is working perfectly on my desktop PC monitor in Windows 10 Pro. Also on my iphone SE 2020 (in portrait and landscape view). It has been tested in Safari, Firefox, Chrome, Edge, and Opera. The row and column headers are both sticky.
- Does it work perfectly for you too in an Android phone?
{{sticky header start}}
and{{sticky header end}}
sound good to me. I want to start using it right away since it works perfectly.style="max-height:50vh"
is rarely necessary. I would like all the class names in the first row of table wikitext if possible. But I will take what I can get.- I think the default should be row and column sticky headers. But not within a scroll window. That would require a "scroll" class. So someone could set up a fully-sticky table in a scroll window with just this:
{{sticky header start}} {| class="wikitable sortable sticky-header scroll" |- ... |} {{sticky header end}}
- It would be very easy to convert from {{sticky header}} to it, and thereby add sticky row headers and a scroll window.
- I can't see why sticky row headers shouldn't be default.
- Is is possible to make sticky row headers the default in {{sticky header}}? No scroll window. In other words no changes would have to be made on the 2000+ existing transclusions (using classes sticky-header and sticky-header-multi).
{{sticky header}} {| class="wikitable sortable sticky-header" |- ... |}
- --Timeshifter (talk) 11:17, 7 July 2024 (UTC)
@Timeshifter: I'm not sure why issues with the Template:COVID-19 pandemic data/styles.css template are being discussed here. It's a competing template that has not been thoroughly tested and should not be used in conjunction with this template on the same table. It was made a long time ago for the covid tables and only recently has it been applied to the sports tables. The only reason I can think of that it was used outside of its original scope was because they wanted horizontal scroll and an optional left-sticky column that this template didn't offer. The horizontal scroll is now available with the div wrapper. As indicated above, left-sticky can be added to this template, but like the covid styles, a div wrapper is required for it to work. As I indicated at Template_talk:COVID-19_pandemic_data/styles.css#Why_is_Firefox_table_slightly_cut_off_horizontally?, this template has been thoroughly tested whereas the covid one has not, so the covid one will have issues in other skins, etc.
The original intent of this template was to provide the most common usage, which is for top-sticky row(s). Adding the div wrapper to this template and now wanting left-sticky columns is complicating this template and the documentation, as you are obviously trying to sort out in this discussion.
Options for the new left-sticky feature would look something like this.
OPTION 1:
Add left-sticky to this template, which further complicates documentation.
Row 1 top-sticky, no left-sticky:
{{sticky header}}
{| class="wikitable sortable sticky-header"
|}
or
{{sticky header}}
<div class="sticky-header-scroll">
{| class="wikitable sortable sticky-header"
|}
</div>
Row 1 top-sticky, column 2 left-sticky:
{{sticky header}}
<div class="sticky-header-scroll">
{| class="wikitable sortable sticky-header sticky-header-col2"
|}
</div>
No top-sticky, column 2 left-sticky:
{{sticky header}}
<div class="sticky-header-scroll">
{| class="wikitable sortable sticky-header-col2"
|}
</div>
OPTION 2:
Create start/end templates, add left-sticky to the start template, move the div wrapper to the start template, include this template in the start template so editors don't have to if they want the optional top-sticky row(s). This template returns to a simpler version and moves the complexities to the start template. This is unadvisable since it greatly complicates the styles, testing, and documentation. Technically start/end aren't good names since left-sticky is a new feature not found in this template. The start/end templates I have examined don't add new features.
Row 1 top-sticky, no left-sticky:
{{sticky header}}
{| class="wikitable sortable sticky-header"
|}
or
{{sticky header start}}
{| class="wikitable sortable sticky-header"
|}
{{sticky header end}}
Row 1 top-sticky, column 2 left-sticky:
{{sticky header start}}
{| class="wikitable sortable sticky-header sticky-header-col2"
|}
{{sticky header end}}
No top-sticky, column 2 left-sticky:
{{sticky header start}}
{| class="wikitable sortable sticky-header-col2"
|}
{{sticky header end}}
OPTION 3:
Create new start/end templates and add everything there so sticky tables are always wrapped in a div providing horizontal scrolling when the tables are wide. Always having the div would fix the Android issues with wide table scrolling mentioned at Template:Sticky header#Known issues. This template could be deleted once transclusions are replaced since it duplicates some of the start/end features. If this template is kept, then this template's div wrapper can be removed to simplify it and this template will be a separate competing template to the start/end templates, which it might be prudent to have a more descriptive name like maybe "sticky header box start" and "... end", but this template's Android issues will remain. The start/end templates are what I originally planned so the horizontal scroll and left-sticky column features were possible just like the covid styles, but this template was created so I didn't bother.
Row 1 top-sticky, no left-sticky:
{{sticky header start}}
{| class="wikitable sortable sticky-header"
|}
{{sticky header end}}
Row 1 top-sticky, column 2 left-sticky:
{{sticky header start}}
{| class="wikitable sortable sticky-header sticky-header-col2"
|}
{{sticky header end}}
No top-sticky, column 2 left-sticky:
{{sticky header start}}
{| class="wikitable sortable sticky-header-col2"
|}
{{sticky header end}}
Jroberson108 (talk) 15:56, 7 July 2024 (UTC)
- Having seen how wonderfully the Covid CSS works with all browsers on my iphone SE 2020 portrait and landscape views, I want the same for Android phones too. So I guess that means option 3. As long as there is a scroll window option with it.
- Can that be done with a class alone? For example: class=scroll.
- I always prefer the simplest names: "sticky header start" versus "sticky header box start". And sticky-col2 versus sticky-header-col2.
- I no longer care what happens with {{sticky header}}. It will disappear over time, especially if these new start/end templates work as well with Android phones as they will do with iphones. That is if they duplicate the capability of the Covid CSS.
- --Timeshifter (talk) 18:53, 7 July 2024 (UTC)
- @Timeshifter: If option 3 and removing
{{Sticky header}}
, then{{Sticky header start}}
and{{Sticky header end}}
makes sense. - Wikipedia:TemplateStyles gives guidelines to name the classes based on the template name, so "sticky-header-col1" and "sticky-header-col2" better follow that.
"Use selectors that are highly likely to be unique to the template being used. This reduces the chance of conflicting CSS rules arising accidentally. Examples: Use .myTemplate-row rather than .row or .myTemplate tr rather than tr."
- There wouldn't be a need for editors to add a scroll class. Transcluding the start template would add the template's styles and the opening div tag with its class. An optional parameter would be added to the start template so editors can add/override the div styling like with "max-height:50vh". Example property use:
{{Sticky header start|style=max-height:50vh}}
. Jroberson108 (talk) 21:13, 7 July 2024 (UTC)- So the scroll window would be the default? If so, then there would be a need for a class=noscroll in some cases. Not all sticky tables need to be in a scroll window. I guess small tables would automatically not have a scroll window since they wouldn't extend past the screen. And some tables slightly taller than the screen may not really need a scroll window, and so some article editors may not want them in a scroll window.
- I think the spirit of the Wikipedia:TemplateStyles guidelines is met by "sticky-col1" and "sticky-col2". Or col1sticky and col2sticky. I don't know of any other sticky templates, etc. that use those class names. Kind of like col1left and col2right are adequately distinct for {{table alignment}}.
{{Sticky header start|style=max-height:50vh}}
is fine. I don't think it will be used very often.- --Timeshifter (talk) 22:48, 7 July 2024 (UTC)
- @Timeshifter: The scroll shows when needed, which is more useful for mobile.
- In case you aren't aware, there are other sticky styles besides this one:
- {{Import style}} used to import Template:Import_style/sticky.css
- Template:COVID-19 pandemic data/styles.css
- MediaWiki:Gadget-StickyTableHeaders.css
- {{Sticky}} (draft?)
- I recall there was a "mw-sticky" class too unless they removed it.
- I wouldn't assume "col1left" followed or was aware of the guidelines at the time, the same way I wasn't when I first created the covid styles. If you weren't aware, "sticky-col1" and "sticky-col2" are used on the covid styles. You want "highly likely to be unique to the template being used", which templateName-style accomplishes. This template's classes already follow guidelines by being named "sticky-header-...", so I don't see a need to deviate from it:
- sticky-header
- sticky-header-multi
- sticky-header-scroll
- sticky-header-col1
- sticky-header-col2
- Also, my preference would be to change the "sticky-header" class to "sticky-header-row" so it describes it better. Another thought is that the template could be better described if named "Sticky table" instead of "Sticky header". Jroberson108 (talk) 23:08, 7 July 2024 (UTC)
- @Timeshifter: If option 3 and removing
When I do google searches "sticky header" is used when the discussion is ongoing. "Sticky table header" is used to introduce the topic. Same for "Sticky table". Since this template goes above a table there is no need to put "table" in the template name.
I dislike longer class names, but there is something to be said about the simplicity of class names that all start with "sticky-header". And I did not realize the number of sticky templates (not just for tables) on and off English Wikipedia.
sticky-header-row sounds good in order to clearly distinguish it from sticky-header-col1 and sticky-header-col2.
So are we going with scroll on or off by default? I think it should be off by default so that article editors can decide for themselves. I have already been thanked for an article with 3 long tables that I converted to scroll windows (via {{sticky header}}) a few days ago. So I think this template will be very popular with editors, but I don't think we should force the scroll window on them at first. They will applaud it after having to scroll through long tables at first. --Timeshifter (talk) 11:20, 8 July 2024 (UTC)
- More accurately, this template styles various parts of a table, the table, and the table's wrapper div. Generally the CSS is included above or better in thead. The "style" import template styles table parts only, if I recall, or headers (h1-h6) aka page sections, and can probably be added to anything else too like images or a paragraph notice. The point is that table's aren't the only element considered to have headers. I'm fine with "sticky-header" or "sticky-table". My preference is the latter.
- The scroll is automatic. The browser adds scrollbars only when necessary. Nothing for the editors to worry about. That's how the covid styles and this template's sticky-header-scroll class work too. Jroberson108 (talk) 13:52, 8 July 2024 (UTC)
Let the other sticky headers distinguish themselves with template names like "Sticky image" or "sticky header image" or whatever. We keep "Sticky header start" for our template name. People are more familiar with the name "sticky header" versus "sticky table" on Wikipedia. Plus it makes it easier and more intuitive to convert the {{sticky header}} tables to the new scroll window tables.
OK, I understand that the scrollbars are automatically off or on depending on how the table fits in the screen.
My question was/is whether the scroll window has to be added via the sticky-header-scroll class being added to the new template. That is what I want. And I assume that is the case, since the class is in your list:
- sticky-header-row
- sticky-header-multi
- sticky-header-scroll
- sticky-header-col1
- sticky-header-col2
I just wanted to make sure the scroll window wasn't added without the sticky-header-scroll class being added to the new template.
I suggest having class=sticky-header and class=sticky-header-row do the same thing. That would make it even easier to convert {{sticky header}} to the new template. Most of the {{sticky header}} tables use class=sticky-header. And sticky-header-multi is the same on both templates. So this basic change would be easy and intuitive:
{{sticky header}}
{| class="wikitable sortable sticky-header"
to
{{sticky header start}}
{| class="wikitable sortable sticky-header sticky-header-col1"
...
{{sticky header end}}
Or would that cause problems with having the same class name in 2 different templates on the same page? Which is possible if one only converts one table to the new template, and leaves other tables with the old template for later conversion (if ever). I have a feeling it would be a problem. Unless the start/end aspects of the new template prevent it from seeing those duplicate class names elsewhere. --Timeshifter (talk) 15:13, 8 July 2024 (UTC)
- Maybe "sticky-header-multi" should be changed too since it doesn't indicate row or column.
- The CSS include and
<div class="sticky-header-scroll">
are added via{{Sticky header start}}
. Nothing for the editors to decide. - Having duplicate classes complicates the CSS, testing, and documentation. You can see how much is there already, which doesn't include col1 and col2. This is a new template that is used differently, so familiarity isn't an issue and we can pick the best template and class names for long term use that describes things better. I think "sticky-table-col1", etc. makes more sense. Tables have columns, which may be header cells (th) or data cells (td). Headers are generally known as page sections (h1-h6). Again, either can work. This just makes more sense to me.
- In time, all uses of
{{Sticky header}}
will be converted before deletion. If the classes change, then it isn't a big change. From our prior discussions on TfD, we don't need to worry about converting since they handle it and have tools to help. Jroberson108 (talk) 15:53, 8 July 2024 (UTC)- If I search all the Village Pump archives I get 12 sections with "sticky table" and 28 with "sticky header". Page sections (h1-h6) are known as headings. At least according to this Google search:
- https://www.google.com/search?q=page+sections+%28h1-h6%29.
- We used class=sort-under and class=sort-under-right to mean the same thing for use with {{sort under}}. And my understanding from that discussion was that it was not technically difficult to set up.
- I disagree with all tables using this new template to have a possible scroll window without manually adding a class: "Nothing for the editors to decide."
- If you are saying that it is technically difficult to provide a choice, then I understand. In that case we can go ahead with this new template, and maybe create another template for fully-sticky headers (row and column) without scroll windows.
- I think we need more input on all of the above. More input has helped in the past with the various templates. --Timeshifter (talk) 17:07, 8 July 2024 (UTC)
- Technically h1-h6 are called headings, but can sometimes be referred to as headers as I did. If you want to be precise,
<th>
are called header cells, not headers. There is also a<header>
tag. - "I disagree with all tables using this new template to have a possible scroll window without manually adding a class ..." Sounds like what is already in this template, so no changes needed then. It hasn't been a problem on the covid styles. Anyways, feel free to discuss with others. Jroberson108 (talk) 17:44, 8 July 2024 (UTC)
- Technically h1-h6 are called headings, but can sometimes be referred to as headers as I did. If you want to be precise,
{{sticky header}} is used on the table in List of countries by intentional homicide rate. But there is no short scroll window of the type we are talking about in the Covid CSS tables unless one manually adds the class for it. And even with the Covid CSS tables it is possible to remove the short scroll window by removing the scroll div:
- <div class="scroll-container">
See this short scroll-window table:
For example, I removed it from the above-linked table.
<nowiki><templatestyles src="COVID-19 pandemic data/styles.css"/></nowiki>
<div class="covid19-container" role="region" tabindex="0">
{{mw-datatable}}{{sort under}}{{table alignment}}
{| class="wikitable sortable mw-datatable defaultcenter col1left sort-under-center sticky-col1" style="margin:0; font-size: 90%"
<templatestyles src="COVID-19 pandemic data/styles.css"/>
So are you saying that with the new template, the short scroll window will be implemented by adding a class manually?
I just noticed that the above table is not top sticky until a horizontal scroll bar shows up when I narrow the table enough.
So I guess the new template will only work correctly when there is no choice given about the short scroll window. The short scroll window will have to be built-in. --Timeshifter (talk) 18:25, 8 July 2024 (UTC)
Template:Sticky table start and Template:Sticky table end
[edit]- OK. After sleeping on it, I can live with
{{sticky table}}
. Since this template has a short scroll window, and {{sticky header}} does not, we need a template name that makes it clear that this template is different in a major way. It may be slightly more time-consuming to convert from one to another though. - Possible classes:
- sticky-table-row
- sticky-table-rows or sticky-table-multi or sticky-table-multi-rows
- sticky-table-scroll - Built-in. Not added manually.
- sticky-table-col1
- sticky-table-col2
- Please clarify this for me. Editors won't see sticky-table-scroll in the table wikitext? And there will be no option (for now) to not use the short scroll window? There will no longer be long tables outside a short scroll window?
- --Timeshifter (talk) 10:20, 9 July 2024 (UTC)
- "sticky-table-scroll" will be in the div above the table, which is transcluded by the
{{sticky table start}}
. The transclusion code is all they see. - If this template is being kept, then naming the new templates like this will follow guidelines on ensuring the class names are unique.
- "sticky-table-row" and "sticky-table-rows" could work. The former could also be "sticky-table-row1" like col1 and col2. Be nice if some other editors joined the discussion. Jroberson108 (talk) 15:58, 9 July 2024 (UTC)
- So editors only see
{{sticky table start}}
which is what you mean by "transclusion code" I assume. That is a new phrase for me. I just called them template names. - sticky-table-row1 could work.
- For more than one row of column headers:
- sticky-table-rows. Since column headers can have more than 2 rows.
- Pinging: TheDJ. Qwerty284651.
- --Timeshifter (talk) 19:43, 9 July 2024 (UTC)
- "sticky-table-rows" would only work on the thead element, which is how multi works on this template. Sortable and the sticky gadget are the only two that move rows into the thead. Jroberson108 (talk) 19:59, 9 July 2024 (UTC)
- So editors only see
- "sticky-table-scroll" will be in the div above the table, which is transcluded by the
I didn't understand any of that. :)
Does the Covid CSS work with multi-row headers? If so, are there any sticky multi-header-row table examples you can link to that use the Covid CSS? I want to look at the wikitext. I haven't looked at the HTML yet. --Timeshifter (talk) 22:41, 9 July 2024 (UTC)
- The covid css does not. Jroberson108 (talk) 23:00, 9 July 2024 (UTC)
- So currently there is a need for both templates. The differences between the 2 templates:
- {{sticky header}} - for single and multi-row sticky top headers. No sticky side headers. Option for short scroll window [Later note: Soon to be gone].
{{sticky table start}}
-single-row-onlysticky top headers. Also, sticky side headers. Short scroll window (no option for long tables without a scroll window).
- So I will work on putting tables with both single and multi-row sticky top headers in short scroll windows. As I did here:
- https://en.wikipedia.org/w/index.php?title=List_of_countries_by_firearm-related_death_rate&oldid=1232974888
- I think this will help people become more familiar with the short scroll windows.
I will concentrate on multi-row sticky top headers. - --Timeshifter (talk) 18:22, 11 July 2024 (UTC)
- The div "sticky-header-scroll" class (scroll window) would be removed from this template as that is the main difference. A left-sticky column isn't possible without it. Also note that always having the scroll window on the new template fixes Android issues mentioned at Template:Sticky header#Known issues. It also means that there is less table to swipe/scroll past if trying to skip it as you browse since it has it's own vertical scroll. I question the need of
{{sticky header}}
if the other template is available. Correction to your above bulleted list:{{sticky table start}}
would allow for top-sticky multi rows too. Jroberson108 (talk) 20:11, 11 July 2024 (UTC)
- The div "sticky-header-scroll" class (scroll window) would be removed from this template as that is the main difference. A left-sticky column isn't possible without it. Also note that always having the scroll window on the new template fixes Android issues mentioned at Template:Sticky header#Known issues. It also means that there is less table to swipe/scroll past if trying to skip it as you browse since it has it's own vertical scroll. I question the need of
- So currently there is a need for both templates. The differences between the 2 templates:
That's good news! When can we have the new template? I am itching to start using it. Since it does everything I want. I struck out the incorrect info in my last post. In reply to a recent question of mine you said "The covid css does not" [work with multi-row headers]. Have you decided to add that capability to the new template? --Timeshifter (talk) 22:01, 11 July 2024 (UTC)
- Multi is on this template, so I don't see why I wouldn't port it over. The original plan was to replace this one with added features. Jroberson108 (talk) 22:09, 11 July 2024 (UTC)
- OK, so I see the reason for my confusion. We have been talking about 3 "templates". The covid css, {{sticky header}}, and the new proposed template,
{{sticky table start}}
. I thought you were basically only changing formats from the covid css to{{sticky table start}}
, and that everything had already been incorporated in the covid CSS. --Timeshifter (talk) 22:31, 11 July 2024 (UTC)
- OK, so I see the reason for my confusion. We have been talking about 3 "templates". The covid css, {{sticky header}}, and the new proposed template,
See Global Search at Toolforge. Search for "sticky-header-scroll" - in quotes (used in {{sticky header}}). To get a list of pages worldwide containing it. Currently, I get 51 results when searching everything. Search takes time.
When I search for "scroll-container" (used in covid css) I currently get 91 results when searching everything. That search took 2 and a half minutes.
I appreciate whoever added the {{nowrap}} around the first search phrase. I put it around the second phrase. It must have been an admin, because I see nothing in the page history. Editing other people's posts in talk pages is usually a violation of WP:TALK. Even stealth edits. So please stop. I suspect a certain new admin. But who knows. Don't risk losing your admin rights. We need admins. As long as they follow the rules. No need to apologize. Just stop. --Timeshifter (talk) 17:24, 17 July 2024 (UTC)
- I am guessing that this is directed at me, but I can promise you that was not my doing. It looks like you added it yourself around the first one. To perform a stealth edit, you would have to 1) make the edit, 2) make another unrelated edit (or wait for someone else to make one), 3) delete the page, 4) selectively undelete all revisions except for the stealthy edit. I don't ever plan to do that, nor do I know of any other admins that do so. And carrying out those steps would itself be a much more serious violation than formatting changes to someone else's message. In any event, you can see this page has never been deleted. HouseBlaster (talk · he/they) 18:26, 24 July 2024 (UTC)
- Did you by chance copy/paste from the VisualEditor when you were making that edit? HouseBlaster (talk · he/they) 18:27, 24 July 2024 (UTC)
- HouseBlaster. I don't think so. I have no idea how nowrap was added. I don't remember doing it. But then this wouldn't be the first time something vanished from my memory. Alien memory wipe? :)
- Wikipedia:Administrators' guide/Deleting#Deleting a revision talks about "whether to revision-delete the content, the edit summary, the username or all three." That sounds like a way. I am an admin bureaucrat on a couple wikis elsewhere. So this stuff interests me a little.
- So maybe it was some nefarious admin activity, or not. As the saying goes approximately: "Just because you're paranoid, doesn't mean they aren't after you". :)
- But let's not waste more time on it. Now that you are here Jroberson108 and I would like your opinion on the ideas in this thread. --Timeshifter (talk) 04:48, 25 July 2024 (UTC)
- Happy to give my thoughts later today :) HouseBlaster (talk · he/they) 12:45, 25 July 2024 (UTC)
- Did you by chance copy/paste from the VisualEditor when you were making that edit? HouseBlaster (talk · he/they) 18:27, 24 July 2024 (UTC)
Discussion
[edit]HouseBlaster. Here is a noncovid table with both top and left sticky headers. And the relevant wikitext at the top. Divs are closed at the bottom. Table is the top table from this version of List of U.S. states and territories by incarceration and correctional supervision rate. It works perfectly for me on desktop and on my iphone SE 2020.
<nowiki><templatestyles src="COVID-19 pandemic data/styles.css"/></nowiki>
<div class=covid19-container>
<div class=scroll-container>
{{static row numbers}}{{mw-datatable}}{{sort under}}{{table alignment}}
{| class="wikitable sortable static-row-numbers mw-datatable sort-under defaultright col1left sticky-col1" style="margin:0"
|+ Incarceration rates per 100,000. Counts. Latest data available as of June 2024.
|- class=sticky-row
<templatestyles src="COVID-19 pandemic data/styles.css"/>
Location | Incarceration rate | Total incarcerated | State population | State prisons | Federal | Local jails |
---|---|---|---|---|---|---|
![]() |
898 | 45,573 | 5,073,903 | 26,421 | 3,607 | 14,727 |
![]() |
744 | 5,456 | 733,276 | 4,778 | 498 | 12 |
![]() |
606 | 301 | 49,710 | 301 | N/A | N/A |
![]() |
710 | 52,329 | 7,365,684 | 33,865 | 3,567 | 13,541 |
![]() |
912 | 27,795 | 3,046,404 | 17,625 | 2,522 | 7,165 |
![]() |
494 | 192,694 | 39,040,616 | 97,608 | 12,172 | 75,061 |
![]() |
556 | 32,495 | 5,841,039 | 17,168 | 1,811 | 12,719 |
![]() |
326 | 11,747 | 3,608,706 | 10,506 | 949 | N/A |
![]() |
539 | 5,492 | 1,019,459 | 4,954 | 361 | N/A |
![]() |
816 | 5,473 | 670,949 | N/A | 3,445 | 1,817 |
![]() |
705 | 156,734 | 22,245,521 | 84,678 | 13,370 | 55,826 |
![]() |
881 | 96,171 | 10,913,150 | 48,439 | 6,897 | 40,085 |
![]() |
502 | 772 | 153,836 | 678 | 94 | N/A |
![]() |
367 | 5,283 | 1,439,399 | 4,149 | 834 | N/A |
![]() |
720 | 13,965 | 1,938,996 | 9,110 | 950 | 3,508 |
![]() |
433 | 54,474 | 12,582,515 | 29,634 | 6,386 | 16,493 |
![]() |
721 | 49,241 | 6,832,274 | 25,286 | 3,436 | 19,416 |
![]() |
550 | 17,598 | 3,199,693 | 8,473 | 3,744 | 4,950 |
![]() |
648 | 19,022 | 2,936,716 | 8,709 | 1,537 | 8,065 |
![]() |
889 | 40,107 | 4,511,563 | 19,744 | 3,182 | 16,844 |
![]() |
1,067 | 48,973 | 4,588,023 | 27,296 | 2,538 | 18,183 |
![]() |
272 | 3,777 | 1,389,338 | 1,675 | 452 | 1,623 |
![]() |
475 | 29,304 | 6,163,981 | 15,637 | 4,068 | 8,455 |
![]() |
241 | 16,798 | 6,982,740 | 6,001 | 1,279 | 9,129 |
![]() |
535 | 53,683 | 10,033,281 | 32,374 | 4,477 | 15,875 |
![]() |
323 | 18,457 | 5,714,300 | 8,636 | 2,003 | 6,343 |
![]() |
1,020 | 29,980 | 2,938,928 | 19,802 | 2,041 | 7,829 |
![]() |
713 | 44,016 | 6,177,168 | 23,911 | 6,747 | 11,576 |
![]() |
758 | 8,508 | 1,122,878 | 4,691 | 1,214 | 2,206 |
![]() |
591 | 11,635 | 1,968,060 | 5,649 | 1,390 | 4,119 |
![]() |
610 | 19,370 | 3,177,421 | 10,304 | 1,311 | 7,211 |
![]() |
278 | 3,886 | 1,399,003 | 2,086 | 426 | 1,332 |
![]() |
270 | 25,016 | 9,260,817 | 12,657 | 2,337 | 8,775 |
![]() |
647 | 13,676 | 2,113,476 | 4,970 | 1,746 | 6,549 |
![]() |
317 | 62,339 | 19,673,200 | 31,148 | 8,859 | 20,448 |
![]() |
559 | 59,753 | 10,695,965 | 29,627 | 9,164 | 20,360 |
![]() |
560 | 4,363 | 778,912 | 1,817 | 901 | 1,434 |
![]() |
400 | 189 | 47,329 | 170 | 19 | N/A |
![]() |
621 | 72,989 | 11,759,697 | 45,313 | 4,728 | 20,582 |
![]() |
905 | 36,388 | 4,019,271 | 22,941 | 2,350 | 10,625 |
![]() |
494 | 20,942 | 4,239,379 | 12,518 | 1,182 | 5,991 |
![]() |
589 | 76,355 | 12,972,091 | 37,910 | 5,726 | 31,303 |
![]() |
341 | 10,995 | 3,220,113 | 7,067 | 3,928 | N/A |
![]() |
254 | 2,779 | 1,093,842 | 2,393 | 260 | N/A |
![]() |
606 | 32,038 | 5,282,955 | 16,318 | 3,712 | 11,177 |
![]() |
812 | 7,386 | 909,869 | 3,444 | 1,327 | 2,003 |
![]() |
817 | 57,625 | 7,048,976 | 23,735 | 7,044 | 26,463 |
![]() |
751 | 225,480 | 30,029,848 | 139,631 | 23,244 | 58,489 |
![]() |
651 | 567 | 87,146 | 417 | 150 | N/A |
![]() |
396 | 13,381 | 3,381,236 | 6,009 | 1,313 | 5,765 |
![]() |
245 | 1,583 | 647,110 | 1,360 | 219 | N/A |
![]() |
679 | 58,917 | 8,679,099 | 27,162 | 4,722 | 25,229 |
![]() |
373 | 29,065 | 7,784,477 | 13,772 | 2,438 | 11,567 |
![]() |
674 | 11,954 | 1,774,035 | 5,873 | 1,289 | 4,372 |
![]() |
615 | 36,199 | 5,890,543 | 20,873 | 1,615 | 12,741 |
![]() |
785 | 4,568 | 581,629 | 2,154 | 615 | 1,558 |
U.S. total | 608 | 2,048,524 | 336,829,545 | 1,079,467 | 219,140 | 649,181 |
How does this look in everybody's phones?
I tried the covid css with this multi-row header:
Only the top row was sticky at the top. Side sticky worked fine. I believe Jroberson108 said multi-row top-sticky could be incorporated into the new template from {{sticky header}}. --Timeshifter (talk) 02:53, 26 July 2024 (UTC)--Timeshifter (talk) 02:53, 26 July 2024 (UTC)
- Four notes:
- I didn't get your ping. Pinging is very finicky; see WP:PINGFIX for more. But the fool-proof way to ping is to use the edit summary (see Help:Notifications#Mentions in edit summaries for more). I have pinged you in this edit's summary.
- It looks fine on my phone (still rocking the iPhone X) – both side and top sticky worked.
- I wish that the table caption wrapped over multiple lines so I don't have to horizontally-scroll to see the entire thing. If I am skimming an article, I would want to see the entirety of the table caption without horizontal scrolling so I know whether the table has the information I am looking for (and therefore whether I should scroll past it or investigate further).
- Not really a display issue, and I doubt there is anything that can be done to fix this, but it is hard to scroll past the table once I am finished reading it. I try to scroll down further on the page, but it thinks I am trying to scroll down further on the table (even though I am already at the bottom of the table).
- Best, HouseBlaster (talk · he/they) 03:53, 26 July 2024 (UTC)
- I will try the edit summary ping.
- About the table caption, I assume you mean for it wrap within the screen width, and not the table width.
- I notice that trying to get past the table (up or down) can be weird. I think I went near the screen edge to pull the page up or down.
- Do you know how to create templates like this? Maybe you can help Jroberson108. --Timeshifter (talk) 04:20, 26 July 2024 (UTC)
I got your edit summary ping :)
You are correct, I mean wrapping the screen width.
I have no clue how to create templates like this, though I might be able to figure it out (most of software development is googling things). I will let Jroberson108 try first, however. HouseBlaster (talk · he/they) 04:23, 26 July 2024 (UTC)- @HouseBlaster: Thanks for your notes.
- Auto wrapping the caption to the scroll area's width would be nice. I'll have to play around with it to see if it's possible. The table is in it's own scrollable element, so it may not be possible.
- As for scrolling past the scroll area, the height of it is 75vh (75% of screen height), so there should be 25% left above/below the scroll area that can be used to page-scroll past the table on mobile or with mouse scroll wheel. The height can be reduced if needed. If this is a usability problem that can't be fixed, then we may not want to do this template, which means no left-sticky and continued Android issues. Jroberson108 (talk) 13:05, 26 July 2024 (UTC)
Thinking out loud, perhaps there is a way to make the scrolling functionality conditional on the text not being a part of a caption?
Regarding the scrolling, I think it is a minor complaint; I am still able to scroll past the table. It is just not as easy as I would like it to be, but it is in the "annoyance which is worth the added functionality" category rather than the "literally unusable that is a UBN-level issue" category. HouseBlaster (talk · he/they) 02:12, 27 July 2024 (UTC)- @HouseBlaster: The following CSS would auto wrap the caption, at least in Windows Chrome:
max-inline-size: 90vw; overflow-wrap: break-word;
. Unfortunately, the styles page says that "max-inline-size" is an "unrecognized or unsupported property". I've had other issues with the styles page not supporting newer properties. Jroberson108 (talk) 17:34, 27 July 2024 (UTC) - Switching the property with "max-width" seems to work though. It will need testing. Jroberson108 (talk) 17:44, 27 July 2024 (UTC)
- It doesn't work properly if there are left/right sidebars. Need to instead use the width of the main content area, not the table. Dropping it for now. Jroberson108 (talk) 17:51, 27 July 2024 (UTC)
- @HouseBlaster: The following CSS would auto wrap the caption, at least in Windows Chrome:
I don't find it difficult to get past the scroll window in my iphone now that I am more familiar with it.
I put the above table here (with a longer caption):
I tried different width, max-width settings, etc.. But I couldn't figure out how to make them adjust to the scroll window width, and not the table width. Your method is almost there.
Putting the caption directly above the table (outside the table) would work, I believe. But I don't think the table would be accessible then to screen readers. Could maybe do both. But then there would be duplicate "captions". Unless the in-table caption could be made with an invisible, transparent font only seen by screen readers. --Timeshifter (talk) 18:28, 27 July 2024 (UTC)
- We can use {{screen reader-only}} (shortcut {{sronly}}) to make something visible only to screen readers. HouseBlaster (talk · he/they) 20:42, 27 July 2024 (UTC)
- The template can only style content, not move it around. If JavaScript were possible, then maybe. Jroberson108 (talk) 21:39, 27 July 2024 (UTC)
- @HouseBlaster and Timeshifter: See {{sticky table start}}. Jroberson108 (talk) 02:13, 28 July 2024 (UTC)
Thanks HouseBlaster. I added {{Screen reader-only}} to Help:Table#Templates.--Timeshifter (talk) 10:20, 28 July 2024 (UTC)
Tests of new template
[edit]I started this whole new section so it is easier to find on a cell phone via the table of contents.
Moved to Template talk:Sticky table start. --Timeshifter (talk) 06:30, 29 July 2024 (UTC)
Problem when PC browser window narrowed
[edit]I noticed something strange on this page:
In Firefox on Win 10 Pro PC when I narrow my browser window I reach a point where the tables expand weirdly to the right, and the sticky headers stop working.
Same on Chrome, Edge, and Opera on my Win 10 Pro PC.
I noticed that the table pairs on that page also lost their sticky headers. But without the weird table expansion to the right. Instead their caption backgrounds turned gray at a certain narrower browser width on my PC. At that point the sticky headers stopped working. Try it and see what I mean. I tested this only in Firefox so far.
No problems with that page on my iphone SE 2020 in Safari or Chrome. In both portrait and landscape view. --Timeshifter (talk) 10:22, 30 July 2024 (UTC)
- I'm not able to reproduce the issue. Sounds like you are minimizing it after loading, so the browser is redrawing things. Jroberson108 (talk) 11:10, 30 July 2024 (UTC)
- Try narrowing your PC browser width as far as you can. Until it will not narrow any further. Drag the right side of the window to the left as far as possible. When I do that none of the tables have working sticky headers, including the scroll windows.
- I just retested in Firefox, Chrome, Edge, and Opera on my Win 10 Pro PC. In Vector 2022. Also, in Firefox in Vector 2010.
- Same problem in all. --Timeshifter (talk) 11:30, 30 July 2024 (UTC)
- I see it at width 639px or less. It's due to some changes they made to Wikipedia's CSS across multiple skins. Don't know when they made those changes. Should be fixed now. Jroberson108 (talk) 18:13, 30 July 2024 (UTC)
Thanks. It is fixed. I checked in Chrome and Firefox on my Win 10 Pro PC. --Timeshifter (talk) 23:08, 30 July 2024 (UTC)
Urgent: Please fix this template for printed content Template:Sticky header/styles.css.
[edit]Firstly, apologies for writing in English if this is not your first language (this is an automated message).
This template has been detected as one of 436 pages using styles that break the page when printed when the user is using dark mode. The fix is very straightforward - all your styles relating to dark mode must be scoped to. Since there is a high risk of this templates being copied to other wikis it is important this notice is acted on ASAP.
To fix this:
- Update `@media (prefers-color-scheme: dark` to `@media screen and (prefers-color-scheme: dark`
- Wrap any styles relating to `html.skin-theme-clientpref-night` in `@media screen`
If this message has not been acted on in 7 days, this will be fixed by an automated script. Thank you for your help fixing this important issue.
For any questions feel free to ask them at phab:T369874.
Jon (WMF) (talk) 18:18, 2 August 2024 (UTC) on behalf of the web team.
- Pinging Jroberson108. --Timeshifter (talk) 18:23, 2 August 2024 (UTC)
- @Jon: You are missing the closing parenthesis after "dark". These were already there, just not in the format of `@media screen and (prefers..."`, but `@media screen { @media (prefers...`. Print would not have been affected. I adjusted them anyways, so no real changes. Jroberson108 (talk) 18:52, 2 August 2024 (UTC)
Obsolete sticky-header-scroll class
[edit]The obsolete "sticky-header-scroll" class has been removed since the {{sticky table start}} template replaces it and works better. I've updated articles/templates that used it. Also, "max-height: 50vh;" should not be used because it is too short for mobile landscape. Jroberson108 (talk) 22:42, 2 August 2024 (UTC)
- Thanks! --Timeshifter (talk) 00:13, 3 August 2024 (UTC)
Overwriting of style attributes for rows
[edit]- With 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 |
- 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)
- @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)
- 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)
- @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)
- @Miria~01: You're welcome. If there is a discussion about accessibility, the info I mentioned can be found at MOS:COLOR, specifically
- 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)
Top sticky is not in the right place in Firefox
[edit]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:
--Timeshifter (talk) 08:32, 18 August 2024 (UTC)
- @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)
- 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)
- 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)
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)