It would be nice to make this optional per-language version. For example, de: users seem really opposed to it and are happy with other solutions for working around the whitespace problem. --Evan 16:41, 17 June 2006 (EDT)

It's all messed up in IE 7. Check out this screenshot and this one. The actual article is pushed down below the TOC and left side menus. I like the look in Firefox, but have to say it's a no-go until the IE issues are resolved. -- Andrew Haggard (Sapphire) 16:02, 16 November 2006 (EST)

There are some fairly big and small problems in Firefox that may or may not be caused by the TOC alignment on Review. Most notably, if you click "edit" the edit box is no more than two lines in height. I'll upload a screen shot under Image:Reviewedit.PNG. The other problem I noticed is if you click on the Cincinnati guide in Review. Scroll down to the second image, that's directly below the "Please" infobox. Part of the text gets covered up by the second image. -- Sapphire 16:14, 16 November 2006 (EST)

Agreed about the IE7 stuff -- I'll see if I can fix it. The edit-box problem was unrelated to the menu -- I just hadn't kept the review site code up-to-date with the live site code. I've fixed that now. The Cincinnati page was built to have a whole bunch of stuff on the right side of the page. We're going to see some other alignment and layout problems due to this change; I think we can work around them. (They're the same problems you see now when you close the ToC on the live site, btw.) --Evan 11:33, 17 November 2006 (EST)

I don't like how it pushes the lead photograph below the ToC. Anyway to fix that? -- Andrew Haggard (Sapphire) 14:38, 7 December 2006 (EST)

Also in IE it creates far more whitespace than previously. Additionally, 'arrows' come up on IE, but if you close the 'arrows' the whitespace decreases on IE. A quick look over pages with quickbars isn't too bad so I wouldn't be too concerned with that. -- Andrew Haggard (Sapphire) 14:48, 7 December 2006 (EST)

I personally think the TOC on review: looks ugly on most of the articles, we had to reformat most articles to look good. One solution would be to make a wider quickbar or to hide the TOC by default. And it should be possible to hide it on the printable version, too. The best solution would of course be to include it in the toolbar on the left, if that is possible. --Flip666 16:57, 15 February 2007 (EST)

I think putting the ToC in the left-hand navbar is the best place, but you and I are in the minority on that one. --Evan 14:11, 15 March 2007 (EDT)

New, new style

So, I've created a new, new style that's visible on review, see http://wikitravel.org/review/France for an example. It puts the ToC in the upper-left-hand corner of the content area. This doesn't interfere with the navigation area, and since we almost always put our quickbars, images, etc. on the right of the page, it doesn't interfere with them, either. I need to figure out some CSS magic to pull the "twist down" arrows out to the right of the ToC entries (so they line up correctly), and tighten up the whitespace inside and outside of the box. But it's where I'd like to go with this.

The only pages where I've seen this cause a problem is when there's a very short lede (first paragraph) and a long list of regions or cities which wrap around the end of the ToC. I'll see what I can do to fix that. --Evan 14:11, 15 March 2007 (EDT)

It's the least bad attempt yet, but I still think it's bad. Is it really necessary to put the TOC above the intro paragraph? Why not keep it right after it with a dedicated block of space, as now, but just in a more condensed format? Also, while the idea of "click to expand" is very good, the current uneven list with big honking triangles is not at all obvious: it makes it look like, say, "Eat" is particularly important for some reason. Headings with and without subheadings should be on the same level, and boxed plus and minus would be nicer: see eg. this for an example of how it should be done. Jpatokal 15:04, 23 March 2007 (EDT)

IMO, the ToC displayed at http://wikitravel.org/review/Munich is aesthetically an improvement on the current version but a leap backwards in so far as it does not allow the position to be customised. I think that you need to be realistic and recognise that, since beauty is in the eye of the beholder, a humna will usually do a more elegant job of placement than an algorithm.

My suggestion would be to have the ToC appear automatically by default in a position to the right of the left hand margin (ie where it is in the Paris example) BUT immediately below the heading of the first section [ie NOT competing with the introduction (and often an infobox)] but then also allow its position to be customized by specific intelligent human placement if that default position produces ugliness or excessive white space on the page. ...Gaimhreadhan(kiwiexile at DMOZ) • 00:43, 24 March 2007 GMT

Thoughts:

Get rid of the extra whitespace on the left side of the new TOC (I see a margin of about 10 pixels). Following the CSS of en:Template:TOCleft should work.

Shrink the expand/condense images.

I like The idea suggested above about having the TOC display by default next to the first heading, rather than next to the intro.

Otherwise this new version seems good to me, and something that would be nice to see enabled. -- Ryan 06:19, 24 March 2007 (EDT)

The main reason I want it flush with the first section is because I eventually want to have optional split-page navigation of guides by section (see en:Wikitravel talk:Article templates#The best Wikitravel articles are too damn long and http://wikitravel.org/examples/Paris). When guides are split into different pages, what is now the Table of Contents will become the menu for navigating between the the section pages. If there's only one section on the page, putting the ToC at the end of that section is going to make it difficult for people to find, and hard to navigate quickly between parts of a guide.

As far as a human override: I'm a little nervous about that, since it means that essential navigation bounces around to different parts of the page. It also requires considerably more work on my part, because of how I'm moving the ToC. -- I'm not even sure it's possible. --User:Evan 10:16, 24 March 2007 (EDT)

(Responding to a bunch of things) I'd prefer +/- bullets for collapsing sections; the twirling triangle is a Mac-ism that isn't as clear to the unwashed masses. :) The Munich example does some ugly things to the layout of the text if your font size and screen geometry aren't just right, leaving white space on the left and/or right if the second section has to wrap around boxes on either side. (At least it does in Firefox and Konqueror; Safari's OK, and I don't have IE handy). I really don't like the idea of relocating the TOC on a page-by-page basis; I can tolerate typesetting no-no's like left-aligned text having to follow a moving left margin, but standard UI elements should not move like that; functionality trumps beauty in UI decisions. - TVerBeek 12:18, 24 March 2007 (EDT)

I've had a re-think on ToC's - especially after reading the comments here.

As I see it, you're trying to achieve three things with your new ToC:-

1) Make the page look better.

