Template talk:Routemap/Archive 2: Difference between revisions

This is an archive of past discussions about Template:Routemap. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

I noticed at {{Kanpur–Phaphund–Tundla section}} that the font size for {{BSsplit}} renders text at 77% of the default, which is too small for accessibility, per MOS:FONTSIZE. Normally, I would go through the code and adjust the code that makes that text too small, but the module code for this template stacks font size reductions in a way that I was unable to parse. It appears that the stacking is 95% times 85% times 95%, but I could definitely be wrong, and I don't know the best place to fix the problem so that the rest of the template's text remains at the desired sizes. The minimum allowable font size reduction is to 85%. Is anyone here willing to take on this adjustment? Thanks. – Jonesey95 (talk) 15:23, 16 June 2020 (UTC)

I have pointed this out often, yet there are still people who think that using {{BSsplit}} is somehow "better" than accessibility considerations. --Redrose64 🌹 (talk) 19:45, 16 June 2020 (UTC)

I'm sure that this was discussed in relation to an RDT for somewhere in East Anglia. But I've found Template talk:Richmond station routemap#Text size, so am notifying RexxS (talk · contribs). --Redrose64 🌹 (talk) 19:56, 16 June 2020 (UTC)

I sorted that out in 2018. Since then the styles have been moved to Template:Routemap/styles.css by Jc86035 and the scaling has been introduced which results in non-compliant text. --RexxS (talk) 20:38, 16 June 2020 (UTC)

 Fixed. That was helpful. As far as I can figure it, the "RMsi" style in the .css file is applying a 90% reduction to text that is already at normal*0.88*1.07=95%, resulting in a size of 85.5%. And then the module was applying a further 90% reduction. On the assumption that styling is intended to be in the .css file as much as possible, I have removed the duplicate 90% reduction, which was presumably an oversight, from the module. There may be other tweaks needed for different bits of text that this module renders. Thanks for the links and clues, all! – Jonesey95 (talk) 21:42, 16 June 2020 (UTC)

@Jonesey95 and RexxS: I don't think the duplicate reduction was an oversight; I believe it was more or less like that before I converted it to Lua, and I didn't get around to putting the CSS into the TemplateStyles CSS page. (The text is actually slightly smaller than before, but this is because I was trying to make {{Routemap}} display properly on the mobile site, which uses larger text for everything, and so a reduction was necessary to prevent the two rows of text from overlapping.)

