Wikivoyage talk:TOC Voyage Tips and guide

Swept in from the pub

Contents

Looks fine to me, can you be more specific? LtPowers (talk) 15:05, 15 January 2013 (UTC)Reply

The deal is that, unlike on Wikipedia, on Wikivoyage we float the page Table of Contents left and flow text around it. This gets more content onto the first screen view. But when the flowed text contains a bullet list that flows past the bottom of the Table of Contents, the bullets below the Table of Contents automatically align with the left margin and thus are not aligned with the bullets above them that are aligned along the right edge of the Table of Contents. People rightly expect bullets in bullet list to be vertically aligned with each other. So this looks strange and broken. It is strange and broken but we have gotten used to it. We would not have this problem if we floated the Table of Contents to the right side of the page instead. However, we usually have photos there on the right side. So we don't do that. We have lived with this layout imperfection for many years. I'd love to see it fixed so that bullet lists would not get misaligned when they flow past the bottom of the Table of Contents. Someday someone will solve this long standing problem. However, it is not critical and we seem to find other ways to enjoy ourselves. I love seeing content, especially photos of gorgeous places to go, on the first screen. --Rogerhc (talk) 20:31, 15 January 2013 (UTC)Reply

Yes, this is a problem. A good example of it messing up listings is Southern Coast (Fujian); the suburbs should be indented to a 2nd level (and are in the actual wiki text) leaving only the main cities (Quanzhou, Putian, Xiamen, Zhangzhou) at 1st level. The indentation is not visible now. Pashley (talk) 20:58, 15 January 2013 (UTC)Reply

Yes, separate levels of list item indent being lost when a list flows around the right side of the left floated Table of Contents is an additional problem. A CSS expert may be able to solve both these problems. Maybe? --Rogerhc (talk) 00:25, 16 January 2013 (UTC)Reply

I noticed a similar issue when looking at Somerset (England) using MSIE - the bullet points for cities/towns infiltrated the TOC box. This didn't happen using Firefox. -mattbuck (Talk) 21:25, 16 January 2013 (UTC)Reply

• I think Whittier has the same problem that's being discussed here. Half the TOC is at the top and half the TOC is in the middle. There's gotta be some way to fix that for longer articles; the current FA (Walt Disney World) takes up at least as many screens as Whittier and its TOC isn't split Purplebackpack89 (talk) 04:31, 17 January 2013 (UTC)Reply

Re Whittier, it's because some of the <buy> tags weren't closed with a matching </buy>; this seems to break the contents list. I fixed them. Dave.Dunford (talk) 16:21, 17 January 2013 (UTC)Reply

Hack Not sure how effective this hack is in all browsers but I have found that putting a wiki list within <div style="overflow:hidden;">in here</div> stops its list items that are flowing outside the right edge of the TOC from jumping left when they reach the bottom of the TOC box. Looks like this:

<div style="overflow:hidden;"><!--This DIV HACK prevents list items jumping left after TOC bottom-->
* Example text
* Example text
* Example text
* Example text
* Example text
</div><!--closes DIV HACK, above-->

It's a kludge. Maybe it is just better to live with the jump to left. It also fixes the missing indent problem of nested lists, I believe. To show this hack in action I have inserted the div into the Cities section of the Long Island guide that was mentioned at the beginning of this thread. --Rogerhc (talk) 23:42, 21 January 2013 (UTC)Reply

IE 9.0 on Windows 7 superimposes bullet list item bullets, when TOC floats to left of these, all the way into the left edge of TOC. This is a "Yuck! What's with this Website?" level problem that I only just now discovered because I don't use IE generally. My DIV HACK solves it but is just a hack. Does anyone have any ideas how we can fix our TOC problems perhaps with CSS in Mediawiki:Common.css, or some other way? Should we throw in the towel and just go with a TOC that stands on its own with nothing next to it at all? Ideas? --Rogerhc (talk) 02:15, 22 January 2013 (UTC)Reply

Swept in from the pub

Quick question, but why are the contents boxes different here than on other WMF projects? It's kind of annoying not having numbers there, and furthermore, section titles frequently span several lines, so without numbers they appear to be different things. -mattbuck (Talk) 09:16, 16 January 2013 (UTC)Reply

Table of Contents (TOC) item numbers are cruft that we intentionally leave out. However, long section names do look a little odd in the resulting TOC. Some CSS formatting such as out-denting initial line could solve this. Our TOC has other issues (see #Coding error, above) that also might be solved with some expert CSS formatting. Thanks for pointing this out. --Rogerhc (talk) 19:32, 16 January 2013 (UTC)Reply

(edit conflict) We had a discussion about this somewhere recently, but I can't remember the page. The problem with the numbers is that they add to the width of the box, which is a factor because we wrap text around the box. When we had numbers, a lot of articles were ending up with small ribbons of text between TOC boxes on the left and lead images on the right. Also, on our content pages, section headings should rarely be long enough to wrap, so it's never been seen as a big problem. Some way to distinguish wrapped lines from individual headings in the TOC would likely be welcome; perhaps it can be done with CSS? LtPowers (talk) 19:33, 16 January 2013 (UTC)9:33, 16 January 2013 (UTC)Reply

We don't usually use initialisms or acronyms for a policy title. --SHB2000 (talk | contribs | meta) 07:41, 19 May 2023 (UTC)Reply