I think you've achieved this first goal which is not a trivial one - it will be important to the price of advertising on the page and users (subconsciously at least) devalue the authority and value of scrappy looking pages. In this regard, I suggest:

a) reduce considerably the padding inside the left and right margins of the box so that it becomes considerably narrower (I congratulate you on wrapping individual headings within the ToC already and using two smaller fonts for headings and sub-headings which are both a big improvement).
b) increase the padding outside the right hand ToC border.
[If you expand the subdivisions of the ToC at http://wikitravel.org/review/France#Stay_healthy and then scrutinise things you will find that the right hand border of the ToC is then butting right up against the bullets of the list in "

The Ile de France is the region surrounding the French capital, Paris.

The North is one region where the world wars have left many scars. It includes Nord-Pas de Calais, Picardie, and Haute-Normandie...etc, etc"

2) Make the ToC more helpful and usable for users

Here you need to default to the most useful configuration for naive and/or non-perceptive users. This means you need to:

c) default to ToC fully expanded right down to third level sub headings
d) Retain the ability to "hide" and "expand" the whole ToC fully (with the default condition set as "expanded")
e) Have the word "Contents" moved inside the ToC, keep this word "Contents" black not blue and centre it in the largest font you use in the ToC CSS
f) Have the following phrase in blue and smaller font and centred just below this: "(hide for printing)" If you do this then you will remove the need for custom ToC placement altogether since experienced and/or perceptive users will twig that they can save paper by hiding the ToC before printing
g) retain the arrows but have them in outline with a minus sign visible within to denote that they can be clicked to collapse a particular heading [-] and a plus [+] inside the arrow to denote it can be expanded if clicked.
h) for most users the directions the arrows point are presently counter intuitive: they should point downwards to denote that one can "drill down" or expand a heading and point upwards to denote that one can go up or contract a section. Arrows facing horizontally are confusing to most and I for one did not even realise they were clickable until I did some playing around - I thought they were just highlighting an important section...

3) Do a bit of future-proofing for clever stuff to come.

