Wikipedia talk:Section

This is the talk page of a redirect that has been merged and now targets the page:
• Help:Section
Because this page is not frequently watched, present and future discussions, edit requests and requested moves should take place at:
• Help talk:Section
Merged page edit history is maintained in order to preserve attributions.

Wikipedia Help

This redirect is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp articles

Section edits on diffs

The section editing feature in most cases does not work when the page is displayed with a table of differences between two versions (changes, cur, dif and last). First press Current revision.

Could this be corrected? - Patrick 21:43, 29 Jul 2003 (UTC)

Is the claim correct that section edit wont work with the pre-first-header-section? I thought it will work (and is there, cluttering the text of the first line of the pre-first-header-section)? -- till we *) 11:03, Jul 30, 2003 (UTC)

You are right, I have corrected it now. - Patrick 11:41, 30 Jul 2003 (UTC)

Inter-section edit conflicts

(moved from Wikipedia talk:Software updates)

Is there a reason why two people editing separate sections of an article generate edit conflicts? This makes it seem like the section editing is really just some syntactic sugar for "edit the whole page, but don't show it all to me in the edit box." Ideally separate sections could be edited without conflicts, though I have no idea how difficult this would be to implement. --Delirium 19:40, Jul 29, 2003 (UTC)

Difficult. We need a better, more general solution: a merging library that tries to merge two revisions. —Eloquence 06:32, Jul 30, 2003 (UTC)

I just tried it, I don't get an edit conflict. - Patrick 10:01, 30 Jul 2003 (UTC)

Edit conflicts with yourself are always suppressed so you don't trigger one by repeatedly submitting an edit form. You can simulate them by opening a separate browser (not browser window) and using one browser where you're logged in and one where you aren't.—Eloquence 11:43, Jul 30, 2003 (UTC)

But if the server can replace, in the latest version of an article, a section with a newer version, what is the edit conflict about if someone else has just edited another section? Is the edit conflict procedure unnecessarily triggered? Or is my browser handling the whole article in the background and sending the modified whole article back? - Patrick 12:20, 30 Jul 2003 (UTC)

It's not that simple, unfortunately. A person editing another section might have inserted new sections into that section, or removed the section entirely, thereby messing up the section count which the separate edit needs to insert its own section properly. Aside from that, we don't store the section number together with the other edit information, so the new edit has no information about which section was affected by the last one. We could do a diff, but that again would be quite complex. It would make more sense to just generally check if the two edits can be merged and do that it if possible, showing the user a diff after the merge.—Eloquence 12:25, Jul 30, 2003 (UTC)

No conflicts when different sections are edited will be introduced in version 1.3 of [www.mediawiki.org MediaWiki] --Iammaxus 23:42, 27 May 2004 (UTC)[reply]

A Simple Point Should Be Clarified

A first time user of the Wikipedia might well think that he can simply type text in the little text box.

But, reading to details, we find there are various cryptic looking codes to accomplish things.

It would be nice if the directions made it clear whether these codes form some kind well known system or whether they are unique only to the Wikipedia.

