From Wikivoyage
Jump to navigation Jump to search

Let's fix the per page Table of Contents (TOC). The problems have been discussed at Wikivoyage:Travellers' pub#Coding error – now moved to Wikivoyage talk:TOC#Coding error (on the attached talk page).

Bullet lists[edit]

  • Hi (level-1). So, I put ul,ol{list-style-position:inside;} into my user:Rogerhc/common.css and... it fixes the IE 9 wandering bullets but introduces a problem at the same time--wrapped list items now line up with their bullets instead of with their first line of text. And it dose not solve the lack of indentation on nested lists. Nor dose it solve the jump left of list items flow past the bottom of TOC.
    • There (level-2)
  • Oh (level-1)
    • Hi! (level-2)
      • Bye! (level-3)
  • This
  • That
  • And
  • More

TOC Numbering[edit]

We don't need or want TOC item numbering, so numbering is suppressed in Mediawiki:Common.css with this:

/* Suppress numbering of items in TOC */
.tocnumber { display: none; }

This introduces a TOC readability issue: long TOC items wrap without any graphic indication. This makes it unclear which line in the TOC is a new section and which is just a wrapped line; a minor issue but worth fixing if we can.

Fix may prove tricky due to [+] and [-] getting in the way of implementing first-letter and first-line styling for unknown reason. Implemented by TocTree, see below.


[+] expand and [-] collapse is from m:Extension:TocTree and settable in user Preferences > Misc.

TOC float left is from m:Extension:TocTree and also settable in user Preferences > Misc.

Bullet list adjacent TOC[edit]

TocTree states this is known problem. So why isn't it fixed yet? Let's help fix it...

Bullet lists don't flow gracefully past right side of TOC.

  • Lists jump left when list flows past bottom of TOC. This is normal display inline behavior but is jarring for lists that are expected to be aligned vertically. Can we get display block to solve this? Div hack below does but is an HTML hack we don't want to see in the wiki markup.
  • List is not correctly indented (bullets float left a bit)
  • Nested lists fail to indent
  • IE 9.0 Windows 7 displays bullets in left edge of TOC when a bullet list flows at right of TOC.
  • Div hack can force such lists into compliance with user expectation, but its a hack:
<div style="overflow:hidden;">
* Some
* List
* Here

Example pages[edit]

  • Southern Coast (Fujian) has nested lists flowing at right of TOC that are missing expected indents. Try toggling "TOC float" off in your Preferences > Misc, to see what it should look like.
  • Long Island is an example of a page with the div style="overflow:hidden" hacked into one of the lists flowing to right of TOC. View its wiki markup to see.


  1. Do lists always have these problems when flowed around a float left box?
  2. Do other Web sites have this trouble?

Some mock up HTML pages might help answer this question...


...let's get out of the box, old ideas, new ideas, simple ideas, crazy ideas!

New ToC[edit]

I'd like us to have a completely new ToC. We've had the current one for some 8 years, and it's both stale and still problematic. It squishes text, messes with bullet points, shoves templates down, etc. I like the idea of a horizontal ToC at the very top of the article. --Peter Talk 22:23, 22 January 2013 (UTC)

Sounds interesting! Might be a pipe dream but if someone cooks some of those up, I'd love to taste test em! --Rogerhc (talk) 22:30, 22 January 2013 (UTC)
Someone actually did cook one up back in the day, but I can't for the life of me find the discussion. Maybe it got deleted accidentally at some point. --Peter Talk 22:39, 22 January 2013 (UTC)

A Destination Guide TOC and a plain vanilla TOC[edit]

A template could be used to insert a uniform Destination Guide specific TOC in destination guides, while a __TOC__ could be inserted anywhere else we want a normal plain vanilla Mediawiki TOC that just plain works. The site default could be no TOC till one or the other of those is manually added. This way destination guides could have a TOC that works well for them while other pages could use the plain vanilla TOC without customizations.

  • Problem: automatically showing a TOC when there are more than 3 sections on a page is a user override preference--users can override the site default in their preferences.
    • Solution: warn against doing that with a customized system message at the place that preference setting is displayed in preferences. (unsigned) 23 January 2013‎ Rogerhc