If you follow my suggestion, then you will have substantially eliminated the need for customised ToC placement! ...Gaimhreadhan(kiwiexile at DMOZ) • 22:43, 25 March 2007 BST

Here is my question. Why have we abandoned the idea of putting the ToC on the right? The reason we got into trouble last time was not because folks objected to having the ToC on the right. It was because the ToC placement was screwing up the image-placement tactics that had been adopted to take care of the too-much-whitespace problem. As I see it, wherever we place the ToC, it is going to screw up the placement of the lead image anyway. So why not have a fresh look at the ToC placement on the right? Especially now that we are going to make it a per-language change, so that if the German Wikitravellers do not want to adapt to the change, they don't have to?

The reason I want to have the ToC on the right is that once we have the ToC safely out of the way, we can get it to float. That will be much better for navigation. — Ravikiran r 03:17, 26 March 2007 (EDT)

I abandoned the idea of putting the ToC on the right, inside the content area, because it interfered a lot with the layout of most pages (quick bars, images tend to go on the right side). I don't have a problem with moving it back there if people have the energy to reformat the pages.

Putting the ToC on the right in a separate column had a lot of detractors, not least the people at Internet Brands. That's the most likely spot for a column of text ads in the future, so they asked that I find another place to put the ToC.

Finally, the suggestion that there'd be an exception for de: has lost some currency since the suggester is no longer active on Wikitravel. --Evan 09:43, 26 March 2007 (EDT)

And again

A new version is up on Wikitravel review; see http://wikitravel.org/review/France. There's still one layout bug -- toc entries that are longer than one line wrap funny -- but otherwise I think this meets a lot of the requirements from above. I've fixed up the whitespace inside and outside the box so it doesn't take too much space nor bump into list items. I've replaced the arrows with pluses and minuses (putting a plus or minus over the tiny arrowheads didn't look very good), and I've made them align to the left of the text. I didn't add a "hide for printing" note; I'm just going to make it so the printable versions don't have a (useless) ToC.

Very quick first impressions: looks good to me, with the caveat that the plus sign takes up a lot of space (it would be better if it was smaller) and the second-level indents could be deeper as it's not completely clear that they are sub-headings. These are minor nitpicks though - the left alignment with text flowing around it seems like a good improvement. -- Ryan 12:36, 5 April 2007 (EDT)

I think it's the best version I've seen. The deeper indent will mean a wider column, so it's a trade off there... Maj 12:38, 5 April 2007 (EDT)

I was about to suggest indenting too. Two spaces should be enough. It looks like the words are wrapped, so it is not that big a trade off. Otherwise this looks production ready. — Ravikiran r 12:40, 5 April 2007 (EDT)

I like it, but there's one thing that slightly bugs me. If you expand the "Get around" section for the USA. There's the sub-header "By Recreational Vehicle (RV)" that looks somewhat weird. Explaining why is a bit difficult, but is it possible to possibly widen the ToC a bit so that the sub-header will fit perfectly, rather than take up two lines? It's the same thing for France under "Get around" you'll see a sub-header about getting visas or something, which confused me because I thought it was a top-level header. If this can't be easily fixed or would cause more conflicts please write my complaints off so we can get this done and over with. -- Sapphire • (Talk) • 13:19, 5 April 2007 (EDT)

I'm probably missing something from the previous discussions but can't we just have the TOC hidden/collapsed by default on both the online and print versions? I guess it'd solve most of the whitespace issue, which by the way, doesn't bother me at all. And honestly, I know you've devoted time and creativity to changing it, but I personally like the "old" version better than any of those new proposals. Or maybe I've just gotten used to it anyway. -- Ricardo (Rmx) 14:08, 5 April 2007 (EDT)

I'm kind of with you. I really don't have a problem with the ToC as it is, but I'm not opposed to changing either. Also, I think this is going to be a wiki-by-wiki decision so pt: won't be required to adopt it, right Evan? -- Sapphire • (Talk) • 14:15, 5 April 2007 (EDT)

I'd rather not do that, if possible. It makes maintaining the different versions a lot harder for me. --Evan 14:57, 5 April 2007 (EDT)

