Not a bug.

alpeterson wrote:

forgot to reopen.. as a feature request

robchur wrote:

No. I reclosed it.

jamesp wrote:

So what happens for those of us with a very real need to exempt headings from
the ToC?

Bold-text-with-a-line-break is hardly ideal when you need to format "all
headings" in CSS, and it prevents purely semantic markup.

I don't see what suddenly including "hX" headings in the ToC does for the
software or the user - given we can still use "===" format to ensure inclusion
of a heading it merely removes functionality.

Apologies if this seems a bit blunt. I'm a new user of Wikimedia - I've been
searching all over for a solution to this problem, and now I've discovered the
functionality's been effectively removed (and the re-addition request closed)
with no reason given...?

jamesp wrote:

Addition: The including-hX-tags-in-ToCs functionality Aaron Peterson describes
is present at least as far back as MediaWiki 1.6.8.

In addition, the <nowiki><h3>...</h3></nowiki> syntax doesn't work either in
this version - the <nowiki> tag apparently escapes the angle-brackets so you get
your HTML echoed to the page, instead of interpreted by the browser.

ayg wrote:

For an application, consider something in [[m:Help:Section]] saying:

"These are what the various levels of headers look like:

First level

Second level

Third level

..."

I've run into this at [[s:Help:Editing poetry on Wikisource]]. It's not a real
heading, and showing up in the TOC would be screwy, but you want it to look
exactly like a real heading. That page uses a Monobook-centric hack that's
really not desirable.

jamesp wrote:

Oh well, I guess that's that, then.

Nice to see that helpful open-source ethos at work, eh?

jamesp wrote:

Oh well, I guess that's that, then.

Nice to see that helpful open-source ethos at work, eh?

robchur wrote:

If a document has a semantic header, and we show a table of contents, then it
makes sense to include that header in the table of contents.

Suggest possible syntax for doing so in wikitext.

actually, supressing the sematics of markup in some blocks would be useful - for
example for a page that showcases templates. It's verry annoying to have
categories that are imposed by the template show up on the page (and worse, the
page in the categories). Same goes for headlines present in such templates. So,
there could be a <showcase> tag or something, analogous to <noinclude> and freinds.

aculver wrote:

!== Non-TOC Section ==

Then you could do things like:
<includeonly>!</includeonly>== Section to not apprear in TOC of including pages ==
<noinclude>!<noinclude>== Sections to only appear in TOC of including pages ==
in your templates

brocvir wrote:

This feature sure would be nice. I keep wanting to use it when putting headings
in an "External links" section. I feel like categorizing external links is
helpful to readers. However, such links are very secondary to the actual
article, so I don't like seeing such headers take up a significant portion of
the ToC. Being able to make headers without including them in the ToC would
solve this issue quite nicely.

brian wrote:

(In reply to comment #12)

This feature sure would be nice. I keep wanting to use it when putting headingsin an "External links" section.

I feel like categorizing external links ishelpful to readers. However, such links are very secondary to the
actualarticle, so I don't like seeing such headers take up a significant portion ofthe ToC. Being able to make
headers without including them in the ToC wouldsolve this issue quite nicely.

How about foldable ToCs? Headings in the External links section really ought to be the the ToCs, but we could add
a markup option to have the External links section in the ToC folded by default.

krixel wrote:

http://pl.wikipedia.org/w/index.php?title=Dyskusja_szablonu:Cytuj_pismo&oldid=20837013

Of course you do not understand the text but I want to draw your attention to the fact that the TOC is excessive. Maybe TOC entries could be suppressed for short sections (based on length of text)?

• Bug 9078 has been marked as a duplicate of this bug. ***

@GOIII originally wrote in T118685 ...

Currently, the use of "straight" html heading tags...

<h2>Chapter Heading 4</h2>

... already differs from the typical wiki mark-up's usage...

== Chapter Heading 4 ==

... in that the [edit] link is not generated to the right of the headline text.

Unfortunately, the straight html element tag approach still causes each heading to become part of the built-in Table of Contents listing whether applicable or not.

:(

Hoping there is a way to have the parser skip the creation of the span element involved with subsequent ToC listing if some condition was met beforehand (such as the presence of a class name under the heading tag for example)

<h2 class="mw-legacy">Chapter Heading 4</h2>

Doesn't matter if the class is added by Linker.php(?) or if user's must add it themselves; whatever is easier.

See more details at: https://test2.wikipedia.org/wiki/Headings

In my experience, one of the consequences of this (feature? bug? limitation?) is that sometimes, non-semantic elements (like styled divs) are used in places where a h2...h6 element would make more sense. This ends up affecting accessibility, hence tagging with Accessibility.