Drop something like this onto the destination page to turn off the TOC and replace it with a fake one?

__NOTOC__ Understand Get in See Do Buy Eat Drink Sleep Go next

All the sections are standardised so the same template every destination would work. K7L (talk) 00:43, 23 January 2013 (UTC)

I would love to have a destination guide-specific ToC. Having all the expandable subsections always seemed a little pointless, and a simple horizontal ToC bar like this (except hopefully a little prettier) would resolve all the various formatting problems caused by our current ToC. The subsection linking functionality of the ToC we have now, though, is better for talk page content. --Peter Talk 00:46, 23 January 2013 (UTC)
Right, so we could uninstall the [+][-] show/hide (mw:Extension:TocTree) extension which also is doing the float left that is causing trouble, and just use a standard plain vanilla TOC with no preferences tweaks needed. Pretty. I think we have a winner! Styling the winner will be frosting on the cake. Oh! The plain elegant simplicity of using a template to replace the TOC on Destination Guides! Love it. Just put __NOTOC__ in the template, sweet! Maybe some input from the others? --Rogerhc (talk) 04:22, 23 January 2013 (UTC)

A long time ago someone was messing around with an article for some small town in Central America, and while they were reverted the idea seemed neat so I kept it in a sandbox - see User:Wrh2/Sandbox, which is rough, but offers an idea of how we could put more information into a horizontal navbar at the top of the page. -- Ryan • (talk) • 04:57, 23 January 2013 (UTC)

Ryan, That looks really cool! However, that is region guide, not a destination guide, right? It's got lots more sections than a standard run of the mill destination guide. And the TOC on that page is not broken, and hm, works rather well maybe as is. Okay, I'm going to bed. But this is all good food for thought. Of course we could put an explicit __TOC__ magic word on pages like that. Could we live with a standard plain vanilla Mediawiki TOC there instead of the TocTree TOC? I'd like to see the troublesome TocTree Extension uninstalled because of the troubles it causes, unless it gets fixed. --Rogerhc (talk) 05:36, 23 January 2013 (UTC)
I was just throwing it out as a UI idea that could be applied to any type of article. It would of course be possible to suppress the TOC with __NOTOC__ and have it appear in a specific place with __TOC__. I actually like our existing TOC (I find it useful for navigating long pages) although I wish there was a better way to fit it into articles. I also think the idea of having some elements in a header might be useful. -- Ryan • (talk) • 05:56, 23 January 2013 (UTC)


  • When a page lacks a section, having a blue link to such a section breaks expected link behavior. This breaks user-site trust. Maybe use existing TOC logic to auto generate 1st level section links instead, which is elegant content focused bottom up structure, rather than trying to force a predefined set of links onto all pages. --Rogerhc (talk) 17:48, 23 January 2013 (UTC)

Seen in the wild![edit]

  • Southern Coast (Fujian) <------OnO-------here
    That page is a region guide more than a destination guide. So fit is not be perfect; the {{Go}} bar has no "Stay safe" link yet. Maybe it could be included in an options set? Maybe {{Go|x=region}} could trigger inclusion of standard region links? And or maybe {{Go|Stay safe}} could trigger inclusion of a "Stay safe" link? And {{Go|Stay safe|Another}} include "Another", etc? --Rogerhc (talk) 05:14, 23 January 2013 (UTC)
  • Nice! However, I notice that Roger did some other edits before applying that template, presumably adjusting things so the template would work. Is that going to happen for every article we apply it to? How much work is that likely to be?
    The adjustments are optional. All I did was add more equal signs around the "Talk" section so that it would be a sub-section of ==Understand==. Not strictly necessary, and if "Talk" is ends up being preferred as a standard section on its own rather than a subsection of "Understand" we can do that, too. The beauty of K7L's template, which I have parked at {{Go}} for test driving, is that it wont break anything. If someone puts it onto a destination guide that lacks one of the standard sections, nothing is broken. I think someone would just add the missing section to the page when they see this, I suppose. Let's test drive this thing, bumper car style! Bumping into a region guide is how I realized me might want to work out options for the template to add links like "Stay safe" to the "go" bar in region guides. --Rogerhc (talk) 05:24, 23 January 2013 (UTC)
  • If the above questions can be answered, I'd say this is a great idea, & we should apply it everywhere. Pashley (talk) 05:11, 23 January 2013 (UTC)
  • To test it with a fairly complex city article, I added it to Xiamen. It seems to work fine. Pashley (talk) 05:41, 23 January 2013 (UTC)
    It lacks links to Cope & Contact sections. Pashley (talk) 05:44, 23 January 2013 (UTC)