I think this new latest version is great. Only things I saw and didn't like were already mentioned above... 2nd level needs more indenting, and + signs slightly too big... but I think this is much nicer looking than the current TOC. Would also vote for it being collapsed by default... – cacahuatetalk 21:00, 5 April 2007 (EDT)

I like it a lot! Excellent job. I think this is production ready. I agree with some of the comments, but they are very minor and can be fixed as we go along. The funky wrap on long lines does not look that great, but again this can be fixed and improved upon later. The massive white space is gone. I give two thumbs up! Great job Evan. -- Xltel 21:48, 5 April 2007 (EDT)

The "collapsed by default" thing would make a nice preference since a lot of people would probably rather NOT have it collapsed (myself included). Assuming you're using Javascript then it should be reasonably easy to just set a cookie to remember the collapsed-or-not state, but if you're ready to push this live soon then that might make a nice enhancement for later. A more difficult issue is going to be getting all versions to give their OK on this - any thoughts on how to roll this out without starting a revolt? Perhaps an email to the admin list asking admins to add their comments and post a message in the language-specific pubs requesting feedback? Maybe set a planned rollout date of 01-May so enough people can chime in? -- Ryan 00:43, 6 April 2007 (EDT)

It's really hard to get positive sign-off for anything in the Wiki world. It's also not part of our technical infrastructure policy. The main thing I'm concerned about is that everyone gets a chance to comment, that no one feel that their voice wasn't heard and that they didn't get a chance to respond. I'll send an email to the admin-list and I'll leave a message in all the of the various pubs (although it's really the liaison's job to do that...). I don't think waiting until May 1st is necessary or even a good idea. I'd like to make this change next week, Tuesday or Wednesday. --Evan 10:26, 6 April 2007 (EDT)

I might be wrong, but there won't be a revolt over the size of the indents. The last time there was a revolt because the placement of the ToC was upsetting the formatting of all articles. That problem will occur even now and quite frankly, it is not a big deal. The changes to get the formatting in shape are quite obvious and can be handled in the wiki way. The key thing is to get a buy-in. The problems that occurred the last time was more to do with other issues. - Ravikiran.

A distinct improvement, Evan!

Except for one flaw (see below) you have achieved the first objective to Make the page look better.

You are also well on the way to the second: Make the ToC more helpful and usable for users

In my view, this is what remains to be done:

1) Change the word "contents" to either "Contents" or "CONTENTS" and move it inside the ToC box (not abandoned forlornly and semantically orphaned outside), keep this word "Contents" black not blue and aligned left in the largest font you use in the ToC CSS

2) You need to default to the most useful configuration for naive and/or non-perceptive users. This means you need to:

a) default to ToC fully expanded right down to third level sub headings

b) Retain the ability to "hide" and "expand" the whole ToC fully (with the default condition set as "expanded")

and either

c) Have the following phrase in blue and smaller font and centred just below the aligned left Contents: "(hide for printing)" If you do this then you will remove the need for custom ToC placement altogether since experienced and/or perceptive users will twig that they can save paper by hiding the ToC before printing

or

d) Default to fully expanded on both display and print but initiate a user-settable preference under "skin" (perhaps label it the "treesaver" skin), that hides the ToC when printing.

e) make sure that the appearance of the [+] (expand) and [-] (contract) symbols changes when a user hovers the mouse over them. My suggestion would be to have them slightly smaller in appearance to begin with and then slightly enlarge and in bold font when they are mouse-overed...

Responses here: 1) good idea. 2a) I think that expanding the ToC fully by default would take up too much space, without much benefit. It's not crucially important that newbies who aren't familiar with twist-down tree controls (which is a pretty small segment of the computer-using population) click directly to second-level headings. If someone can't figure out how to click to "By boat", they'll still be able to click to "Get in". 2b) I'm not excited about having the whole ToC collapsible. In a split-pages scenario (Tech:Optionally split long guides into one page per section), the ToC becomes essential navigation between pages, and hiding it is a bad idea. 2c) I'm going to make it so that the ToC never shows up in print, so this is unnecessary. 2d) same. 2e) I'll try, but again I don't think it's a tragedy if a novice user can't expand the ToC.

