Template talk:Ratio

Spaces surrounding the ratio colon

MOS:RATIO apparently requires spaces around the colon in (aspect) ratios, but assumes U+003A Colon instead of the proper U+2236 Ratio. In order to make this template conformant, I added thin spaces yesterday, which was reverted soon thereafter. The sandbox still contains that code.

@Deacon Vorbis: Why do you think that "invisible unicode characters [...] is a problem"? Different whitespace characters are there for a reason. We could discuss (here or on MOS) which one should be used, though:

• ] ∶ [ U+2007 Figure Space   – much too wide, 1ch ≈ 1⁄2em
• ] ∶ [ U+2002 En Space   – much too wide, 1en ≈ 1⁄2em
• ] ∶ [ U+2005 Four-per-Em Space   1⁄4em
• ] ∶ [ U+00A0 Non-Breaking Space   – too wide, no fixed width: may grow wider
• ] ∶ [ U+205F Medium Mathematical Space   2⁄9em
• ] ∶ [ U+2008 Punctuation Space   – often same width as the colon itself
• ] ∶ [ U+202F Narrow No-Break Space – semantically optimal, too wide in some fonts
• ] ∶ [ U+2009 Thin Space   1⁄6em through 1⁄5em
• ] ∶ [ U+2006 Six-per-Em Space 1⁄6em
• ] ∶ [ U+200A Hair Space   – ideal width in my opinion, c. 1⁄8em
• ]∶[ none, compare to colon:
• ]:[

Also, what exactly are the "more serious problems with the way this template is implemented" that you see? — Christoph Päper 08:35, 22 November 2019 (UTC)

It appears that spaces are only required when a decimal point is present. From the linked page:

Dimensionless ratios (i.e. those without accompanying units) are given by placing a colon between integers, or placing to between numbers-as-words: favored by a 3:1 ratio or a three-to-one ratio, not a 3/1 ratio or a 3–1 ratio.

Use a colon (spaced) when one or more decimal points is present (a 3.5 : 1 ratio – markup: a 3.5 : 1 ratio).

I think this applies fairly rarely, as from what I've seen, most ratios are given either as the furthest reduced integers, or written in decimal form in comparison to 1 and the denominator of the ratio (the ":1") is simply omitted (i.e. 2.40 aspect ratio). In the few cases where this applies, it's technically still possible to add spaces with this template as required by simply including them in the input argument: {{ratio|21.5 | 9}}: 21.5 ∶ 9. Or alternatively, written exactly as the example in the MOS except replacing the colon with {{ratio}}, which is originally how this template was intended to be used anyway. In any case, I'm not too bothered about putting in automatic detection for it given how unusual it is, and that it can be done by the user if they want to. It is best in my opinion to keep the usage and behavior simple and consistent and not overcomplicate things if possible. However, if we were to implement detection for decimal points and add spaces, I will point out one potential problem, which is that the spaces must be of the non-breaking type. From what I can tell you used thin spaces (U+2009) in your edit, which do break on lines. And even when non-breaking spaces are used, they won't work when the template is placed between two numbers outside. For example if I type 16{{ratio}}9 and ratio substitutes for  &#x2239 , it can still line break on the spaces anyway, which is unfortunate. So spaces really create a whole host of issues. If we were to make a change, I think the best thing to do would simply add the CSS tag for white-space:nowrap around the whole template, that way it won't change the operation or output of the template in any way, but if someone wants spaces they can just include normal spaces in the argument instead of typing  , which would be a nice convenience.

I suppose one could also argue that this entire template doesn't comply with the MOS no matter what we decide, since the MOS clearly states to use a colon, and the U+2239 character is technically not a colon :P GlenwingKyros (talk) 09:53, 22 November 2019 (UTC)

The original point is that it's impossible to see the spaces in the editor (or if god forbid, someone substs this). If you have to use things like thin spaces, then they should be entered with either a template ({{thinsp}}), or the HTML entity ( ). That being said, there are some other problems with this. First, I don't think it should be using the unicode ratio symbol. A normal colon is pretty standard and runs no risk of not being supported on any platform. Second, trying to detect colons already in the input rather than requiring the input be as separate parameters is kind of questionable. I also don't think this should be providing default behavior of a plain colon or a ":1" afterwards; if someone wants that, then enter it. The best justification for even having this template would seem to be not having to worry about spacing, which the MOS is sort of quirky about. But to do that right would require some extra tinkering. I'm going to have a think on this for a bit and see if anything else comes to mind. Oh, and if you want to support more than 2 values, it's worth deciding whether there should be a max (of say, 3), or if you just want to allow an arbitrary number, in which case, doing this all in Lua might be the best option (which already might be for the spacing stuff). –Deacon Vorbis (carbon • videos) 15:24, 22 November 2019 (UTC)

Well, the original intention was to have a way of typing the unicode ratio character, since it doesn't have a named entity to type it easily, so the only other option is generally to copy paste it from somewhere. Standard colon can be easily typed so I don't think there's any point in having a template at all if it's going to use that. Personally I think the ratio character looks better since it's more centered rather than resting on the baseline. The intent of detecting colons was to make it slightly more convenient/easy to just wrap the template tags around existing text to convert it to template without needing to replacing the colon with a pipe; since I edit on phone a lot it makes things more convenient. But I admit it's a pretty oddball function :P I'm not too keen on the automatic :1 either, I think someone else added that. Anyway, I'm obviously kind a noob when it comes to template creation though so I appreciate the feedback. GlenwingKyros (talk) 19:10, 22 November 2019 (UTC)

FWIW, the sandbox now defaults to NNBSP and detects floating numbers (by presence of a dot .), but perhaps it should really check for integers. The /testcases show that it is pretty much in line with MOS. — Christoph Päper 00:25, 23 November 2019 (UTC)