Last modified: 2011-01-19 22:55:33 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.
* a little hacky if you consider layout design
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
"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.
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
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 :
Do you think the cleanest way is for good to not use <h2> or <h3> for structure
*infoboxes or all other meta-stuff that one have oportunity to put in the
heading of wiki pages ?
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.)
"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.
+ out of scope of the page itself but in the scope af all the wikibook (isn't
any  button ?)
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.
I came across this bug with respect to info boxes that have transcluded comment sections on Wikipedia related to a template box [http://en.wikipedia.org/wiki/Template:Physics#Leave_comments_to_explain_the_rating 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.
*** This bug has been marked as a duplicate of bug 6575 ***