In general, regions should not have Eat, Drink & Sleep sections. We discourage listing bars etc. at higher levels; they go in the cities or towns. On the other hand, countries do need an overview of the cuisine. Even Huge City articles may not have those sections; the info goes in the district articles.

The basic idea here is clearly very good, but do we need multiple versions? Pashley (talk) 06:15, 23 January 2013 (UTC)

Regions do have eat, drink, & sleep sections! They're not as critical as they are for articles that have listings, but they do have them for overviews.
We will need a different template ToC for different article categories: countries, regions, huge city articles, small cities, parks, and districts all have slightly different subheadings. When articles have something a little more exotic, like a "See and Do" section, that will have to be taken care of manually with some sort of parameters, I would think. --Peter Talk 06:24, 23 January 2013 (UTC)
I agree a few different versions depending on article type would be great. A really simple version for most article. We could even think about putting an image in certain types of them rather than just the plain blue background seen here [1] Travel Doc James (talk · contribs · email) 09:56, 23 January 2013 (UTC)

Is there a reason this is being planned as a template instead of an extension, or perhaps using CSS? LtPowers (talk) 15:22, 23 January 2013 (UTC)

Getting an extension tested, approved and actually deployed to the WMF servers could easily take a couple of months, based on the progress of bugzilla:41983 and bugzilla:43220 (which both had proposed solutions in 2012; the fixes likely will be deployed to the servers around Feb 11, 2013). Certainly a template is something that can be easily done now as it doesn't change server PHP code. If we don't like it, it's easily reverted. Write an extension if you like, just don't be surprised if it takes a month to complete code review and then awaits deployment for the better part of another month. K7L (talk) 15:32, 23 January 2013 (UTC)
Well, my concern is that crafting a slightly wonky, if workable, template will dampen enthusiasm for designing a proper solution. I suppose at some point I'll have to teach myself how to write an extension, but it's a bit daunting. LtPowers (talk) 01:41, 24 January 2013 (UTC)
Yes we do need WVers who are will to take up programming. If we want to make changes most will need to come from within the group of editors. Travel Doc James (talk · contribs · email) 02:22, 24 January 2013 (UTC)

There have been at least two versions of this applied in Southern Coast (Fujian) at different times. I liked the original one much better than the current one; it made the menu stand out better. Pashley (talk) 12:58, 22 February 2013 (UTC)

Doing this[edit]

Are we doing this? I'd like to. What needs to be done before we can make the switch? --Peter Talk 23:00, 22 February 2013 (UTC)

I think we need to decide on a design, and figure out how to make it work with articles that have section headers different from the standard list. LtPowers (talk) 03:38, 23 February 2013 (UTC)

Muddying the waters[edit]

I know there are unresolved issues with the horizontal ToC discussed above, but...

