Template talk:Hide inline TOC

Template disabled

This template was generating full, vertical Table of Contents on pages where it is transcluded, even when the NOTOC appeared after the template. I was not able to find a workaround, so I had to disable the template by enclosing all the code within noinclude tags, until a fix can be found. If there is a workaround, please lmk, but in any case a fix is needed. Adding FaviFake. Mathglot (talk) 00:55, 4 April 2026 (UTC)

@Mathglot Huh? It seemed to work. It should force the TOC to appear, thus intentionally overriding NOTOC, and hide it on every skin except V22, where it's in the sidebar. I don't understand what issues it was causing; is this not what it was doing? FaviFake (talk) 04:54, 4 April 2026 (UTC)

FaviFake, well then perhaps it is doing what it is supposed to, and maybe the problem was that this templates was included on pages where it should not have been. If that is the case, we can just revert the change here, find the places it was included incorrectly, and remove them. All I can tell you is that it forced the TOC to appear on the WP:Glossary page, where you added it in this edit. Was that a mistake? Should it not have been added? Just now I noticed you also added it to other pages that have the {{Compact TOC}} template, such as: List of commonly misused English words (diff), List of Latin and Greek words commonly used in systematic names (diff), List of traffic collisions (before 2000) (diff). Were those additions all mistakes? They forced pages having Compact TOC templates to also have a vertical TOC also, so there were two of them, which defeats the purpose of Compact TOC, namely to obviate the need for a long, vertical TOC. What do you see as the right outcome here? (subscribed; no ping needed) Thanks, Mathglot (talk) 05:28, 4 April 2026 (UTC)

Yes, all of these were intentional and worked as intended. I attempted to explain it in the /doc:

The Vector 2022 skin has the TOC on the sidebar, thus the TOC is not inserted inside articles (inline). However, some TOC templates automatically hide the TOC, and other pages manually hide it by using the _NOTOC_ magic word. This makes browsing lists much harder. Many of these pages are alphabetical lists, where having a TOC is useful for navigation.

I realise this is not very clear, but the point is that all these templates are hiding the TOC because many years ago the toc was just one block of text at the top of the page. So of course that's less useful than, say, {{compact toc}}. But now the TOC is sticky, so it's even more useful than any of those templates. However, we can't remove them, otherwise editors who use the old skins will be left with just have a huge list of section links at the top of the page.

So {{hit}} is a compromise. It preserves those templates for backwards compatibility, but allows users on the V22 skin to make use of the much better sticky TOC. FaviFake (talk) 05:36, 4 April 2026 (UTC)

I'm afraid I didn't understand much of that. Let's start with the Glossary and go step by step. The glossary has had a horizontal {{Compact TOC}} for years, rather than a vertical TOC, which would be 26 lines long (at least) one line each for 'A' to 'Z'. We don't want it to have a vertical TOC, just the horizontal one it always had. When you added the {{Hide inline TOC}}, it generated the vertical TOC, along with the compact horizontal one. So, it seems to me, all we have to do, is just remove the {{Hide inline TOC}} on the Glossary page and we're done, because that fixes the problem. Then we can revert the change I made to {{Hide inline TOC}}, and it won't affect the Glossary anymore. Do you agree with this approach? Mathglot (talk) 06:08, 4 April 2026 (UTC)

What I'm saying is that the lack of a sticky TOC for V22 editors is itself the problem, because, readers cannot quickly jump to the section they want whenever they want, but can only do it after looking for one of the templates.

WP:Glossary is maybe a bad example, but imagine other pages where there are much fewer TOC templates, or maybe just one at the top of the page. {{hit}} allows V22 readers to have the TOC available at all times without having to go searching for a TOC, while at the same time preserving the same experience for readers using older skins that lack a sticky TOC. FaviFake (talk) 06:19, 4 April 2026 (UTC)

It may be a bad example, but it is the example that I noticed breaking when the {{hit}} is included. That's one reason I wanted to start step by step, starting with the Glossary. So, I have to repeat my question: are you okay with removing {{hit}} from the Glossary? If so, that's one down, and we can move on to the next one.

Tracked in Phabricator
Task T317818

I also forgot that there was a Phab ticket related to this, and that I responded to it here. As far as I can tell, there wasn't any response to it, and I interpret this comment as meaning they have either deprioritized it, stopped work on it, or both but I may be wrong. Mathglot (talk) 06:29, 4 April 2026 (UTC)

