alistrius wrote:

• a little hacky if you consider layout design

ayg wrote:

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
solution.

alistrius wrote:

"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 :
http://fr.wikibooks.org/w/index.php?title=Programmation_Basic_Casio/Prise_en_main_des_outils&diff=next&oldid=102041
but it's also hacky i think.

ayg wrote:

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.

alistrius wrote:

(edit conflict)

quick links :

this is some page :
http://fr.wikibooks.org/wiki/Programmation_Basic_Casio/Prise_en_main_des_outils

this is the transcluded page :
http://fr.wikibooks.org/wiki/Programmation_Basic_Casio/Sommaire

this is the template which set up the layout :
http://fr.wikibooks.org/wiki/Mod%C3%A8le:Sommaire

this is the css which customize the layout :
http://fr.wikibooks.org/wiki/MediaWiki:Common.css#Classes_pour_autoriser_une_centralisation_des_sommaires

(after edit)
Do you think the cleanest way is for good to not use <h2> or <h3> for structure
infoboxes ?

alistrius wrote:

*infoboxes or all other meta-stuff that one have oportunity to put in the
heading of wiki pages ?

ayg wrote:

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.)

alistrius wrote:

"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 :
http://fr.wikibooks.org/wiki/Programmation_C_sharp
(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.

alistrius wrote:

+ out of scope of the page itself but in the scope af all the wikibook (isn't
any [edit] button ?)

alistrius wrote:

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.

pdbailey wrote:

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 ***