All this talk about ToC and pretty banners for the new Main Page had me wondering if the two could be combined to create a new, much more enticing header, for our destination guides. An idea I had was to incorporate the page name and a horizontal ToC superimposed on a banner image. I roughed out some examples here:

  • User:Shaundd/Sandbox2 - two prototypes using the new banners for the main page -- one places both the page title and ToC on top of the image, while the other puts the ToC in a separate box to differentiate it a bit. These banners have a 3:1 ratio (width to height).
  • User:Shaundd - prototype on an actual page, with the ToC customized to suit the page. This banner has a 4:1 ratio.
  • Garibaldi Provincial Park - prototype with a separate ToC box prototype on an actual destination article. Banner has a 4:1 ratio. The page is a pretty low traffic mainspace page, but if you prefer I have this strictly in my Sandbox for now, let me know and I'll move it.

I haven't done a lot of testing on it so I don't know how robust the design is. It worked in Firefox, IE and Safari for me, but I haven't tested different font sizes. I also haven't figured out how to scale the image to screen width, so right now it is hard coded to 800px. Ultimately, I'd like to (experimentally) template this because I'm hoping that it could be reduced to just needing one parameter from the user -- the image name -- and everything else would fall into place. A second optional parameter could be a page name that would override the normal page name, for instances like Districts ("The Loop" instead of "Chicago/The Loop") or places with the same name ("Georgia" instead of "Georgia (country)"). I know next to nothing about templates though, so I freely admit I could be dreaming in blissful ignorance.

There's also the whole issue of whether we want to display the ToC horizontally and what is the best way to do this. I've just taken the Go template and modified it to left align as a starting point (I thought it looked better when I was building the prototypes), but I know the whole ToC issue is not a settled issue. For now though, I just wanted to put this out there and see what people think. Cheers. -Shaundd (talk) 17:17, 17 March 2013 (UTC)

They look relatively spiffy but take up too much space, and in general I don't think using a panorama for the header is a good idea because 1) the panoramas would have to all be exactly the same size and shape in order to present consistently and neatly (even among your models, one of them only reaches 2/3 of the way across my screen, which looks very odd), and 2) we are never going to have good, properly-sized panarama pictures for the vast majority of our destinations, which will further break the relative consistency of our page formats. I am all for exploring horizontal TOC options, but I think including a giant picture banner would be complicating things greatly.Texugo (talk) 17:59, 17 March 2013 (UTC)
Reminds me of mw:Athena. LtPowers (talk) 00:41, 18 March 2013 (UTC)
Those are really beautiful! I think the text should be bigger, though. I'm less concerned about them taking up too much space, since so much space is gained by losing that awful floating ToC box! If we have similar banners on our main page, then it would be a really nice parallel in usability. To Texugo's concern about panoramas—they're not actually needed. All you need is any photo that meets our minimum width needs, and then just crop it to the right dimensions. The bigger problem would simply be the work involved in doing this for our enormous number of pages. Maybe we could treat that as a long-term goal, in the same way we take illustrating our guides in general as a long-term goal, and use a boring horizontal ToC on the destination pages that for the meantime lack such a picture? --Peter Talk 04:33, 18 March 2013 (UTC)
(ec) Texugo - thanks for the comments. I agree that adding the picture complicates things and consistency is more difficult, but I'm not convinced those can't be minimized. Re #2, I agree that we won't always have a good image. To get around that, my thought is to have a default monochrome banner that would display the page name and ToC (I've added it to the bottom of User:Shaundd/Sandbox2) if the template is used without an image name parameter. If there is a suitable image, the image name parameter would be included in the template, and the panorama banner would display. The two banners (monochrome and panorama) wouldn't be perfectly consistent in look and shape, but I think it would help a great deal.
Re #1, it's helpful if all the images used in the header had the same width to height ratio. There would definitely need to be documentation about it. But if there is a default banner, I'm not sure how many users would try to change it. I'm also not convinced the panorama headers take up too much space. I think if the ratio of width to height is 4:1 or greater, it's OK. The lead images we have right now take up space and if the intro is too short, the image spills over into the next section and sometimes interferes with the contents (like regionlist templates). A header that combines the lead image and ToC creates a clean start for the rest of the article, which I think offsets the extra space it may use.
LtPowers - it does look a bit similar to Athena (but very unpolished by comparison). I like the look and feel of that.
Peter - I like your thinking! I agree this is a longer-term thing -- it could make a good expedition to find and add banner images over time. -Shaundd (talk) 04:47, 18 March 2013 (UTC)
That would be a very fun expedition ;) --Peter Talk 04:57, 18 March 2013 (UTC)
OK, I suppose having a blank the same size would alleviate my concern in that regard, though I think gray or white would be far preferable to a vacuous black. But I still think there are some issues to be resolved before I can support this:
  • We will need to work out a single standard size and have it always reach across the whole screen - even on my very narrow work computer, that Garibaldi park example only reaches about 80% of the way across
  • I think the banner is still too tall - since it needs to expand to fit the screen size, on a wide screen these would be really tall.
  • Your examples only include articles with a very few headers. How is the TOC going to look with articles with the maximum number of headers?
  • We are not going to care about second-level headers/expandability?
  • How will it look with long national park names or Llanfairpwllgwyngyllgogerychwyrndrobwyllllantysiliogogogoch?
  • Is it necessary to have "Travel guide contents:"? I think it would be plenty intuitive enough without and would lend a little more symmetry to the TOC.
  • I assume this ought to be used for all main namespace articles, so I'd like to see some examples of what could be used for a panorama in phrasebook or travel topic articles (How about Gap year travel, List of country calling codes, Tips for travel in developing countries, or Travellers' diarrhea?)