(I don't claim to know the answer, myself. Is it "html" ?) -- (unsigned comment)

It's not HTML. As far as I know, __TOC__ is used in several different wikis, but alien to the rest of the world. // Pathoschild 01:43, 5 October 2005 (UTC)

Table of contents in printable version

Moved from Wikipedia:Village pump on Sunday, September 21st, 02003.

do people think the table of contents [showhide] thing should be displayed when looking at a printable version of something?

On paper, it's pretty easy just to scan an article for the headings you want without needing a toc. Tristanb 10:01, 14 Sep 2003 (UTC)

The TOC should definitely be included on paper. You could argue that on a web page it is easier to find something as you can use ctrl F to search for something, whereas on paper you actually need to read it, so the TOC is probably more important on paper. Angela 10:25, Sep 14, 2003 (UTC)

What?? "Should definitely" -- Meaning the TOC "Must Absolutely" be included on paper? I find Id prefer to see the TOC minimized on the screen, (option to show) rather than on paper. The ideal would be having an option to show/hide on both screen and print. -戴&#30505sv 03:45, Sep 16, 2003 (UTC)

A choice would be nice, but in the absence of choice, I'd say it should be included. I assume you want the option before you print it. I read your message first thing this morning and was wondering how you could have such an option on paper. :) --Angela 18:49, Sep 16, 2003 (UTC)

Some long articles could fill numerous pages, seeming to justify a TOC with page numbers, but our typical article size (about 32K) does keep visual scanning practical. However, at least some links might benefit from page numbers. Deco 20:48, 15 Nov 2004 (UTC)

unwanted indents

Moved from Wikipedia:Village pump on Thursday, September 25th, 02003.

Why do some pages (my homepage for example) appear with the first line of the first paragraph slightly indented? It is not very attractive. What would would be attractive (IMHO) would be a convention to have a three-line drop-capital (like this) at the start of each article. Perhaps the style committee could look into it. Dr Adam Carr 01:00, 22 Sep 2003 (UTC)

This is a problem with the [edit] link. If you put two blank lines at the beginning of the article or page, it goes away. RickK 01:24, 22 Sep 2003 (UTC)

Internal link trickiness

Moved from Wikipedia:Village pump/March 2003 archive 2 on Thursday, September 25th, 02003.

At Timeline of trends in music (1980-present), there is a link for George Strait's album #7 in 1986, but the link functions as a self-link instead of leading to an article entitled #7. Is this a feature? If so, can it be fixed? Tuf-Kat

It's not precisely a self-link: it's linking to http://www.wikipedia.org/wiki/Timeline_of_trends_in_music_(1980-present)#7 - and a link I just tried in preview mode on this page linked to http://www.wikipedia.org/w/wiki.phtml?title=Wikipedia:Village_pump&action=submit#7. My guess is that the # sign is making something somewhere think that [[#7]] is a link to a within-page anchor, not to another article. I have no idea how to fix this, apart from forbidding article names beginning with #.

--Paul A 03:23 Mar 10, 2003 (UTC)

The # character is reserved and is not allowed in page titles. They are allowed in links purely for the purpose of linking to internal anchors -- but the syntax for defining internal anchors has never been enabled, so they aren't much good. ;) --Brion 04:40 Mar 10, 2003 (UTC)

See Sharp-P for an article with this problem. You may wish to call your article Number 7 (album) and use {{wrongtitle|#7}}. Deco 20:53, 15 Nov 2004 (UTC)

Dash versus vertical bar

For the Compact TOC format, the first example shows just the letters from A-Z with a single space between them. I find it more aesthetic to use vertical bars to separate the letters. The climbing glossary and list of climbing topics use this format. I have noticed a lot of other pages using dashes instead. The benefit of the vertical bar is that it takes less pixels on the screen so a better chance the entire A-Z list will appear on one line instead of broken up which makes it a bit harder to read. I have not come across a documented standardized way of displaying this type of TOC. RedWolf 05:42, Jan 2, 2004 (UTC)

links and references

The article C programming language currently uses a style for links and references that seems more pleasing (at least to me) than the usual style. Especially when there are References, See also, and External links lists, then I'd like to see the style used in C programming language promoted as general usage. Bevo 20:12, 5 Feb 2004 (UTC)

unnumbered TOC possible?

Hope it's Ok to add my question here, I'm using sections in MER-A timeline and the TOC numbers each date. Is it possible, without creating my own in html, to have the TOC appear without numbers and without bullets, like this?

Introduction
2003
2004
- 2004 January

The timeline used to be a monolithic list which I sectioned because

it grew to over 32K
it looked ugly
one could not navigate to a particular date

No, there's no way of turning off the numbering. The only thing you can do is turn off the whole TOC using __NOTOC__. Angela . 13:14, Mar 4, 2004 (UTC)

Well that isn't a solution since we need a TOC. Perl 20:25, 4 Mar 2004 (UTC)

That makes me wonder what the benefit of the numbers are in a TOC. They don't show up in the actual section labels, so you can't use them like you would page numbers (and I hope they never do show up on the labels). Maybe we should lobby for some software change to simply stop generating the numbers. - Bevo 20:43, 4 Mar 2004 (UTC)

They do show up in the section headings if you set this option in your preferences. Perhaps it would be best if the TOC was only numbered for those users who have the sections numbered? Angela . 23:33, Mar 5, 2004 (UTC)

How does one lobby for that? I have an example compact calendar-based TOC Talk:MER-B#TOC Table of Contents ideas that I'd like to see somehow.

There's somewhere on something called SourceForge that you register requests for software enhancements and bug fixes. See Wikipedia:Bug reports - Bevo 22:50, 4 Mar 2004 (UTC)

Feature suggestions can be entered at sourceforge, or discussed at MediaWiki feature request and bug report discussion on Meta. Angela . 23:33, Mar 5, 2004 (UTC)

I would also love to have the ability to turn off automatic numbering on certain Tables of Content. For example, Statutes, Regulations and Acts typically have their own numbering scheme for each section of the Statute, Regulation, Act, etc. When I make each mark each section of the law in order to generate a Table of Contents, I end up with the wiki numbering scheme for the TOC and also the law's numbering scheme, which does not look right. Banjolawyer 17:44, 4 Feb 2005 (UTC)

Well, I had the problem to switch off auto-numbering in TOC; this was possible for my local installation of mediawiki 1.5.6 in includes/Linker.php line 763; I have comment-out the line concatenating tocnumber to tocLine, but this is global for the whole installation ! Besides, there SHOLD BE a parallel version of TOC without auto-numbering, call it NONUM_TOC, --Zangler Hartl 10:16, 27 March 2006 (UTC)

Editing sections (from pump)

Why can't anon users edit sections? RickK

I'm guessing the section edit links are disabled by default because they could be confusing. I notice the default skin at the test wiki currently does show them for anons though - not sure whether that's a good thing or a bad thing... IMSoP 23:33, 22 Apr 2004 (UTC)

We're assuming that most anons are just readers, so they wouldn't want to look at edit links (and this is the way it should be, IMO the new skin shouldn't change this). Dori | Talk 02:39, Apr 23, 2004 (UTC)

"Anon" users can edit sections. I just did in order to make this comment... why would anyone think we can't? 213.232.66.5 22:35, 9 May 2005 (UTC)[reply]

Redirect to section

The Five Boroughs contains less information than City of New York#The Five Boroughs. Most of the info currently has to be maintained in both places. IMO, The Five Boroughs also tears the subject out of the valuable context of the City of New York article. But (as i learned by experimenting), overwriting The Five Boroughs with

#REDIRECT City of New York#The Five Boroughs

has the same effect as

#REDIRECT City of New York

Sounds like a useful SMOP to me, to have the Wiki engine use the section info instead of ignoring it. Has there ever been discussion of doing so? --Jerzy (t) 18:12, 2004 May 13 (UTC)

According to Wikipedia:How to edit a page, "Note that redirects to sections do not work yet. #REDIRECT [[United States#History]] will redirect to the United States page, but not to any particular section on it. It is possible this feature will be implemented in future, so such redirects could be used now for future compatibility." So, I guess it has been discussed, but not yet done. --Stormie 00:43, May 14, 2004 (UTC)

Out of interest, the reason this isn't as simple as it might seem is that currently, a redirect essentially replaces the content of a page, whereas the information telling the browser to focus on a particular header (the "#anchor" notation) is stored in the address. So, if you go to, say, New York City, the page's address is http://wiki.riteme.site/wiki/New_York_City (as you'd expect) - but the content is the same as that of City of New York (the target of the redirect) with an additional "redirected from" note. In order to redirect to a section, the browser would have to be told somehow to add "#section_name" to its own address - possible, but not trivial. With the current system, the browser is completely unaware that a redirect has been used, as it is all processed by the server. - IMSoP 13:51, 14 May 2004 (UTC)[reply]

Let's brainstorm technical solutions (see downpage for more about why this feature is important). To repeat the original example, suppose the The Five Boroughs is a redirect to City of New York#The Five Boroughs.

The content at that address is already modified to contain a note

(Redirected from The Five Boroughs)

Can't we at least change that note to something like

(Redirected from The Five Boroughs; jump to relevant section)

This useful hint will show up even if the user directly types the URL http://wiki.riteme.site/wiki/The_Five_Boroughs. It would be easy to implement and is certainly better than nothing.

If the user clicks on "jump to relevant section", their location bar will show the ugly URL http://wiki.riteme.site/wiki/The_Five_Boroughs#The_Five_Boroughs. We can improve this somewhat to http://wiki.riteme.site/wiki/The_Five_Boroughs#sec if the content, when reached by a redirect, is modified to include not only the note above but also the anchor

<A NAME="sec"></A>

at the appropriate point. The idea is that #sec is a standard and relatively unobtrusive suffix.

If there is no "appropriate point" because the section has been revised out of existence, the note should say

(Redirected from The Five Boroughs; however, relevant section "The Five Boroughs" no longer exists under that title on this page)

Now let's consider how we can make this jump to the relevant section happen automatically, e.g., when the reader clicks on another page's link to The Five Boroughs.

Apparently Javascript can do it without modifying the URL! (See e.g. [1], [2].) So we can embed a little Javascript in the page content. Browsers that support Javascript will jump automatically when the page is loaded. For browsers that don't support Javascript, the reader can still click on "jump to relevant section" ... or the server or browser can fall back to one of the options below, which carry out the jump automatically without depending on Javascript, though at the cost of a slightly uglier URL.

Using reloads would let us continue to refer to the section using the ordinary URL http://wiki.riteme.site/wiki/The_five_boroughs. The server should respond to that ordinary URL with a page that immediately reloads http://wiki.riteme.site/wiki/The_five_boroughs/#sec . Note the subtle trailing / before #sec in this case. Upon being told to reload, the browser asks the server for http://wiki.riteme.site/wiki/The_five_boroughs/ -- not quite the same URL as before! The server responds to this new URL by returning the content, including the redirect notice at the top and the <A NAME="sec"></A> in the middle. The browser then follows the client-side #sec part and jumps to the section.

(To make a prettier URL for the Javascript case, the reload page could dynamically choose to reload either http://wiki.riteme.site/wiki/The_five_boroughs/ or http://wiki.riteme.site/wiki/The_five_boroughs/#sec, according to whether Javascript is turned on or not. The prettier URL works with Javascript.)

(It is true that the prettier URL is not as portable. If the Javascript user mails it to a non-Javascript user, the latter will not get the automatic jump, but will have to click on "jump to relevant section." If that's unacceptable, then an alternative is to have the original URL http://wiki.riteme.site/wiki/The_five_boroughs contain either the desired content or a reload of http://wiki.riteme.site/wiki/The_five_boroughs/#sec, according to whether Javascript is turned on. If there's an efficient way to detect Javascript status at the server side, then it's easy to decide which one to generate. If the decision needs to be made at the client side, then it's a bit inefficient: the pretty URL must make the server send the whole page content, but if the user's browser doesn't have Javascript, it will only pay attention to the part of the page that tells the browser to immediately reload the same content under a different URL.)

Wiki-internal links to The Five Boroughs could actually link to http://wiki.riteme.site/wiki/The_Five_Boroughs#sec . In other words, MediaWiki could recognize that the link page is actually a redirect to a section, and accordingly generate a link ending in #sec.

This can be combined with the previous solution. That is, suppose the ordinary URL http://wiki.riteme.site/wiki/The_five_boroughs will also work, by triggering a reload of http://wiki.riteme.site/wiki/The_five_boroughs/#sec as described above. We may want still want to reduce server load by having wiki-internal links go directly to the latter URL (at least on wiki pages generated for a non-Javascript browser).

What do you think? 141.157.47.53 09:50, 30 Oct 2004 (UTC)

Additionally, it could be argued that being taken to a the middle of a page when you thought you were going to view a whole article could be a bit confusing, although this is true to a certain amount with normal links to a section. - IMSoP 13:51, 14 May 2004 (UTC)[reply]

As you say, it is equally true with normal links to a section. If normal links to a section are allowed, then surely it is desirable to allow a redirect mechanism for them. A strong reason is that such a redirect provides a stable URL to the section content.

As I develop this documentation wiki, I frequently find myself linking to sections. But my section links are fragile and sometimes break, because the section title may change in future, or the section eventually gets split out into its own page. I'd feel much safer if I could instead link to a page that redirects to the correct section. Then if something happens to the section, I only have to change the redirect page, not find all the links to the section (how?) and change them.

Certainly I'm glad MediaWiki allows section links. It would be much more disorienting to send the reader to the top of the page, as the section really is where the reader can find more information about the relevant technical feature. (The page is a tutorial walkthrough of some group of related features.) But the instability of these links is frustrating. It also discourages me from moving a frequently referenced section into its own page, even when I know I should. 141.157.47.53 07:22, 30 Oct 2004 (UTC)

By the way, it would be nice if MediaWiki noticed when you seemed to be retitling a section, and made an attempt to correct both direct and redirect links to that section. This would stabilize section links somewhat. But maybe it's too much to ask for ... 141.157.47.53 09:50, 30 Oct 2004 (UTC)

Here's a radical solution, though it would require a lot of redesign and I'm not sure I like it. We could introduce a new kind of section link, perhaps referenced by

[[City of New York/The_Five_Boroughs]]

. This would generate a URL such as http://wiki.riteme.site/wiki/City_of_New_York/The_Five_Boroughs that would dynamically serve up only the relevant section (plus a link to the whole City of New York page if the reader wants to see more than just that section). Redirects to this sectional page would work fine. This mechanism would also make it possible to write very long pages (a.k.a. "books") and have them still be manageable via these path-style URLs. Editing a sectional page would be equivalent to a section edit on the full page, which is already implemented. 141.157.47.53 09:50, 30 Oct 2004 (UTC)

Templates do not restart numbering

Sections in a template do not appear in the TOC of the referring page. The automatic section numbering restarts with 1 at the beginning of a template, and continues with the section numbering of the referring page itself after the template.

I've removed these sentences because they appear to no longer be true. See, for example, my Sep 1st edit of Wikipedia:How to edit a page, where the TOC numbering on the old version using the template is now screwed up even though it was working "as advertized" back in September when I made the edit. - dcljr 17:39, 7 Oct 2004 (UTC)

Choosing TOC level

Is it possible to limit the TOC to a certain level? I would like to prevent the listing of sub-sub-sections...Perhaps a __TOC_LEVEL_2__ token? (I could have sworn I posted this message 24 hours ago, but I must have forgotten...) — David Remahl 09:04, 28 Oct 2004 (UTC)

I would also like to see the same feature. – flamurai^TM 05:26, Feb 4, 2005 (UTC)

For example, see the TOC at Timpani which would be much more managable without the last level of headings displayed. – flamurai^TM 20:02, Feb 4, 2005 (UTC)

Yes please! This feature would be invaluable! --Anonymous use, Dec 9th, 2005

I've added this idea to the Village Pump. --Tom Edwards 13:26, 2 January 2006 (UTC)[reply]

Redirects to sections do work

Redirects to sections do work if you put a "w:" before the title.

#redirect [[w:Metasyntactic variable#Foo.2C Bar and Baz]]

However, you no longer get the "redirected from" message. Should this be mentioned in the help page or should it be hidden since it is not a recommended way to get a redirect? Angela . 16:34, Nov 9, 2004 (UTC)

Interesting. It is essentially an interwiki redirect to an internal page. As I dislike interwiki redirects with a passion, I'd be in favor of supressing this trick. Gentgeen 19:47, 15 Nov 2004 (UTC)

As long as it doesn't produce any adverse effects and it is invisible to the user I don't see any reason to suppress it. —Mike 03:01, Nov 16, 2004 (UTC)

I just tried it. It no longer works and does not jump to the section. --70.16.27.74 18:37, 17 Dec 2004 (UTC)

Right floating TOC

I would like to generate a discussion on the placement of the TOC within a page. I think on most wiki articles it actually looks a lot better of floated top right. Readers of English read from left to right, so having to TOC top right won't interfere with the initial reading of the subject matter. At the moment there can be a large white block underneath the intro which is used solely by the TOC on the left. If that list is long(ish) it just looks ugly. I spotted that Angela's talk page has a lot of info floated right, and copied the html to the Monmouth Rebellion page. This resulted in a much better looking page!

It has been deleted by a user claiming that it's not in the WS:MOS, but I can find no reference to the TOC with the MOS at all. I don't want to start an edit war, but I do think that a discussion on what actually looks good and readable is needed. Take a look at United States Senate for example. A long scroll past all the contents until the piece starts. Martin TB 16:35, 15 Nov 2004 (UTC)

The code added to Monmouth Rebellion was

If the TOC is going to be floated right, it needs to be done in a way which does not involve adding HTML to articles. It also needs to be consistent throughout, at least, the English Wikipedia, and preferably all Wikimedia projects. This can be changed in the global stylesheet to avoid needing to add the markup manually. I can't see any advantage to having some articles with a left TOC and some with a right. I do prefer a right-floating TOC, but I would oppose it if it was not applied globally and automatically. Angela . 17:19, Nov 15, 2004 (UTC)

I like it on the left, and I doubt we need a policy. Maurreen 17:53, 15 Nov 2004 (UTC)

I agree that it would need to be done globally without inline HTML or CSS. A floating right TOC makes some articles look better, but unfortunately it makes those that use the top-right area for images and infoboxes worse. --Mrwojo 18:04, 15 Nov 2004 (UTC)

I rather like the way it eliminates all the ugly white space, but agree that this should be done consistently or not at all. FWIW, to see what it looks like (without having to dig through history) here's a link to the Martin TB's version of the Monmouth Rebellion article: [3]. older≠wiser 18:18, Nov 15, 2004 (UTC)

That looks better than I expected. But I wonder about the result for large tables. Maurreen 18:35, 15 Nov 2004 (UTC)

As stated above, I do agree that it could be problematic if there is a shortcut top right, but its not insurmountable. Pictures can be moved left quite easily, and there are some pages with pictures left, right and across the middle in a line!
One real problem will be if the TOC is exceptionally wide, as is the case with United States Senate which has long chapter names. Nevertheless, I still feel that the TOC top right is much more aesthetically appealing. Martin TB 19:34, 15 Nov 2004 (UTC)

I hadn't considered the problem with images. This example shows the TOC very badly placed so perhaps trying to have them right aligned when most images and tables are already right-aligned is not going to work. Angela . 19:37, Nov 15, 2004 (UTC)

I've changed my .css file to incorporate right-floating TOCs. Here are two example screen schots. Image:TOC Monmouth.png, Image:TOC San Jose.png. I rather like the way they look. Gentgeen 19:40, 15 Nov 2004 (UTC)

That looks pretty good, actually - but I'd rather it was done without adding mark-up to the article. -- ALoan (Talk) 19:48, 15 Nov 2004 (UTC)

Hi the "user" mentioned above was me :) - sorry, I thought I had replied here earlier but can't have saved my edit. I was going to say that this was the part of the MOS I was thinking of (not actually WP:MOS but not too far away either). My concern was that TOC placement is reasonably standard (although NOTOC and the compact TOCs have their place) and I couldn't see a reason to adopt a non-standard TOC in this case.

I agree that white space to the right of the TOC can be problematic, although some people cleverly fill the space with a long image, and float-right TOC would avoid that problem, but, as others have pointed out, float-right TOCs will clash with float-right lead images and infoboxes and so on (particularly for antediluvian users of the classic skin - like me - for whom stacked floats don't work properly). -- ALoan (Talk) 19:43, 15 Nov 2004 (UTC)

Genteen, could you please try your CSS with Sgt. Pepper's Lonely Hearts Club Band. An album page with a long TOC. I liked your screenshots, and thought the TOC placement looked good. Martin TB 19:49, 15 Nov 2004 (UTC)

Ok, here it is. Image:TOC Sgt Pepper.png. Oh, by the way, there is no additional markup on the article page. I've changed my stylesheet to make everything that is called "toc" float on the right side of the page. Every page in the 'pedia with a TOC is displaying it this way right for me right now. Gentgeen 20:08, 15 Nov 2004 (UTC)

A number of articles I'm aware of float "category boxes" at the top-right linking to a number of similar topics, which might also conflict, but these seem to be moving to the bottom more often nowadays. However, if the TOC were confused with a category box, this might prove very confusing (imagine seeing History of Swartvenia in the box and not knowing if it's a section or a different article). Deco 00:11, 16 Nov 2004 (UTC)

White space can be good. It lets the page breathe. And readers are used to seeing tables of contents and similar matter on the left. Maurreen 03:46, 16 Nov 2004 (UTC)

From my own experience I would like to highly discourage making a floating TOC the standard rather than the exception. I have experimented with it in the past and finally settled on floating the TOC to the left in limited cases. And after doing this on a few articles I finally got tired of typing in the formatting and created a template to do it for me (and make it more consistent). First let me give you the limits that I believe would justify a float based on my experience:

In the case of an article with one or more pages of text occuring before the first section header (see abbot), it is necessary to manually move the TOC near the top of the article. I floated the TOC in this case to keep from adding unnecessary white space at the beginning of the article.
When the TOC is very long and there is no floating infoboxes or images in the way, I will float the TOC to the left. (see Wikisource: Treaties of Versailles and St. Germain as an extreme example of this)
I don't like to float the TOC when it is short. The previously cited example of Monmouth Rebellion is a good example of a TOC that is short enough that I wouldn't bother floating.
I never float a wide TOC. The United States Senate is a good example of this.
As was previously stated earlier in this discussion by others, images and infoboxes tend to be floated to the right so that the TOC can't be floated in many cases. If the TOC were floated it would cause a thin column of text to appear. I for one don't run my browser at full screen because I'm shifting back and forth between it and my word processor, etc. and anything more than one moderately wide floating item across any single line of text doesn't look very good. The formats used by Gentgeen would not look as nice on my system because they require more screen real estate than I have. Floating TOCs should be limited to cases where there is no other floating item in the way.

Additionally I want to mention that using a "div" to float the TOC is not good as it doesn't work properly in every case. A table has to be used instead. The template I'm using for floating the TOC to the left uses this proper table formatting (and you will also notice it uses a class rather than a style statement). The template is named Template:TOCembed. Ciao. —Mike 04:10, Nov 16, 2004 (UTC)

- Please note that Template:TOCembed has been nominated for deletion. It is been discussed on Wikipedia:Templates for deletion, and i suggest that peopel here with a strong opnion on thsi subject join that discussion. DES 17:40, 22 Jun 2005 (UTC)

My preference is for the status quo, with the TOC at the left, non-floating. I think that the option to have a right|float TOC could be offered in the user's preferences. Noisy | Talk 15:46, 20 Nov 2004 (UTC)

I kinda like it. See example. The only issue will be with articles with long TOCs and right-aligned tables/images. But I hate long TOCs anyway so those should be cut down in size by deleting un-needed section titles and splitting longer articles. --mav 21:00, 23 Nov 2004 (UTC)

I recall the discussion when TOC's were introduced and many of us argued for floating TOC's so as to avoid unproportionately large white spaces, orphaned introductory sentences, and TOC's popping up several screens into the article. I hope this finally gets implemented. mydogategodshat 05:02, 30 Nov 2004 (UTC)

This is a nice idea; it breaks up the article much less. The CSS should probably include "clear: both" to avoid interfering with floating images or tables. --ᓛᖁᑐ 10:36, 1 Dec 2004 (UTC)

Section Editing for the First section?

Can someone tell me how to use it? (I right-clicked and nothing happened.) Thanks. AirBa 18:26, 14 Feb 2005 (UTC)

When editing the first section I just click the Edit tab for the whole page…Barefootguru 21:25, 9 September 2005 (UTC)[reply]

Merged?

Considering that none of the information/guidelines on Wikipedia:Headings is included on this page, in what way can the former be considered "merged" into the latter? Hyacinth 21:38, 10 Jun 2005 (UTC)

More on floating TOCs

The guidelines on left and right floating TOCs now on the page were a result of discussion and a poll at Wikipedia talk:Manual of Style#Template:TOCright, and should be considered to have achieved consensus as guideliens, IMO. the discussion was advertised at WP:RFC and at the village pump for over a month. DES ^(talk) 23:05, 12 August 2005 (UTC)[reply]

Forcing TOC

Is it possible to force a TOC onto a page even if a user has their preferences set to suppress the TOC normally? Rossami (talk) 13:06, 8 September 2005 (UTC)[reply]

Article section: Opening a link in a header in a new window

"When right click editing is enabled, you cannot right click a link in a header to open it in a new window, etc. However most browsers have an alternative way of doing that (Mozilla: middle click, ctrl+left click, type ahead find, TAB navigation; Opera: middle click, shift+left click, ctrl+shift+left click; IE: shift+left click)."

First I'm not sure how appropriate a how-to-use-your-browser section is for this article, because it verges on being off-topic. Second, I don't really understand what this person is talking about. What is right click editing? Is this user talking about the very minor issue of a link in a section header not appearing in the TOC? (e.g. <TT>==[[Hello, World]]==</TT> would not have a link to the Hello, World article within the TOC but a link to the "#Hello, World" section within the same page.) —Tokek 22:07, 25 September 2005 (UTC)[reply]

Update: Apparently it was introduced with this edit, migrated from a bug report / feature request and a response to that over at Wikipedia:Software updates. Removing section from this article as non-notable/irrelevent, and frankly a non-issue because you can click on the section link in the TOC and then click on the link in the section header. —Tokek 22:24, 25 September 2005 (UTC)[reply]

This refers to an option in preferences which, using javascript, opens an edit page when you right-click on a heading. — Dan | Talk 02:52, 5 October 2005 (UTC)[reply]

Very long lists

The first page of Category:Redirects from title without diacritics ends at Augusto B. Leguia, so you have to click <next 200> many times. Inserting a TOC apparently didn't help much. It would be great if we had TOCs that, when users click on the letter <Q>, direct them to the first page of all entries that start with the letter Q. Do we have such TOCs or can somebody create them for use with all similar pages? Thanks in advance. – Wikipeditor 07:17, 31 October 2005 (UTC)[reply]

{{CategoryTOC}} —Cryptic (talk) 22:21, 31 October 2005 (UTC)[reply]

Thank you. – Wikipeditor 10:17, 2 November 2005 (UTC)[reply]

Display the TOC of a different page

Is it possible to display the TOC of another page (with links to the various sections)? Sort of like an index page.

"See also" line or section

There were minor differences in the parallel text on MoS. First, I tried harmonizing the two. On second thought, it just seemed better to merge the text there, as this was the only explicitly named section here.

However, MoS is getting rather large, and several other topics have been moved to a separate page. Shouldn't all the MoS Sections section be merged here, instead? (That's a bigger merge, thus more controversial, but it should be relatively clean here.)

--William Allen Simpson 00:56, 8 January 2006 (UTC)[reply]

{Main}, {See}

What's going on, there are undiscussed changes?

--William Allen Simpson 00:22, 28 January 2006 (UTC)[reply]

Where should the Bibliography go?

Currently, Wikipedia:Guide to layout#Standard appendices talks about a Bibliography section, but the preferred order in the "Appendix sections" section of this page doesn't show where to put the Bibliography. I would prefer to put it between References and External links. What does everyone else think? T J McKenzie 07:07, 16 February 2006 (UTC)[reply]

Thanks for fixing the change from Standardized to Standard. When folks change section headers, they forget to check for all references.

I always thought the Standard Appendices was the correct order. Let's list them all here, too. Heck, I see that Quotations is now deprecated, so let's toss that one. And Wikipedia:Filmographies seems to be inactive now. Always a problem to keep things synchronized!

--William Allen Simpson 19:27, 16 February 2006 (UTC)[reply]

Thanks for sorting that out. T J McKenzie 23:51, 17 February 2006 (UTC)[reply]

Has this been sorted out? Or did someone change the " 'Appendix sections' section of this page", as T J puts it, since February? Please take a look at my related Wikipedia talk:Citing sources#Appendices and their order post, as well. --J. J. 21:39, 27 April 2006 (UTC)[reply]

The following proposal is an outgrowth of #See also to bottom of page?, where I received a decent explanation for why navigational templates aren't located under “See also” and why “See also” is located where it is.

I have been convinced for a while now that there needs to be a separate standard appendix, named “Navigation”, for navigational templates. First of all, under current practices, the navigational templates appear to be part of one of the other standard appendices, usually “External links” or “References”. Moreover, most edits to the navigational templates show up under those standard appendices in the page history because the editor almost invariably uses the section edit link. (Who wants to deal with more wikitext in the edit box than they have to?) As a bonus, the categories and language links will also fall under “Navigation” and will be similarly displayed in the edit history.

This also helps work against another confusion: why aren't the navigational templates located under “See also”? By creating a separate template for single article links and navigational templates, it helps prevent a confused newbie (such as myself, long ago) from wanting to move navigational templates there.

— DLJessup (talk) 17:29, 4 March 2006 (UTC)[reply]

To clarify, you're referring to Wikipedia:Navigational_templates#Footers, right? I agree with others (from your initial topic above) that an additional section is not necessary since there are dozens of other "footers" that are commonly added at the bottom, as well. I mention this issue briefly at Wikipedia_talk:Citing_sources#Appendices_and_their_order; you may be interested. --J. J. 21:32, 27 April 2006 (UTC)[reply]

WP policy, if any, on a "Quotes section"?

I know WP is not supposed to have articles that are just lists of quotes (actually, there's an exception I find a little confusing: "Of course, there is nothing wrong with having lists if their entries are famous because they are associated with or significantly contributed to the list topic"). However, is a quotes section of an article frowned upon as well? I can't seem to find a policy on that; is there one? Шизомби 04:51, 8 March 2006 (UTC)[reply]

Sorry, found it here Wikipedia:Guide to layout#Quotations. Maybe it should be mentioned under Wikipedia:Section#Appendix sections. Шизомби 08:08, 8 March 2006 (UTC)[reply]

Searching sections?

Is there a way to search for text that appears in section headings, just as it is possible to search article titles? Шизомби 04:51, 8 March 2006 (UTC)[reply]