What I will definitely do: make the plus and minus smaller; make the second- and third-level headings indent farther; make the text wrapping work a little better; make the ToC a little wider to make text wrap less frequently. --Evan 10:36, 6 April 2007 (EDT)

I'm late to this discussion - didn't even know it existed until the roll-out today. So I apologize if it seems like I'm wandering in and taking pot-shots at the hard work you've already discussed and done. I don't like the new ToC. This, for example, seems so busy to me - three sections side-by-side clamoring for my attention as I first glance at the article (four, if you include the standard navbar at far left). That sudden overload puts me off as a reader - I don't know where to direct my attention. Also, as already mentioned, the Understand section on most articles comes running up to get squashed between part of the ToC and the lead image. Visually, it's a really bad first impression to make.

To add something other than complaints to the discussion, here are my two suggestions.

1. Horizontal ToC. Put it left-to-right under the line that underlines the name of the article. Unobtrusive, out of the way quickly (and good for printing) but there if the reader needs it. Shouldn't take more than two lines for any article, one for most. Begin the intro text, lead image and article space below that.

2. Ditch the ToC. I doubt this will be a popular suggestion. But given that we have a standardized format and all significant articles are held to it, why do we really need a ToC? Look at any printed book travel guide - they explain their section structure at the beginning, but they don't have a ToC before every individual article in the book.

So I'll be honest: once little bugs in the current version of the ToC are fixed, it's going to plummet to the very bottom of my TODO list. It's been a thorn in my side for a year now, and we've had really, really, really long chatter about it. We've tried the ToC in just about any place possible on the page, and this has been the spot that's gotten the most "I like it!"s and the least "I'll kill you!"s.

I don't think the horizontal ToC under the page title will work, since that's where we put geographical breadcrumbs. I'm mixed about ditching the ToC entirely; I think that when we optionally split long guides into one page per section we'll want to have that kind of navigation between sections.

I understand your concern about making a good first impression, but I think we're making a much better first impression than when we had acres of whitespace above the fold (like here). --Evan 13:21, 10 May 2007 (EDT)

Well, my fault for being unaware there was a discussion underway. I know it's brutal to build consensus. Frankly, this is an "I'll kill you!" for me, but maybe I'm alone in that. It's like trying to read a novel written on the Tokyo skyline - I look at it and I have to force myself to read any further. The problem in that San Diego example is resolved as soon as you put a nice lead image in the article - then the white space isn't apparent until the user has already read the intro and looked at the image, and the white space is reduced even more if you use small fonts in the ToC as with the new design. This, however, makes every article equally problematic, and I'm not sure what to do to make them look any better. Seems like we've solved a problem some articles have by giving all articles a problem.

Is it at least possible to not let the Understand rise up like that - force it to stay below the ToC? I still don't like having intro text squashed between ToC and the lead image, since we're now starting the article by asking the reader to read from the center of the page - and then switching to asking them to read from the left of the page - but if that's the way it need be, the less squashing, the better. Gorilla Jones 16:18, 10 May 2007 (EDT)

I have to say I agree with Gorilla Jones about forcing the first section to stay below the TOC - it's especially bad in my opinion when it's a region/district section, and the list starts to get broken up like this. Other than that I really like the new TOC... better design, and most importantly I can just leave it collapsed. woohoo! – cacahuatetalk 03:10, 11 May 2007 (EDT)

Just making sure this doesn't get lost since it's above the rest of the discussion... is this agreeable / doable Evan? The en:United States of America article which uses the new regionlist temlate is an even more glaring example of why we should fix this... – cacahuatetalk 13:31, 11 May 2007 (EDT)

I have to agree with Gorilla and Cacahuate here. Having a section get broken up like that looks really crap. Texugo 05:01, 12 May 2007 (EDT)

Me four. On ja, people are already sticking little <br clear=all>'s after the intro section to stop it from happening, so figuring out a way to make this happen automagically shouldn't be too difficult. Jpatokal 07:52, 16 May 2007 (EDT)

Except that br clear=all forces text to go below the infobox if there is one, not just the TOC. Argh. Jpatokal 22:02, 16 May 2007 (EDT)

When it happens