As an aside, if we do get this workable, there will be some other secondary changes to be made: Removal of the now-secondary lead image from country fact boxes, consideration of how the previous lead images look when all smooched up under a banner image, etc. And a personal opinion for later discussion is that panoramas need to be limited to only such a TOC, one per article -- I've never been a fan of the way panoramas break up the flow of articles, and if every article is given a prominent place for a panorama, I think that should be sufficient to eliminate them in the rest of the article.
Texugo (talk) 11:45, 18 March 2013 (UTC)
Do you include maps in your panorama prohibition? I have wide-format maps in Walt Disney World/Downtown Disney and Southern Tier. LtPowers (talk) 14:46, 18 March 2013 (UTC)
I think those are both perfectly reasonable. I don´t see why that would need to apply to maps, as maps are rarely that shape anyway. I just think it´s unnecessary for an article to have giant panorama of beach A, giant panorama of beach B, giant panorama of beaches A-D from atop mountain X, etc. Texugo (talk) 14:56, 18 March 2013 (UTC)

I am not very happy about Shaund's design, because it has too much color and does not match the overall text style of Wikivoyage travel guides. A large title picture should be followed by many nice pictures of similar size and beauty. But this is a matter of taste. Please, do not consider my opinion as an opposition to the proposal.

I also wanted to mention that on Russian Wikivoyage we developed a very simple and, seemingly, rather general solution of the ToC problem. You can see an example here. Of course, suggestions and comments are welcome. --Alexander (talk) 15:04, 18 March 2013 (UTC)

I've tweaked the banners a bit more to try to address some of the issues Texugo raised above. I rebuilt it using Mark's banner coding and put a couple of examples up on User:Shaundd/Sandbox3. With this new design:
  • The banner should scale to fit the screen width. It works on my computer and my cellphone, which have different resolutions, so I have my fingers crossed. Let me know if it works/doesn't work for you. I'll also check on my work computer tomorrow, which has a very wide screen.
  • I added an example to show what happens when the ToC has many sections (it wraps to the next line and the grey box expands to include it).
  • "Travel guide contents" isn't necessary, so I took it out.
  • I also tested what happens when a very long name is used (the second banner on User:Shaundd/Sandbox3). It fit most of the word in, but the excess part was not displayed. That is a variable that is set in the CSS, so I could set it to wrap around, but that would be pretty ugly. Another thing is right now I'm using an pre-existing style sheet. I can create a unique one for these headers with a slightly smaller font and less spacing from the top and the left, which would allow more text to fit in (and if the images are shorter, a smaller font would probably be needed so it doesn't overpower the image). Another thought is how many of these super long names exist? If it's not many, it could probably be handled on a case-by-base basis, or I could create a second style sheet for use when the name is very long.
