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.

@GOIII : I renamed this report back to something closer to its initial title. The initial title was not great, but issue report titles should avoid suggesting specific solutions and stick to describing the problem in functional terms. This makes it easier to find tickets.
Moreover, I am not even sure of the sense of "Conditional use of plain heading element tags use".

In T8575#112057, @bzimport wrote:

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

I find it interesting that you mention page inclusions. Tiki Wiki CMS Groupware had a similar problem with footnotes, which were unconditionally inherited from included pages, until I made its parser contextual, allowing for example to exclude footnotes in included pages. The key here was context: the "distinct words under the same token" section, for example, should contain a different parsing context which would be excluded from the (main) ToC. It may be fine for headings in that context to generate ToC entries, but these should be in a different ToC.
This begs the question: Does MediaWiki allow explicitly creating a parsing subcontext (not merely implicitly when including)? Having the problematic content in a blockquote element treated as a subcontext, for example, could solve the problem.
Marking just individual headings as excluded does not seem optimal to me.

In T8575#10952951, @Chealer wrote:

This begs the question: Does MediaWiki allow explicitly creating a parsing subcontext (not merely implicitly when including)? Having the problematic content in a blockquote element treated as a subcontext, for example, could solve the problem.
Marking just individual headings as excluded does not seem optimal to me.

It does, and in fact it happens whenever you use an XML-style tag that allows more wikitext inside of it, e.g. <gallery> or <ref>. So I thought to test this, and indeed, if you put a <h2>…</h2> inside of these tags, it's shown as a heading but doesn't appear in the TOC. Therefore you could implement a workaround for this problem in an extension by just adding a parser tag that just calls back into the parser and returns the result, as described here: https://www.mediawiki.org/wiki/Manual:Tag_extensions#How_do_I_render_wikitext_in_my_extension?. (This is not always desirable; for example T114033 asks for the opposite behavior to be possible.)

However, that is not quite correct, as the headings actually must share some context to avoid generating identical id attributes in the output HTML. When I tested it with the old parser, every such tag restarted the numbering of identical headings. It actually works correctly in Parsoid though, so we might just wait for that instead of trying to fix it.