The key part I think is this:

...while at the same time preserving the same experience for readers using older skins that lack a sticky TOC

Vector 2010 is an older skin, but the template doesn't seem to preserve the same experience, it adds an unwanted TOC where there was none before; at least, that's what it was doing at the Glossary. If you can get it to preserve the same experience, that would be great. Mathglot (talk) 07:01, 4 April 2026 (UTC)

What? The new TOC was supposed to be hidden by display:none on all non-V22 skins. Do you have a link? FaviFake (talk) 07:06, 4 April 2026 (UTC)

I just undid my change previous to your last comment to run some tests, and the unwanted vertical toc is back again. The link is WP:Glossary. I noticed one other change you made back in January, which was to add param |allowtoc=yes to the {{Compact TOC}} call in the glossary. This seems (according to the doc page) to have the same intent as adding the {{Hide inline TOC}} template, and is only intended for guideline pages (and would also be useful in the Template Examples section, where you don't want to suppress sections in the transcluded Template doc) so I don't know why you would need both that param, plus this template at the same time. That said, I tried with and without the parameter, and I don't see any difference in behavior, so not sure what's going on. But there are a lot of variables and I may have messed up; I will have to retry more carefully again later. Signing off for now; catch you tomorrow. Mathglot (talk) 07:23, 4 April 2026 (UTC)

Thanks! It does seem to appear, on https://en.wikipedia.org/wiki/Wikipedia:Glossary?useskin=vector, that's weird.

I don't know why you would need both that param, plus this template at the same time
If I'm not mistaken, some templates might not have all these fancy parameters, and in general the idea is to have 1 template that works with all of these TOC templates. But of course it needs to work, first... FaviFake (talk) 07:32, 4 April 2026 (UTC)

Tl;dr: This is a little tricky to explain, but it looks to me like the template is a technical implementation of a local user preference for full availability of the TOC at all times for V22 users only, overturning consensus about TOC placement reached at the target page (but only for V22 users, not for anyone else). Overturning consensus happens all the time and should be done through discussion, not through technical solutions affecting only a subset of users. If there are no valid use cases for the template that apply to all, it should be deleted.

Details: I'm trying to isolate the problem that may need to be addressed in a template like this one, by separating the issue about different behavior in different skins (a technical issue) from the issue about user preference regarding where or how frequently they wish to see page elements that work on any skin but are a matter of user choice and consensus, and not a technical issue. I am still grappling with coming to a full understanding of all this, but it seems to me that at least some portion of it may be an attempt to fix the latter (consensus issue) using techniques to fix the former (tech issue based on skin differences), which, if implemented, result in a technical solution that may override or deny the consensus reached among editors on an issue that is user choice, not technical. It was your comment above that led me to this analysis, where you said,

WP:Glossary is maybe a bad example, but imagine other pages where there are much fewer TOC templates, or maybe just one at the top of the page

I think this is key. It looks to me like it represents a user preference on a page for users of one skin only (V22), where users of other skins do not have the same access. The glossary is a "bad example", iiuc, because it has a lot of {{Compact TOC}}s throughout the page, and thus V22 users do not have to scroll very far to find one on a page where the standard TOC has been suppressed. Playing an advocate of your position, a better example of where the problem lies, would be a page that uses {{Compact TOC}} rarely, so that a V22 user would have to scroll a long way to find a TOC, instead of just conveniently glancing over at the left sidebar containing it. (Hope I restated your position correctly.)

To clarify what I am saying, let's take two specific pages to look at, that each use {{Compact TOC}}, so we are talking about something concrete: 1) the Wikipedia:Glossary, and 2) the article List of commonly misused English words. These two pages have two different approaches to page design and presentation, and I'll assume that the long-standing appearance of the pages indicates consensus in each case. The pages are alike in that both use the {{Compact TOC}} style and no standard, vertical TOC, but they are different in that #1 (the Glossary) repeats the {{Compact TOC}} frequently, almost for every letter, whereas #2 uses the {{Compact TOC}} once, at the top of the page.

I could be wrong, but what it looks like to me, is that the introduction of {{Hide inline TOC}} is not needed at all, at least, not in these two cases. The reason is, iiuc, that it is not solving any real difference between different skins. What it is actually doing, is what you said above (emphasis added):

but imagine other pages where there are much fewer TOC templates, or maybe just one at the top of the page. {{hit}} allows V22 readers to have the TOC available at all times without having to go searching for a TOC, while at the same time preserving the same experience for readers using older skins that lack a sticky TOC.

Precisely; I agree that that is what it does (well, the first part at least; the second part is broken, but let's assume for the sake of this discussion that that has been fixed, and works to spec). Why should it allow V22 readers to have the TOC available at all times, when users of other skins do not have it available at all times? In case #2, as a non-V22 user, I have to jump all the way to the top of the page to see the TOC, presumably because that was how editors on the page decided was the best presentation at some point. Why should users of V22 get special treatment to effectively overturn the consensus, because they decided they don't like the consensus on that page? Shouldn't they instead try to just change the consensus, rather than get around it by creating a template that makes the page have a different appearance on V22 than on other skins? This is what I meant about using a technical solution to fix a consensus issue. Even a WP:BOLD edit is possible at that page, removing the {{Compact TOC}} and reinstating the full, standard, vertical TOC, to see what happens.

It seems to me that {{Hide inline TOC}} is not really fixing a technical issue between V22 and older skins (though such differences exist and are tracked in Phab, this is not one of them), it is simply overriding the user consensus appearance of Table of Contents on the page by technical means. Such use of a template seems wrong-headed to me, and contrary to the principle of capital-C Consensus at Wikipedia, which is one of our core policies. I understand that as a V22 user, you would like V22 users to have the TOC available at all times at List of commonly misused English words and created the template to make that happen, but why should V22 users have the TOC available at all times if users of other skins do not? Instead, just overturn the consensus on the page to achieve that goal for everyone.

The upshot of all this, is that even if the Template is fixed so it does exactly what it is designed to do, I am opposed to its being used in the way it has been and is being used, namely, as a technical override of user consensus—doing so amounts to a type of impermissible WP:LOCALCONSENSUS. Still, my analysis is based primarily on pages that use {{Compact TOC}} and I may be missing something important. But the way it looks to me now, is that there is no use case where this template could be used in a policy and guideline-compliant manner. If that is true, then I don't believe it would survive a nomination at Afd. Do you see it differently? Mathglot (talk) 20:00, 4 April 2026 (UTC)

Jeez, thanks for the reply! I'll read it tomorrow morning FaviFake (talk) 20:08, 4 April 2026 (UTC)

I think you're framing it and thinking about it in a different way than I am. This isn't really an "or this or that" choice, and by this I mean that the appearance of the non-v22 page can still be improved even if the appearance of the page on v22 is improved as well. You can add more compact TOC templates to List of commonly misused English words, thus improving the navigation for non-v22 users, or i can add HIT, thus improving the navigation on v22, or we can do BOTH at the same time!

Why should it allow V22 readers to have the TOC available at all times, when users of other skins do not have it available at all times?
Maybe users of other skins should have it available at all times, or maybe they shouldn't, but this problem can be debated if needed) and solved by adding more Compact TOCs, regardless of whether there's a HIT template on the page. The page can still be improved for other skins' users even if it's improved for just V22 users. FaviFake (talk) 15:40, 5 April 2026 (UTC)

As far as "adding more Compact TOCs, regardless of whether there's a HIT template on the page", I don't see that as a general solution. It is essentially changing the page in order to plug a gap (or bug) in some other process. If there is consensus for adding more Compact TOCs to the page because it is desirable to have more Compact TOCs (as at the glossary), then great. But if not, it doesn't seem right to do so to fix an unrelated problem.

Secondly, when a {{Hit}} template is added to the page (in rev. 1311568905, before it was disabled), that will fix the lack of a full vertical TOC in V22, but at the expense of introducing one to other skins it is not wanted, so that you end up with both a vertical TOC at the top, and the Compact TOCs as well, thus defeating the whole point of having the Compact TOC in the first place. I think the starting point in all of this, is to get a fixed version of the template into the sandbox, so we can try it out. If the standard testcases page and header are used, the header will contain links for testing in multiple skins. Mathglot (talk) 00:38, 14 April 2026 (UTC)

Sure! I'd still love to solve this problem, using a template or in some other way. FaviFake (talk) 14:40, 14 April 2026 (UTC)

NOTOC inline

I've created a new experimental template {{NOTOC inline}}. For rationale and demos, see my comments on the talk page.

It's using the CSS from § Reason, and I see the caveat there, but I don't see why that's a problem:

However, many custom TOC templates like {{Compact TOC}} automatically add id="toc", so it is not so simple.

I also see the discussion above, but it's awfully verbose and I don't have the patience to read it right now.

From what I can tell, y'all are going for a really generic, elegant solution, but the CSS is more of a blunt solution. I'm fine with that personally, and it's working perfectly in my demos.

— W.andrea (talk) 22:09, 14 July 2026 (UTC)

Looks great! I'm curious to see if @Mathglot's worries are resolved by this new template you created.

I plan to redirect {{Hide inline TOC}} to your new template, since it already has a dozen mainspace transclusions, but I don't love its name. Do you think it could be renamed to {{Hide inline TOCs}}? (Among other things, the nice {{hit}} shortcut would still make sense.) FaviFake (talk) 11:13, 15 July 2026 (UTC)

The new template is a simple and effective means of removing any page elements with id toc from the rendered page by adding css display:none to the element. That should work just fine in any context where a Compact TOC (or any TOC) should not appear on a page. I did a couple of tests (not that it was necessary, because the functioning is obvious) using WP:Glossary as a test bed: one was a simple transclusion of {{NOTOC inline}}, and one with {{NOTOC inline|allowtoc=yes}}. Both tests successfully removed the Compact TOC from the Glossary page, both from the top of the page, and from the individual sections.

This is also what {{Hide inline TOC}} did before it was disabled, because that is an undesirable result on the Glossary page. Please do not add the new template to WP:Glossary, as it will disrupt the intended functioning of {{Compact TOC}} on that page. Be aware that {{Compact TOC}} is used on about 7,300 pages as well.

I would not simply redirect {{Hide inline TOC}} to {{NOTOC inline}}, either, as that would remove the Compact TOC on the dozen pages where {{Hide inline TOC}} is currently transcluded, including, for example, List of commonly misused English words, List of civil aircraft, etc. The Compact TOC apparently is desirable on those pages, and should not be removed without consensus, imho, although you could always try a bold edit, and see if anyone squawks. Mathglot (talk) 18:00, 15 July 2026 (UTC)

FaviFake, I only just noticed that you changed the display of the TOC in Compact format at the Wikipedia:Glossary again, this time by adding FORCETOC to the page in this edit on 2 July 2026, without discussing it at the Talk page or here. And this, despite the fact that previous attempts, such as with {{Hide inline TOC}}, have not worked and been undone. I'm all for finding a solution that works for you, but please do not just use a blunt instrument like FORCETOC (or any method) to force your preference instead of talking about it or finding a technical solution that works. Thanks, Mathglot (talk) 21:50, 18 July 2026 (UTC)

Oh, right. I'm not sure why i added it, but in the same edit i removed {{Hit}} so maybe i considered it a replacement. Anyway, can I added {{NOTOC inline}} to WP:Glossary since that one seems to work? FaviFake (talk) 11:03, 19 July 2026 (UTC)

No, because as I explained in the message of 18:00 15 July, that removes all TOCs, so using that or redirecting {{Hide inline TOC}} won't give the desired result. Perhaps someone should investigate differentiating the id element on TOCs of different types, perhaps something like having dual classes, #toc, and #ctoc; that might lead to something. Mathglot (talk) 16:48, 19 July 2026 (UTC)

Oh, it removes all inline TOCs even on non-V22 skins? This is so confusing. FaviFake (talk) 00:38, 20 July 2026 (UTC)

Didn't check other skins, but be my guest and see what happens when you try. I suspect it does, as the only thing it does, as mentioned, is add {display:none} to elements with id #toc, and a priori, I don't see how the skin would make a difference, but it's always possible the mediawiki parser (now Parsoid) does something special with different skins, but I wouldn't know about that. But I really think that phab: T317818 may be key, here. Mathglot (talk) 01:36, 20 July 2026 (UTC)

Would it be technically possible to hide all inline TOCs on that page, while keeping V22's sticky TOC and removing the default inline TOC of non-V22 skins? FaviFake (talk) 12:53, 20 July 2026 (UTC)