I haven't had a chance to create shorter banners yet, but I'm hoping I'll have more time to do that tomorrow night. I agree we still need to sort out what to do about second-level headers and expandability, but that applies to any horizontal ToC. My thoughts are the second level headers aren't all that useful in a ToC for most destination guides, so I'd leave them out -- but that's just my gut reaction. -Shaundd (talk) 04:25, 19 March 2013 (UTC)
I don't see the text wrapping on my screen because the text doesn't reach the end of the line. In fact, the gray bars extend to the right past the end of the banners. But that's just me. =) I think I'd like to see the TOC text a little bigger, although that might become problematic on small screens. And there's also the mobile version to worry about. As for second-level headers (third, actually; first is the page title), I agree that most destination guides don't need them... but they would be useful in some. Ideally, I suppose, we could code up some CSS to drop down a menu of subsections when you hover over a TOC entry... LtPowers (talk) 13:01, 19 March 2013 (UTC)
I must admit I am kind of warming up to this idea. I don't agree that the TOC text should be larger - it's the same size as the current TOC and I don´t see why it would need to be bigger than that, plus the bigger that font, the more often it will expand onto a second line. I do like the idea of CSS to make drop down menus for subheaders. Some of my other concerns still apply though, especially the box being too tall - the body of the article doesn't even start until halfway down the page. I think that's a little too much, especially when the vast majority of pages are going to have a blank template there for a long long time. Texugo (talk) 15:31, 19 March 2013 (UTC)