In Firefox and Safari, the bullets do not line up properly in the space to the right of the new TOC. They are in the margin rather than at the margin, and on the OS X version of Firefox 2 they're actually touching the border of the TOC. e.g. en:Estonia - TVerBeek 11:55, 10 May 2007 (EDT)

In IE6, the TOC subtopics are all displayed at first, even though the twist-controls say "+". It takes 2 clicks to close them (one to "open", the next to close). - TVerBeek 11:55, 10 May 2007 (EDT)

So, you shouldn't see bullets at all. Can you force-reload a page so you get the new version of the CSS file? --Evan 12:38, 10 May 2007 (EDT)

I think he does not speak about bullets in the TOC but next to it. See de:München. If your browser window is wide enough the bullet list in the first paragraph will be next to the TOC. The bullets are too much on the left. Make your browser windows smaller so the list will move under the TOC, then you can see how it should look like. If you want, I could make a screenshot. --Flip666writeme! • 12:46, 10 May 2007 (EDT)

OK, I think I fixed the IE problem, and I've put in a little numeric code to force the reloading of the .js and .css files that were modified. I'll see if I can do something about the bullet points in the article text. --Evan 13:21, 10 May 2007 (EDT)

Yes, the IE problem is fixed. The bullets/margins issue is illustrated at Image:bullets-n-margins.png. Whether it's because of a CSS reload or what, the problem is less pronounced on Firefox/OSX now than it was at first (the bullets are no longer touching the TOC), but there's still a rendering glitch there. It also shows in IE6 and FF/Win. I recall that there's a CSS attribute that controls which side of the margin the bullets appear on; maybe that needs to be hard-coded to "inside" rather than letting the browser guess? - TVerBeek 16:36, 10 May 2007 (EDT)

Wow! Nicely illustrated! I'll see what I can do... it's a very interesting problem. --Evan 17:09, 10 May 2007 (EDT)

The keywords __TOC__ __NOTOC__ etc. do not work. See my de: Userpage. On en: it seems to be ok, see here, but maybe only because it does not have so many headlines. --Flip666writeme! • 21:16, 10 May 2007 (EDT)

TOC and viewing differences

Well, I think the new table of contents looks great. The only problem I see is that it now appears at the top when viewing differences, pushing the differences over so that one has to sidescroll to see everything. Can we suppress the TOC when viewing differences, as we did before? Or simply push it down below the differences into the article where it would normally appear? Texugo 17:43, 10 May 2007 (EDT)

Yes, I think it needs to be aligned with the top of the contents when viewing differences. I'll see what I can do. --Evan 07:59, 11 May 2007 (EDT)

"contents"

Purely an aesthetic-preference suggestion, not a bug: If the word "contents" (or the language equivalent) at the top of the TOC box were omitted (or moved inside the box if we must, but I don't think the label is necessary), the top of the TOC box would line up with the top of the first line of text. I would find that more pleasing to the eye than having it offset downward as it is now. - TVerBeek 22:51, 10 May 2007 (EDT)

I agree with this as well. I don't think the label is necessary at all. Texugo 23:11, 10 May 2007 (EDT)

You need to default to the most useful configuration for naive and/or non-perceptive users. This means you need to:

a) default to ToC fully expanded right down to third level sub headings

b) Retain the ability to "hide" and "expand" the whole ToC fully (with the default condition set as "expanded")

c) Either lose the word entirely or have the word "Contents" moved inside the ToC, keep this word "Contents" black not blue and centre it in the largest font you use in the ToC CSS

d) Have the following phrase in blue and smaller font and centred just below this: "(hide for printing)" If you do this then you will remove the need for custom ToC placement altogether since experienced and/or perceptive users will twig that they can save paper by hiding the ToC before printing

If you follow my suggestions, then you will have substantially eliminated the need for customised ToC placement! ...Gaimhreadhan(kiwiexile at DMOZ) • 19:43, 20 May 2007 BST

Strongly disagree with TOC being expanded by default. It being collapsed is the best thing about the new TOC... and solves the whole problem we're addressing in the first place... the excess of whitespace. – cacahuatetalk 02:37, 23 May 2007 (EDT)

I also like the TOC to start collapsed.Texugo 04:55, 23 May 2007 (EDT)

+ sign not working?