I've reverted the change for now because {{BSsplit}} is also used in {{BS-map}}, which does not use TemplateStyles and wouldn't have had a duplicate reduction introduced. I think the styling for the template does deserve a more thorough look, since it hasn't been maintained in a while; in addition, since TemplateStyles has been introduced in the intervening years, it should now be possible to apply better styling to {{BSsplit}} and {{BSto}}. Specifically, in {{Routemap}}, the sidebars have primary and secondary text sizes, with the latter (from the .RMsi class) being 90% of the default. TemplateStyles would now make it possible for {{BSsplit}}'s contents to have the same font size regardless of whether or not the template is used inside a .RMsi element, and so it would become easier to control the minimum font size. (Alternatively, the font size could be made partly skin-based; this also wouldn't have been possible before.) Jc86035 (talk) 18:16, 17 June 2020 (UTC)

I've restored the change for now because MOS:FONTSIZE is a bright-line limit at 85% of the normal page font size and the reversion breaks that. I agree that all of the styling deserves a thorough review, but in the meantime, it's not acceptable to breach a clear accessibility guideline while we wait for future changes. --RexxS (talk) 21:11, 17 June 2020 (UTC)

Legend
Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text

Legend
Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text

Within each row, the text on the left does not have .RMsi or font-size:90% applied by the parent template, and the text on the right does. Jc86035 (talk) 18:25, 17 June 2020 (UTC)

All the text on the left remains above 85% of page font size. In each template, the text on the right contains two examples of text at less than 85% (between 78% and 82%). --RexxS (talk) 21:21, 17 June 2020 (UTC)

@RexxS: The primary problems with increasing the text size (both skin-dependent) are that the display of the images is visually broken if the height of the table exceeds 20px, and that the text tends to overlap if used in two consecutive rows due to the line height already being less than 1. My main concern at the moment would be {{BSto}}, since its display is dependent on the top text being clearly larger than the bottom text.

Possibly the text cells could be given pixel-based font sizes, matching the pixel-based row heights, but this could mean e.g. that the smallest text would only be MOS-compliant in the four skins which use smaller baseline font sizes.

Incidentally, it also might be better to use something else instead of the nested table, although I'm not sure if it would be possible to retain all of the features in doing so. Jc86035 (talk) 08:28, 18 June 2020 (UTC)

If I understand the above (did you mean "is smaller than 20px"?), 85%-sized or larger text causes a problem if it can't fit in a given box. If that is the case, the box might just have to be made a little larger. It also sounds like different skins have different base font sizes, which sounds like a fundamental design problem when other, skin-independent design elements are purely based on pixel sizes. Maybe the skins need to be harmonized. – Jonesey95 (talk) 13:35, 18 June 2020 (UTC)

@Jonesey95: The table I was referring to is the table generated by {{BSsplit}} or {{BSto}}. If the height of that table is greater than 20px, then the table cell that contains that table will be forced to have the same height, resulting in a gap between the images.

This is somewhat of a special case, since I don't think there are a lot of templates like this, but I think it could be helpful if the MOS were to reflect the disparity in default font sizes between skins. Jc86035 (talk) 16:21, 18 June 2020 (UTC)

@Jc86035: MOS:FONTSIZE states "Under no circumstances should the resulting font size of any text drop below 85% of the page's default font size (i.e. 11.9 px in Vector skin or 10.8 px in Monobook)." I think that's pretty clear about the pixel values in different skins. It should be apparent to anyone designing a template that if they want two lines of text to fit against an image, they are going to need more than 2 × 11.9px = 23.8px to accommodate them, and they should size their images appropriately. That's the bottom line. --RexxS (talk) 17:43, 18 June 2020 (UTC)

@RexxS: The way that the two lines are currently accommodated in {{BSsplit}} is through line-height:0.9 on the text and margin-top:-2px; margin-bottom:-2px on the table. The font sizes in {{BSsplit}} are already sufficient, so the main modifications needed would be CSS changes in Template:Routemap/styles.css to keep the font sizes consistent. For {{BSto}} the top text is about 14% larger than the bottom text, so either the relative difference could be maintained at the cost of overlapping adjacent lines of text, or the relative difference could be reduced as far as necessary to allow all of the text to fit properly. Most changes would at least initially result in negative visual impacts for {{BS-map}}, since it doesn't use TemplateStyles and possibly never will.

I would also note that the templates were both originally designed in 2011, at which time the relevant MOS page did not have any specific guidance about minimum font size at all. Jc86035 (talk) 17:58, 18 June 2020 (UTC)

@Jc86035: I already know the lines use reduced line-height; I worked on fixing these issues two years ago. Of course if you accept two lines of text overlapping, then you can have an image height of as little as 13px (Minerva), but the text would still be unreadable! We had this conversation at Template talk:Routemap/Archive 1 #Text size in May 2018. The issues are the same and the solution (increasing image height to 28px or 30px) remains the same. The MoS guidance was in use in 2018 and it was quoted in the last conversation. --RexxS (talk) 18:16, 18 June 2020 (UTC)

@RexxS: Given that {{BSsplit}} is currently MOS-compliant, would it really not be sufficient to only make design changes to {{BSto}} (or to phase it out, if a MOS-compliant design isn't feasible without essentially making it visually equivalent to {{BSsplit}})?

I'm not inherently opposed to a change from 20px to 28px or 32px, but I think I would err on the side of keeping display changes minimal unless there's consensus to do otherwise, especially since this template is used fairly widely and used on 40 other wikis (I've copied the module code directly several times over the years). Jc86035 (talk) 18:43, 18 June 2020 (UTC)

@Jc86035: I have no problems with any of the possible solutions, and I very much support the ambition to be able to use the same code on multiple wikis. My only concern is that we don't end up breaching a very clear limit on the smallest text that is displayed by any of the templates on enwiki, especially given that I thought we'd solved that issue years ago. --RexxS (talk) 20:00, 18 June 2020 (UTC)

@Jc86035 and RexxS: I support increasing the image size, and in fact see no real reason to oppose such a change. This template should follow the same rules as everywhere else on the encyclopedia. It would improve readability across the board, even when BSsplit and BSto are not a factor. --WMSR (talk) 23:30, 22 June 2020 (UTC)

Template:Wherry Lines - yes, that was the East Anglian one. --Redrose64 🌹 (talk) 20:55, 18 June 2020 (UTC)

There's a bunch of too-small text in that one as well. I'll take a look at the module code again, which will no doubt cause additional problems outside of the module. – Jonesey95 (talk) 21:11, 18 June 2020 (UTC)

(new subheader created for this fork). That template had a few <small>...</small> tags embedded in it, which were making text too small, as was formatting for {{BSto}} in the module. I have set BSto's size to "inherit", which may be a little bigger than necessary, but it is no longer too small. Comments, complaints, curses, and adjustments to the templatestyles document are welcome. – Jonesey95 (talk) 21:45, 18 June 2020 (UTC)

• Comment: Changing the icon display size from 20 to 28 or 32 pixels will probably introduce rendering issues and fuzziness to the diagrams. The svg code for icons specifies a height of 500, which is an exact multiple of their final display size. AlgaeGraphix (talk) 23:41, 21 June 2020 (UTC)
  • I seriously doubt that. SVGs are vector graphics and don't go fuzzy. Here are some examples:
    

    20px

    

    28px

    

    32px
    --RexxS (talk) 00:29, 22 June 2020 (UTC)

    @RexxS:  (INT) is really not a representative example, since it has two relatively simple objects whose dimensions are multiples of 100px.

    That being said, it probably wouldn't be appropriate to oppose the change without actual evidence that the display would be worse for some icons, and I'm guessing the issues would mostly be limited to images which use lines that are exactly 25px or 12.5px wide (which I don't think are that common).  (tSTR) and  (BL) both use 40px lines, and  (HUB) uses 20px lines, so the display could be slightly better for such icons at a higher resolution.

    Note that because the dimensions of images have to be integers, the height being a multiple of 4px is probably non-negotiable, since otherwise images like  (cdHSTq) (currently 15px wide) would not be resized correctly by MediaWiki. Jc86035 (talk) 23:54, 22 June 2020 (UTC)

    @Jc86035: if you think that any of the vector graphics used would "probably introduce rendering issues and fuzziness to the diagrams" when increased in height to 28px or 32px, please feel free to demonstrate with some examples. That would give us a chance to examine the extent of any real problems. I concur with your assertion that the height ought to be a multiple of 4px (and I think I concluded that the last time we looked at the issues). --RexxS (talk) 00:02, 23 June 2020 (UTC)

Hi! {{BSsplit}} is producing a slight error when used in the primary column of {{BS}}. This is demonstrated in the map below:

Example
Legend
First column Main column small main column text Trailing column It works fine in the first column But doesn't work in the main column The other text isn't as big so doesn't break And the final column doesn't break it either

Code:

{{BS-map
| title = Example
| float = center
| map =
{{BS|ENDEa|First column|Main column|small main column text|Trailing column}}
{{BS|STR|{{BSsplit|It works fine in|the first column}}|||}}
{{BS|STR||||}}
{{BS|STR||{{BSsplit|But doesn't work in|the main column}}||}}
{{BS|STR||||}}
{{BS|STR|||{{BSsplit|The other text|isn't as big so doesn't break}}|}}
{{BS|STR||||}}
{{BS|STR||||{{BSsplit|And the final column|doesn't break it either}}}}
{{BS|ENDE@F||||}}
}}

Thanks, WT79 ^{(speak to me | editing patterns | what I been doing)} 14:20, 17 July 2020 (UTC)

It looks OK to me (not pretty, but OK). What are you seeing, and what were you expecting? Is there a real page on which you are trying to make this work and it is not doing what you expect? – Jonesey95 (talk) 15:21, 17 July 2020 (UTC)

It's fine in Monobook, but in Vector, there's a break in the line level with the "But doesn't work ..." We established that 20px height for the images isn't enough, but that hasn't translated into practice. --RexxS (talk) 16:43, 17 July 2020 (UTC)

I'm using Vector and it looks fine. I don't know what "a break in the line level" means. Maybe a screen shot would help. – Jonesey95 (talk) 17:18, 17 July 2020 (UTC)

I just did some more testing - Vector on Chrome (83.0.4103.116 (Official Build) (64-bit)) is fine; Vector on Firefox (78.0.2 (64-bit)) shows the gap.

• url to test with: https://en.wikipedia.org/wiki/Template_talk:Routemap?useskin=vector#Template:BSsplit_not_working

Screenshot from Firefox looks like the above. --RexxS (talk) 17:45, 17 July 2020 (UTC)

I see the gap in the red line in the screen shot, but not in the template as rendered in my browser (Vector on Firefox 78 for Mac). It is probably somewhat dependent on your default font and font size. It looks like the red line segment needs to be made a bit longer. – Jonesey95 (talk) 19:04, 17 July 2020 (UTC)

It looks like {{BS}} calls {{BS-overlap}}, which asks for {{BSpx}} to set the default image size. So do we change {{BSpx}} from 20px to 21px to see what happens? It seems a little risky. I don't see an easy way to sandbox this quickly, but maybe it is easier than I think to add "/sandbox" to all of the necessary places. – Jonesey95 (talk) 19:15, 17 July 2020 (UTC)

The default image size probably needs to be more like 28px because anyone using Timeless skin has an even larger base font size. Check the following which shows gaps even on Chrome for me:

• https://en.wikipedia.org/wiki/Template_talk:Routemap?useskin=timeless#Template:BSsplit_not_working

Because the different images in use have different aspect ratios, we should be using image sizes that are a multiple of 4 to avoid non-integral calculated dimensions (which then produce distortion as the software rounds them to integers). I agree about the sandboxing, and I suggest you experiment at 24px for default image size first, as that would involve the smallest step-change in template size. Good luck! --RexxS (talk) 22:35, 17 July 2020 (UTC)

I see two one-pixel gaps with Timeless in Chrome for Mac and no gaps in Firefox for Mac, FWIW. I am taking a 24-hour wikibreak, but I will keep this page up in my browser and continue to think about a solution. It sure would be nice to tell the image to render at 100% of the cell's height. – Jonesey95 (talk) 22:39, 17 July 2020 (UTC)

Sorry, I have got a bit behind on my watchlist, somehow missed this.

I am using Firefox Version 78.0.2 (64-bit), vector skin, Windows 10. In case it might be of any use to anyone, all the information I know about my computer's type, etc., is:

Hope some of that might help. WT79 ^{(speak to me | editing patterns | what I been doing)} 07:32, 27 July 2020 (UTC)

how do i add an image next to my station?MetroManMelbourne (talk) 10:22, 25 September 2020 (UTC)

MetroManMelbourne, could you please clarify which page are you trying to edit? Which image are you trying to add? Wikilinks to these will be most helpful. —⁠andrybak (talk) 15:22, 25 September 2020 (UTC)

I would like to add the file File:Syd Trains logo.svg to Template:Western Sydney Airport line RDT at St Marys. MetroManMelbourne (talk) 03:14, 26 September 2020 (UTC)

@MetroManMelbourne: You realize that's a non-existent file you tried linking to, don't you? Did you mean File:Sydney Trains logo.svg? AlgaeGraphix (talk) 13:29, 27 September 2020 (UTC)

I tried linking to File:Syd Trains Logo.svg. MetroManMelbourne (talk) 23:25, 27 September 2020 (UTC)

Here's the code you need:

uextKINTa~~{{rwsA|St Marys|S}} [[File:Syd Trains Logo.svg|16px]]

AlgaeGraphix (talk) 10:29, 28 September 2020 (UTC)

I've created the following Template:Hogsmill River Map. If you go to the page and click on edit, it works fine. Click on the E(dit) icon on the template nav bar and it comes up blank. I've obviously done something stupid but can't work out what. Can some kind soul put me out of my misery? Murgatroyd49 (talk) 11:16, 28 September 2020 (UTC)

Murgatroyd49, fixed: Special:Diff/980782487. —⁠andrybak (talk) 12:25, 28 September 2020 (UTC)

Andrybak Many thanks, as a matter of interest, what had I screwed up? Murgatroyd49 (talk) 14:48, 28 September 2020 (UTC)

As per the diff provided, it was the wrong value in the |navbar= parameter - it must match the template name exactly, case-sensitive. --Redrose64 🌹 (talk) 16:47, 28 September 2020 (UTC)

Doh! looked at that several times but still got it wrong! thanks. Murgatroyd49 (talk) 17:25, 28 September 2020 (UTC)

Strictly speaking, it's a Route Diagram Template, not a map. AlgaeGraphix (talk) 18:45, 28 September 2020 (UTC)

I consider myself duly admonished. Murgatroyd49 (talk) 19:28, 28 September 2020 (UTC)

This edit request to Module:Routemap has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Jc86035: please add kilometres as an input option for {{BScvt}}. Also, it would be nice if proper comma formatting (0,000) was included for numbers greater than 999. Thank you. AlgaeGraphix (talk) 22:21, 25 August 2020 (UTC)

That template already accepts km as an input. See the second example in the table on the template's documentation page. – Jonesey95 (talk) 22:36, 25 August 2020 (UTC)

I don't know enough Lua to implement the second request, but there is a possibly useful example at http://lua-users.org/wiki/FormattingNumbers. – Jonesey95 (talk) 22:41, 25 August 2020 (UTC)

Disabled request. Once the necessary code has been written and tested, it may be reactivated. — Martin (MSGJ · talk) 14:25, 9 September 2020 (UTC)

@MSGJ: You are most unhelpful. If I was a Lua programmer, I wouldn't have to ask someone else to make the changes. AlgaeGraphix (talk) 03:19, 26 September 2020 (UTC)

AlgaeGraphix, what exactly are you trying to do? {{BScvt|1.40}} produces:

1.40 mi

2.25 km

(miles -> km). If you want km -> miles, {{BScvt|1.40|x}} produces

1.40 km

0.87 mi

(1.4 km -> miles). ProcrastinatingReader (talk) 00:32, 27 September 2020 (UTC)

@ProcrastinatingReader: I'd like to see proper formatting for numbers greater than 999, so that {{BScvt|1000}} produces

1,000 mi

1,609 km

instead of

1000 mi

1609 km

. AlgaeGraphix (talk) 12:39, 27 September 2020 (UTC)

Okay, I'll ping @Jc86035: to see if they can help, as the maintainer of this module. @Johnuniq: may also be able to help, as perhaps this module can just call the functions in Module:Convert to do this? You can also make a request at WT:LUA. Regular reviewers of TPERs are unlikely to be able to help further -- edit requests are generally used for 'code review' of already written changes in sandboxes, or for minor changes. ProcrastinatingReader (talk) 13:18, 27 September 2020 (UTC)

Options include Module:Formatnum or Module:Math#precision_format or Module:Gapnum or some Q&D code to handle small numbers (<= 999,999). I've been head-spinning over at Commons lately and don't have the energy to look at this at the moment but maybe later if needed. Any work would involve mucking around in the base function which is completely opaque and which should use a table to pass the optional parameters. I would not use convert—first of all, it was one of the first modules and does not provide access to its internals, and second, it is a lot of overhead for a comma. Johnuniq (talk) 05:04, 28 September 2020 (UTC)

@AlgaeGraphix, Jonesey95, MSGJ, ProcrastinatingReader, and Johnuniq: I've hacked the base function that deals with BScvt to use formatted numbers when the new parameter |numfmt= is set to comma (it just needed a local function to call the mw.language :formatNumber method). It seems to work for {{BScvt/sandbox}} but I'd recommend asking someone more familiar with routemapping to try it out with several edge-cases before thinking of implementing it in the main module.

• {{BScvt/sandbox|1000|numfmt=comma}} →

  1000 mi

  1609 km

Similarly, the functionality could be implemented in any of the other calls/templates that the module deals with, if there's a demand for it. Cheers --RexxS (talk) 15:32, 28 September 2020 (UTC)

Very good, I forgot about the mw formatNum. Johnuniq (talk) 01:53, 29 September 2020 (UTC)

Having {{rint}} and {{BSsplit}} on the left side of the route diagram breaks alignment on mobile view (works fine on Desktop). Example: {{rint|sanfrancisco|metro}}~~{{BSsplit|{{munis|Market and Main}} /|{{munis|Market and Drumm}}}}~~! !udINTACC\d\udHSTACC~~ ~~{{munis|The Embarcadero and Brannan}}

Legend
Market and Main / Market and Drumm The Embarcadero and Brannan

Not sure if this is fixable 132.147.87.52 (talk) 00:57, 27 June 2021 (UTC)

This looks fine to me in mobile view on Firefox for Mac OS. Can you post a screen shot? What app or browser are you using, on what OS? – Jonesey95 (talk) 14:42, 27 June 2021 (UTC)

Safari on iPhone iOS 14.6. How can I post a screenshot?132.147.87.52 (talk) 04:45, 28 June 2021 (UTC)

Link to screenshot: https://ibb.co/Bz8tj52 132.147.87.52 (talk) 05:04, 28 June 2021 (UTC)

Same (or similar) happens with Chrome on Android [text on LHS overlaps symbols]. --John Maynard Friedman (talk) 11:23, 28 June 2021 (UTC)

I can't tell what kind of bug that is, but I worked around it in a somewhat hacky way with |align=left. See the updated version of {{Muni Heritage}}. It's still not ideal. – Jonesey95 (talk) 15:30, 28 June 2021 (UTC)

Looks like it has nothing to do with {{rint}}. Any text on the left of {{BSsplit}} will break it: Text {{BSsplit|{{munis|Market and Main}} /|{{munis|Market and Drumm}}}}~~! !udINTACC\d\udHSTACC~~ ~~{{munis|The Embarcadero and Brannan}} 132.147.87.52 (talk) 00:45, 29 June 2021 (UTC)

Pinging JJMC89, Jc86035 & Sameboat who maintain the {{Routemap}} template & Lua module. AlgaeGraphix (talk) 00:49, 30 June 2021 (UTC)

Seems does not impact left side only. Same issue on the right side. Example code: d\\uextACC\\uextSTRc1\uextSTRl+4\uextSTRq\uxtKRZq2+4tu\uextINTACCq\uextdCONTfq~~ ~~ ~~{{SMRT color icon|te}}''{{BSto|[[Thomson–East Coast MRT line]]|to {{mrts|Gardens by the Bay}}}}''{{SMRT code|TE|20}} Screenshot: https://ibb.co/9vbCfLx 138.75.157.61 (talk) 13:18, 18 July 2021 (UTC)

align=left doesn't quite work either, though it is an improvement in that the words just overwrite the line rather than each other: see "to Oxford" at bottom left of {{Milton Keynes railway map}}. (Using Chrome on Android).--John Maynard Friedman (talk) 17:19, 18 July 2021 (UTC)

I have just given a new name for this template (when used with Routemap):

• Template:Routesplit
  
  

Let's see if it takes use or if it is better that the name remains as it is.
ZandDev (talk) 10:49, 1 September 2021 (UTC)

@ZandDev: What? This template is Routemap, why would you use it with itself? --Redrose64 🌹 (talk) 19:38, 1 September 2021 (UTC)

@Redrose64: Ops I refer to BSsplit template ZandDev (talk) 20:57, 1 September 2021 (UTC)

Document states: Position of the Navbar template. Float to left in the title bar by default; «1» for top-right corner of the map (just under the title bar); «2» for the middle bottom of the map. However for «1», it's appearing on the top-left instead of right. Is the doc wrong, or is that a bug? 2401:7400:C80B:E643:3438:40F6:CECE:CCD5 (talk) 05:06, 1 March 2023 (UTC)

The documentation does not explain how to use this parameter, and the Template Data section is written confusingly. What you want is |navbar pos=1 for upper-right placement or |navbar pos=2 for lower-middle placement. See Template:Routemap#Embedding_into_infobox for a lower-middle example. – Jonesey95 (talk) 06:01, 1 March 2023 (UTC)

That's exactly what I meant. |navbar pos=1 Places it on the upper-left instead of upper-right. See Changi Airport Skytrain infobox as an example. 112.199.236.152 (talk) 10:32, 1 March 2023 (UTC)

Hmm. It looks like the Template Data description is not just poorly formatted, but wrong. As far as I can tell, the default is "no navbar", |navbar pos=1 places the navbar on the upper left, and |navbar pos=2 places the navbar at the bottom middle. Someone more familiar with Lua may be able to determine if there are other options. – Jonesey95 (talk) 17:27, 1 March 2023 (UTC)

The default puts the navbar within the title bar on the left (so it doesn't appear when used inline). I was trying understand if pos=1 was meant to be (1) top-right, and there's a bug in the Lua code; or (2) top-left, and it's an error in the documentation. 2401:7400:C80B:E643:A5B7:CD1B:E56A:2691 (talk) 00:59, 2 March 2023 (UTC)

If there is a non-blank |navbar= and |navbar pos= is blank or absent, you get the navbar in the title bar, at the left, as small capitals enclosed in square brackets. When |navbar pos=1 you get the navbar floated at top left below the title bar, as small capitals not enclosed in square brackets; it shares a row with the "Legend" link. When |navbar pos=2 you get the navbar in a row of its own centred at the bottom, as text reading "This diagram: view - talk - edit". Any other values for |navbar pos= will suppress the navbar, even if |navbar= is specified and valid. --Redrose64 🌹 (talk) 09:10, 2 March 2023 (UTC)

Thanks for confirming it's WAI. I've updated the documentation to reflect that. 112.199.236.152 (talk) 23:46, 2 March 2023 (UTC)

Please see {{Suez Canal map}}. In the third row, there is text "W" and "E" (for West and East entrance). The "W" is half hidden under the following icon. Can someone move that letter to the left to make it visible? Or, if necessary, completely to the right of its following icon. Thanks. -DePiep (talk)