OK, so here's my update for tonight:

  • I built this into a template (Template:Pagebanner) where the user provides (1) either an image name or none, which triggers the type of banner to use, and (2) a guide type, which triggers a ToC (e.g., entering "park" will display a Park article's first-level headings). I have three examples set up: Garibaldi Provincial Park, Dewdney and User:Shaundd/Sandbox3.
  • I changed the banner size so it's a 5:1 ratio instead of 4:1. The three examples above are all 5:1, while my user page still has the old 4:1 size for comparison. Does this look better?
  • I've adjusted the CSS so (hopefully) the grey bars extending past the banners that LtPowers mentioned above is fixed now. I think it was an issue where the screen resolution width was over 1366 or so.

There's still more to do, but that will be tomorrow's project. The idea of drop down menu sounds good... it may be beyond my skills, though. -Shaundd (talk) 06:09, 20 March 2013 (UTC)

Another improvement, yes. The three examples do not appear to be all the same ratio - the blank on (Dewdney) one is narrower and, I think, the perfect size. I think I could live with this if they were all that size, and if the blank template weren´t so black. Maybe we could come up with a default banner with a subtle design of some kind on it to use when there is no image? I also wonder if it would be possible to have it try to distribute the number of items evenly when it has to split the TOC into two lines, to avoid having one lonely item on the second line. Or would it look better if the TOC list were centered?
The template brings up a couple of other points to think about:
  • Will pre-programmed sets of TOC content really be good enough, or do we need something that will automatically pull the headers that each article has? There is quite a bit of variety in what headers are included, even among the same type of article - certain sections are omitted when not needed or sometimes combined when small (Eat and drink, See and do, etc), and itinerary and travel topics have all manner of headings.
  • Will this be implemented entirely by a template in every case, or could we use css, etc. to get the default banner to appear any time no template with image is specified? And related: Would the turning off of the default page name be done by template or by css?
Texugo (talk) 11:19, 20 March 2013 (UTC)
The default banner with a subtle design is a good idea. It will make it easier it get both banners the same size. I'm not sure if we can implement the default banner in CSS, though.
I'll try centering the ToC and see how that looks. Another thought I have for templates with a lot of headings (like Countries), is to put a line break in halfway through to force it onto two lines, more or less evenly.
Overall, the more I work on this, the more I think replicating the current structure of the ToC (i.e., capturing all headings and the expandability) is problematic. As you mentioned, there's quite a bit of variety in headings used, and at this point, I'm pretty convinced the only way we're going to capture that detail is to somehow pull the headers each article has, and then find a way to replicate that horizontally. I'm not sure how important a detailed ToC is versus a generic one that covers off the most important and used headings. Given the layout problems caused by the current ToC, I'm inclined to go with a more generic horizontal ToC that covers most situations (for initial implementation) while continuing to see if a better ToC can be developed. It would be good to get a lot of opinions on this. -Shaundd (talk) 14:37, 20 March 2013 (UTC)
A broken TOC is objectively worse than one that causes layout problems. On articles like Walt Disney World, the TOC would be broken. Having a TOC entry that goes nowhere is a very bad thing and would degrade readers' confidence in our site. Unfortunately -- because I do really like the idea -- I don't see much way around actually rejiggering the real TOC data rather than assuming a standard template. LtPowers (talk) 17:03, 20 March 2013 (UTC)
Also, if we used template options to create the TOC, we wouldn't be able to insert it in all our articles with a bot - we would have to do it manually because even if a bot can look for article-type categories, it is not going to know the difference between a small city, a medium-sized city and a huge city, which is a difference of quite a few headers. We would have to insert the template manually in every article to make sure it shows the right set of headers, and even then a lot of them would be off. I agree that we don´t want links that go nowhere. Texugo (talk) 17:35, 20 March 2013 (UTC)
OK, the ToC is definitely a problem (for now, anyway). After doing a lot of Googling, I don't think there's a way to recreate the ToC dynamically with just HTML and wiki mark-up. The kinda good news is there's a Horizontal TOC template that re-creates the standard Wikimedia ToC horizontally. The not-so-good news is I can't get it to fully work on WV. I've copied over the CSS and the code and it all works, except the ToC won't stretch across the screen like it does on WP. It's also not the most eye-catching thing when it encounters our subheadings. Anyway, a sample of it in action is on my user page and another where I'm working it into the template code at User:Shaundd/Sandbox2. Do you think this option is worth pursuing? I also found some templates that we could probably adapt to customize the ToC for articles like Walt Disney World, but the customization would have to be done manually. -Shaundd (talk) 05:24, 21 March 2013 (UTC)

I only just became aware of this discussion, and have read the whole lot. I really do like Shaundd's idea, and think it will go well in rebranding our site. I do think there are answers to some of the problems mentioned above.

For articles like Walt Disney World that have non-standard headers such as "See and Do", isn't it possible that after a bot has deployed the standard template to all pages, another bot could go through searching for headers like == See and do ==? When it finds such a header, the bot can either add a category that we can manually sort through (I can't imagine there being that many instances) or get the bot to automatically configure the TOC template itself.

I also don't feel that including sub-headers (3rd level) is that important. Most readers of our articles will be clicking on the primary headers. In most instances, getting to the sub-headers doesn't involve much scrolling anyway. By the way, I really don't like that Horizontal TOC that Wikipedia has. It isn't clear at all which header the [+] will expand; the one to the left or right? And after expanding, it is just messy and complicated when displaying the sub-headers in brackets.

The default, subtly-designed banner is a great idea. I imagine it could just be some white-grey gradient with a Wikivoyage watermark overlayed. Another interesting alternative could be to have aerial map banners for each continent, that are deployed on articles of their respective continents. So, for example, Dewdney would have a banner of an aerial shot of the North American continent on the right, that slowly fades to a different colour on the left.

I think if we can tackle each issue systematically, this is a fantastic idea that will really pump new life into our project. JamesA >talk 05:59, 1 April 2013 (UTC)

