Last modified: 2011-01-19 22:55:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9078 - TOC should be specifiable to ignore some headings (e.g., for infoboxes)
TOC should be specifiable to ignore some headings (e.g., for infoboxes)
Status: RESOLVED DUPLICATE of bug 6575
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2007-02-23 18:48 UTC by italvet
Modified: 2011-01-19 22:55 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description italvet 2007-02-23 18:48:29 UTC
when using infobox which transclude a page containing headings such ==, ===, ...
the __TOC__ is placed in the infobox :

The best solution appear to be not use html headings inside of infobox, but not
do so appears to be a little hacky at the level of layout design imho.

The cleanest way is that mediawiki not take into account the <h*> which are not
direct children of #bodyContent so that the only headings which count are those
which are directly writen inside of articles.
Comment 1 italvet 2007-02-23 19:02:45 UTC
* a little hacky if you consider layout design
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-02-23 19:11:29 UTC
Headings included from a template are direct children of #bodyContent, so that's
out, but we do track them and could presumably exclude them from the TOC if we
wanted to.  However, we don't, in general.  Some templates *should* have the TOC
placed before their first heading.  This can be fixed on a per-page basis by
adding __TOC__ to the appropriate place, but I don't know if that's a great
Comment 3 italvet 2007-02-23 19:29:37 UTC
"Headings included from a template are direct children of #bodyContent"

Not if the template is a div with specific #id, no ?

Adding __TOC__ to the apropriate place is the solution we use for now :
 but it's also hacky i think.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-02-23 19:39:16 UTC
Ah, children and not descendants.  Hmm.  An interesting thought, but that strikes
me as too fragile a heuristic.  People might want wrappers around perfectly
normal headings for one reason or another without necessarily wanting to defer
TOC display.
Comment 5 italvet 2007-02-23 19:53:20 UTC
(edit conflict)

quick links :

this is some page :

this is the transcluded page :

this is the template which set up the layout :

this is the css which customize the layout :

(after edit)
Do you think the cleanest way is for good to not use <h2> or <h3> for structure
infoboxes ?
Comment 6 italvet 2007-02-23 19:55:30 UTC
*infoboxes or all other meta-stuff that one have oportunity to put in the
heading of wiki pages ?
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-02-23 20:00:31 UTC
No, structural markup should be used.  What should happen is that particular
sections should be set as ignorable by the TOC somehow, like with a magic word
or an HTML class or something.  (Ideally they *should* be displayed in the TOC
if CSS is off, but that's not practical until widespread CSS3 support.)
Comment 8 italvet 2007-02-23 20:11:08 UTC
"ike with a magic word
or an HTML class or something"
>that looks a pretty idea

"Ideally they *should* be displayed in the TOC
if CSS is off"
>maybe not, the stucture ofthe infobox can be 
really out of scope of the page content. If you
consider such page :
(which is the esthetic goal we try to achieve), 
you see that headings such as "API .Net" or "ressources" 
are out of scope of the page itself.
Comment 9 italvet 2007-02-23 20:12:59 UTC
+ out of scope of the page itself but in the scope af all the wikibook (isn't
any [edit] button ?)
Comment 10 italvet 2007-02-24 13:12:10 UTC
My bad : surely the headings of infobox or book-toc should indeed both be
displayed in the toc, if it's obvious that the headings are sub-headings of the
infox/toc/whatever heading, and not in the scope of the article.
Comment 11 Paul Bailey 2009-09-05 15:03:29 UTC
I came across this bug with respect to info boxes that have transcluded comment sections on Wikipedia related to a template box [ Physics]. In that section they note, "Please note that if you put headers on the comments page (i.e. == Text ==, then the table of contents will get moved into the comments box also. You can avoid this by putting __TOC__ just below the physics template call on the article's talk page." And I would argue that if the person doing that does not take note of this, the person who tries to fix it will have to be very knowledgable about Wikimedia in order to figure out what the heck is going on. Basically the transclude and hide make where the TOC disappeared to very opaque.

It would make sense to me that if there is a desire to have some containers not have a TOC in them (i.e. if you have to tell people to add a TOC to the article because they are including a header in the section) then it would be really nice to make it possible to turn off putting a TOC above a particular container and make life a lot easier.

Finally, I will add that this issue irks me not because it should be easier, but because if you did not cause the problem, and do not know about it, it is really difficult to diagnose and so probably goes unfixed in several cases.
Comment 12 Chad H. 2011-01-19 22:55:33 UTC

*** This bug has been marked as a duplicate of bug 6575 ***

Note You need to log in before you can comment on or make changes to this bug.