When I click on the + signs nothing is happening... it's not expanding the section... I'm using the latest version of Safari on OSX – cacahuatetalk 02:57, 11 May 2007 (EDT)

Evan, the site slowdown is more important to fix right now of course. However, I too get no action when I click on the new ToC's "+" expander do-dad in Konqueror which is my browser of choice. *If* the "+" expansion do-dad is JavaScript, keep in mind that Konqueror orders it's page-elements array differently than other major browsers do. I don't know how this "+" do-dad is scripted but if it uses a page-elements array such as document.getElementsByName then just maybe this tip might help. I'm a JavaScript novice. Don't allow me to steer you wrong but the unexpected order in which Konqueror stores items it its page-elements array (document.getElementsByName I think) threw me once, till I "alterted" the items out and discovered their order. Sorry I can't remember more exactly. HTH, :-) Rogerhc 01:56, 3 June 2007 (EDT)

What should happen

copied in from Evan's talk page archives... – this I think sums up what still needs doing:

I think these are good suggestions. Gorilla Jones 01:00, 7 June 2007 (EDT)

How to fix it

I don't think all-sections-below-the-TOC is the best solution; it'd do ugly things to articles with brief intros and longish TOCs (like lots of city articles). Changing the regionlist template so that the left margin can move when it clears the TOC (Do the div tags wrapped around it prevent that? Are they needed for any other reason?) might be preferable. Yes, folks, I did learn at art-and-design school that a jumping left margin is Bad Layout, but I believe it's a lesser sin than the Gaping Hole Of White in the middle of the screen that would result from shoving all sections below the TOC (which is the problem this whole wrappable-TOC exercise was intended to eliminate). - TVerBeek 08:48, 20 June 2007 (EDT)

City articles with longish TOCs are less likely to have the whitespace problem - they probably have a nice photo up top, because a longish TOC means someone has been putting a lot of work into the article. (And if there's no photo, make a priority to find one - if Namche Bazaar can be done in a day, where else is that hard?) The jumping left margin causes a lot of problems for page design, and unlike the white space, they can't be fixed by simply improving the article with an image. I think we've caught all of the articles with infoboxes that got screwed up as a result, but that's still a layout issue. Anyway, as I've said, to my eye, the jumping left margin is a greater sin than the white space, especially now that the potential white space has been shrunken by the small ToC.

Would still love to see that word 'contents' above the TOC axed. Everything would line up so nicely without it. Gorilla Jones 10:21, 20 June 2007 (EDT)

The en/San Diego article strikes me as a useful case study for chasing white space. Evan gave an example up top of how its excessive white space was a problem. Now, it's got a smaller TOC and two reasonably interesting images, and a humongous amount of whitespace below them because of its largely empty 'districts' section. Whitespace is apparently a bit like whack-a-mole. Gorilla Jones 10:28, 20 June 2007 (EDT)

San Diego's district section really needs to change though, that's not an acceptable way to district it, it will hopefully soon be reduced to 5 or 6 manageable districts, with sub-districts if necessary not listed on the main page, which will fix that issue. I agree with Gorilla that the margin issue creates a greater eyesore than the white space did. Yes that's what we were trying to fix in the first place, but we did improve it greatly by having the collapsed-by-default TOC. The only problem I can see is if you end up making a preference setting where people can have the TOC fully expanded by default, then it may create a lot of white space. Maybe I'm being ridiculous since I don't know anything about that kind of design, but would it even be possible to build the moving margin into the preference? If someone selects "expanded by default" for the TOC pref then it would also activate the moving margin? Either way, I'd still rather see some whitespace then have the left margin wrap like that... it looks horrible :( – cacahuatetalk 20:34, 20 June 2007 (EDT)

Ditto what Cacahuate said. I'd rather have a little gap fillable by a picture than have a "Little Billy's first webpage" layout where even simple lists get chopped in two. Texugo 20:50, 20 June 2007 (EDT)

It maybe works once only then stops working. And only works this once after I purge the Wikitravel page in question's cache (by clicking history and then changing the word "history" to "purge" in the URL in browser location bar, hitting return and clicking that OK button). --Rogerhc 20:14, 21 June 2007 (EDT)