Also to just come across this discussion and had myself been experimenting with horizontal TOC (finding the same problems as discussed above). If we could get this solved I think it would be a an improvement to the style of pages and give WikiVoyage its own identity. --Traveler100 (talk) 06:25, 1 April 2013 (UTC)
I'll chime in to agree with James that the expandable headings aren't really needed. It will give us a much cleaner and more newbie-friendly look to just use the top level headers in the TOC itself. --Peter Talk 21:05, 1 April 2013 (UTC)
James - we could get bots to update the TOC for "See and do" afterwards, but I don't think it can ever match the reliability of using the existing Mediawiki TOC for a couple of reasons. One, there is a lot of variation in our guides -- sometimes Eat and Drink are combined, sometimes Cities and Other destinations are combined, Cities can be called Towns, or Villages, or Towns and villages (plus other names), Cope, Learn and Stay healthy are included or excluded in city articles on an ad hoc basis, etc -- so it would be difficult to get all our pages correct. Two, heading titles can change, over time a TOC updated by bot could become out of step with the headings on the page (an editor could decide to combine See and do, or break them apart; a Cope section could be added or removed). With the built-in TOC, it's at least always up-to-date. -Shaundd (talk) 04:46, 8 April 2013 (UTC)

Version two[edit]

Hi guys, thanks for all the feedback. I've tried to work out a few more of the kinks, so the template now:

  • uses shorter images -- two sizes are posted with 6:1 or 7:1 width to height ratios
  • uses the Wikimedia TOC so it automatically picks up all of our headings and will update automatically if the headings are changed (the TOC is no longer pre-programmed so less manual work and the links should always work)
  • uses a default banner image instead of a generic black box
  • allows a second variable that will display a name different than the official page name (e.g., Georgia (state) could display as "Georgia" in the banner)

Some issues/questions raised that the current version of template does not deal with are:

  • The banner doesn't load automatically if there is no template. I think we'd have to have an extension built if we wanted to go that route.
  • The TOC only displays first level headings, but the [+] or [-] is still produced if there are subheadings (even though they're not displayed). I don't see any HTML or CSS code that I can manipulate to turn this off. I suspect it is tied to the TocTree extension we use. If we move to these banners, maybe we could uninstall TocTree and that will make the [+] go away. That will have a knock on effect where every heading level displays in the TOC on pages that don't use the banner (e.g., Talk pages, Project pages). Not sure if people see this as a problem, the number of levels of headings that are displayed can be manually set on a page-by-page basis with another template that WP uses.
  • I've only got one default image. James' idea of a default banner based on continent is interesting, but it makes it more difficult to automate setting this up. Although, I guess if the default banner was initially setup by bot, the bot runs could be broken up in chunks so maybe there could be a North America bot, a South America bot, an Africa bot, etc. (I have no idea if this is feasible though). Another issue is there would have to be separate templates for each default banner, unless it's possible for the template to read the breadcrumb trail (anyone know?).

I put a new banner up at Wikivoyage:TOC/Banner and put some notes at Wikivoyage talk:TOC/Banner. I tried to capture points discussed here, but if I've missed anything feel free to bring it up there (I thought it would better to move the discussion of this particular style of the TOC to the talk page of the display banner). Cheers -Shaundd (talk) 04:09, 8 April 2013 (UTC)

I think this is a good idea. It adds a distinctive look to Wikivoyage compared to other Wiki sites, more a travel guide look. Moving the contents to the top of the page will remove the cramped area lower down where the contents tends to clash with maps and images.

Would be good to have less white space in the content list and no plus signs, but I have also been experimenting with this and could not find a better format. If we cannot remove the plus sign then I suggest keeping the option to explode the sub-sections. It would be possible to have continent specific bots by getting it to run down the Category:Region categories. --Traveler100 (talk) 14:05, 8 April 2013 (UTC)

Let's try to consolidate this discussion at Wikivoyage talk:TOC/Banner. Texugo (talk) 14:15, 8 April 2013 (UTC)

Broken TOC[edit]

In both Chromium and Firefox on Ubuntu the TOC in Cobblers Reef is broken up into two seperate TOC's, one in the intro (Understand), and the rest in the Facilities section, what gives? Sertmann (talk) 05:50, 23 January 2013 (UTC)

It was a missing </listing> tag. --Peter Talk 06:26, 23 January 2013 (UTC)