Template talk:Fraction/Archive 2

New style
To address usability and style concerns raised above I suggest to change the template a little bit.

Current :

Sample:, ,

Proposal with thin space U+2009
Sample: 1 2⁄3 , 2⁄3, 1⁄3

We could include precomposed vulgar fractions, 1/, 1/2, 1/4, 3/4, 1/3, 2/3, 1/5, 2/5, 3/5, 4/5, 1/6, 5/6, 1/8, 3/8, 5/8, 7/8, as suggested in the deletion nomination discussion, but I’m not convinced yet. I’m also not convinced that removing the ‘sup’ and ‘sub’ elements does give the best result for everyone/anyone. — Christoph Päper 08:15, 21 June 2010 (UTC) (Code altered later slightly.)


 * For reference, the table below gives details of the above characters as well as of the percent sign and its derivatives and of the various types of solidus/slash:
 * {|class="wikitable"

!Unicode||Character||Decomposition||Unicode description
 * U+0025||align="center"|%||align="center"|0/0||PERCENT SIGN
 * U+002F||align="center"|/||align="center"|/||SOLIDUS
 * U+00BC||align="center"|¼||align="center"|1/4||VULGAR FRACTION ONE QUARTER
 * U+00BD||align="center"|½||align="center"|1/2||VULGAR FRACTION ONE HALF
 * U+00BE||align="center"|¾||align="center"|3/4||VULGAR FRACTION THREE QUARTERS
 * U+0337||align="center"| ̷||align="center"|/||COMBINING SHORT SOLIDUS OVERLAY
 * U+0338||align="center"| ̸||align="center"|/||COMBINING LONG SOLIDUS OVERLAY
 * U+2030||align="center"|‰||align="center"|0/00||PER MILLE SIGN
 * U+2031||align="center"|‱||align="center"|0/000||PER TEN THOUSAND SIGN
 * U+2044||align="center"|⁄||align="center"|/||FRACTION SLASH
 * U+2153||align="center"|⅓||align="center"|1/3||VULGAR FRACTION ONE THIRD
 * U+2154||align="center"|⅔||align="center"|2/3||VULGAR FRACTION TWO THIRDS
 * U+2155||align="center"|⅕||align="center"|1/5||VULGAR FRACTION ONE FIFTH
 * U+2156||align="center"|⅖||align="center"|2/5||VULGAR FRACTION TWO FIFTHS
 * U+2157||align="center"|⅗||align="center"|3/5||VULGAR FRACTION THREE FIFTHS
 * U+2158||align="center"|⅘||align="center"|4/5||VULGAR FRACTION FOUR FIFTHS
 * U+2159||align="center"|⅙||align="center"|1/6||VULGAR FRACTION ONE SIXTH
 * U+215A||align="center"|⅚||align="center"|5/6||VULGAR FRACTION FIVE SIXTHS
 * U+215B||align="center"|⅛||align="center"|1/8||VULGAR FRACTION ONE EIGHTH
 * U+215C||align="center"|⅜||align="center"|3/8||VULGAR FRACTION THREE EIGHTHS
 * U+215D||align="center"|⅝||align="center"|5/8||VULGAR FRACTION FIVE EIGHTHS
 * U+215E||align="center"|⅞||align="center"|7/8||VULGAR FRACTION SEVEN EIGHTHS
 * U+215F||align="center"|⅟||align="center"|1/||FRACTION NUMERATOR ONE
 * U+2215||align="center"|∕||align="center"|/||DIVISION SLASH
 * }
 * To clarify from the original discussion:
 * Are  and   both widely implemented in browsers? Might older browsers choke on a thinspace character?
 * Would speech-readers be adversely affected by the loss of the hidden "+" from mixed numbers?
 * I think the template should not produce precomposed fractions, or at least not unless the editor supplies a parameter to override the uniform format, because this could cause unwanted inconsistencies in nearby fractions. It is also likely to cause font problems for the more obscure characters. For example, editors writing "1/2" near to "1/7" might well want them to be formatted the same. If they wanted "½", they could enter the character directly, or perhaps call this template with something such as true.
 * — Richardguk (talk) 10:10, 21 June 2010 (UTC)
 * U+0337–8 are not applicable here, they’re for making ø and such.
 * Do people use frac for per-X signs? I never thought of that, but it would be reasonably easy to add.
 * Older IEs display thin space as a very wide space, but at least as a space.
 * The fraction slash is well supported in that it looks like a normal slash if the font does not provide a glyph, but browsers don’t do smart font rendering yet. (I assume the next major versions of Firefox and Safari will have at least experimental support for enabling Open Type features through CSS3.) Smart fonts, though, will probably also work with the normal slash for this. So it shouldn’t do harm and after all it is currently being used by this template.
 * Speech browsers don’t benefit from the hidden plus at all, neither do console browsers. It was a mediocre idea of mine, at best.
 * I’m not sure I like a  parameter – or a more general   which could do &lt;math&gt; output too – better than a separate template. I agree, though, that we shouldn’t use precomposed glyphs by default. By the way, in vulgar mode you would display ½ for, whereas normal frac does and should keep the numbers.  — Christoph Päper 16:42, 21 June 2010 (UTC)
 * Given your reassurance about browser compatibility and accessibility, your revised code above sounds like a good improvement, and there is no pressing need for precomposed fractions (or for elimination of common factors, which would be a lot of work for little benefit I suspect!).
 * I tried to make my table as comprehensive as possible, but you are right that the template is very unlikely to be used to create percentage-related signs; and if they tried, the template would easily handle  etc.
 * — Richardguk (talk) 17:21, 21 June 2010 (UTC)
 * I’ve been bold and changed the redirect template fraction to use precomposed glyphs (and no ). frac should remain free of them.
 * PerXage signs turned out to be more difficult than expected, so I left them out. — Christoph Päper 23:11, 21 June 2010 (UTC)
 * Since nobody commented or protested for 10 days, I’m asking again to replace the template code with my proposal at the start of this section. It simplifies things a bit and makes it more robust, thereby increasing accessibility. The optical change is basically non-existant with most Mediawiki skins. — Christoph Päper 09:12, 2 July 2010 (UTC)
 * I've applied your requested edit to the /sandbox and made a couple of tweaks including removing an extra /span. Can you make sure that is okay? &mdash; Martin (MSGJ · talk) 09:43, 2 July 2010 (UTC)
 * Oppose thinsp; it isn't rendered in many browsers, for whatever reason. Suggest &nbsp with a negative margin to move it back, similar to the postive margin used in val subfunctions.  Strongly oppose Unicode subscripts and superscripts.  No comment on fracsl; it seems to work for me, but I haven't confirmed it works in all browsers.  — Arthur Rubin  (talk) 01:46, 3 July 2010 (UTC)
 * Thin space is rendered in all browsers that I tested as a space (not necessarily a thin one, though). Which browsers and what kind of “isn’t rendered” do you mean? The correct character should be more robust than CSS hackery, eg. in copy and paste. The fraction slash has been used in this template for years, just not using the named character entity reference. — Christoph Päper 22:18, 4 July 2010 (UTC)
 * I assume you mean code like this:  (1.234 × 105). That’s abusing CSS and fails where it is not available, whereas space characters from Unicode should work everywhere (and do work good enough). — Christoph Päper 17:50, 10 July 2010 (UTC)
 * thinsp; appears as a box for me (Opera 10.60, Windows XP). Firefox renders it as a full space, usually, and Safari seems to work correctly.  — Arthur Rubin  (talk) 08:32, 11 July 2010 (UTC)
 * Is that Opera issue related to the named character entity reference or does it work now that I’ve used a numeric reference (or simply UTF-8)? Anyhow, few people use frac with three arguments (or one), but live with manual full (non-breaking) spaces instead, so Firefox and older IEs are not a problem as mentioned earlier. Note that some similar templates on enWP and elsewhere are using thin space without people complaining. For what it’s worth, copy-pasting current to ‘12/3’ is hardly better than displaying it as ‘1⌷2/3’.  — Christoph Päper 07:34, 13 July 2010 (UTC)
 * No noticeable difference between & thinsp; and the Unicode character, although, oddly enough the unicode character just above (⌷) displays as a thin light gray tall box. — Arthur Rubin  (talk) 07:51, 13 July 2010 (UTC)
 * I'm concerned about Arthur Rubin's oppose. Re-post when there's a clear consensus. TFOWR 09:35, 3 July 2010 (UTC)
 * @Crissov and @Arthur_Rubin: Given that some browsers do not support &thinsp; (or its equivalents &#x2009; and &#8201;), how about simply having a superscript between the integer and superscript numerator? The superscripting would reduce the width. That has the advantage of being simple and unlike &thinsp;  it would not wrap.
 * A typical ordinary space is 1/4em and thinspace has a standard width of 1/5em (or 1/8em in French typesetting, or 1/6em in MathML). Superscript text has a standard size of 83% = 5/6em so typically a superscript non-breaking space has the relative width of 83% × 1/4 ÷ 1/5 = 104% compared to a thin space space, a close approximation but without the compatibility problems.
 * Thus:
 * test 1&thinsp;2&frasl;3 (1&thinsp;2&frasl;3, existing version for comparison)
 * test 12&frasl;3 (12&frasl;3, three parameters with superscript NBSP)
 * test 1&frasl;2 (1&frasl;2, two parameters)
 * test 1 (1, one parameter)
 * — Richardguk (talk) 09:38, 13 July 2010 (UTC)
 * I really prefer to do the spacing on the character level, but since that doesn’t seem to work out we could settle on your suggestion or we use negative.
 * no space: 12⁄3 ,
 * and normal space, $0/00$em - $1/undefined$em => -0.05em: 1 2⁄3 ,$1/undefined$em - $1/undefined$em =$1/undefined$em => -0.083em: 1 2⁄3, $1/undefined$em - $1/undefined$em =$1/undefined$em => -0.125em: 1 2⁄3 ,
 * non-breaking space, -0.05em: 1 2⁄3, -0.1em: 1 2⁄3 , -0.15em: 1 2⁄3 , -0.2em: 1 2⁄3 , -0.25em: 1 2⁄3 , -0.3em: 1 2⁄3 , -0.4em: 1 2⁄3 , -0.5em: 1 2⁄3.
 * This is, at least, a cleaner solution than negative margins. It should be done in common.css for  or , not in the template itself. — Christoph Päper 09:38, 15 July 2010 (UTC)
 * Could you clarify your reasons for preferring this to using a superscript non-breaking space character, as proposed above? Doesn't undefined achieve the desired visual effect, without any semantic impairment and with more widely-implemented code? Conversely, since the width of a space in ems varies from one typeface to another, isn't an em-spacing adjustment inappropriate? — Richardguk (talk) 12:37, 15 July 2010 (UTC)
 * I’m not preferring  over moving the space into the superscript (nor vice versa), I just added it for completeness. Your solution has the benefit of being the simplest, i.e. there’s no special CSS involved, and most backward compatible. We will have to do something else if we some day decide to remove the ‘sup’ and ‘sub’ elements. For now, let’s do it your way. — Christoph Päper 08:46, 16 July 2010 (UTC)
 * Since nobody commented or protested for 10 days, I’m asking again to replace the template code with my proposal at the start of this section. It simplifies things a bit and makes it more robust, thereby increasing accessibility. The optical change is basically non-existant with most Mediawiki skins. — Christoph Päper 09:12, 2 July 2010 (UTC)
 * I've applied your requested edit to the /sandbox and made a couple of tweaks including removing an extra /span. Can you make sure that is okay? &mdash; Martin (MSGJ · talk) 09:43, 2 July 2010 (UTC)
 * Oppose thinsp; it isn't rendered in many browsers, for whatever reason. Suggest &nbsp with a negative margin to move it back, similar to the postive margin used in val subfunctions.  Strongly oppose Unicode subscripts and superscripts.  No comment on fracsl; it seems to work for me, but I haven't confirmed it works in all browsers.  — Arthur Rubin  (talk) 01:46, 3 July 2010 (UTC)
 * Thin space is rendered in all browsers that I tested as a space (not necessarily a thin one, though). Which browsers and what kind of “isn’t rendered” do you mean? The correct character should be more robust than CSS hackery, eg. in copy and paste. The fraction slash has been used in this template for years, just not using the named character entity reference. — Christoph Päper 22:18, 4 July 2010 (UTC)
 * I assume you mean code like this:  (1.234 × 105). That’s abusing CSS and fails where it is not available, whereas space characters from Unicode should work everywhere (and do work good enough). — Christoph Päper 17:50, 10 July 2010 (UTC)
 * thinsp; appears as a box for me (Opera 10.60, Windows XP). Firefox renders it as a full space, usually, and Safari seems to work correctly.  — Arthur Rubin  (talk) 08:32, 11 July 2010 (UTC)
 * Is that Opera issue related to the named character entity reference or does it work now that I’ve used a numeric reference (or simply UTF-8)? Anyhow, few people use frac with three arguments (or one), but live with manual full (non-breaking) spaces instead, so Firefox and older IEs are not a problem as mentioned earlier. Note that some similar templates on enWP and elsewhere are using thin space without people complaining. For what it’s worth, copy-pasting current to ‘12/3’ is hardly better than displaying it as ‘1⌷2/3’.  — Christoph Päper 07:34, 13 July 2010 (UTC)
 * No noticeable difference between & thinsp; and the Unicode character, although, oddly enough the unicode character just above (⌷) displays as a thin light gray tall box. — Arthur Rubin  (talk) 07:51, 13 July 2010 (UTC)
 * I'm concerned about Arthur Rubin's oppose. Re-post when there's a clear consensus. TFOWR 09:35, 3 July 2010 (UTC)
 * @Crissov and @Arthur_Rubin: Given that some browsers do not support &thinsp; (or its equivalents &#x2009; and &#8201;), how about simply having a superscript between the integer and superscript numerator? The superscripting would reduce the width. That has the advantage of being simple and unlike &thinsp;  it would not wrap.
 * A typical ordinary space is 1/4em and thinspace has a standard width of 1/5em (or 1/8em in French typesetting, or 1/6em in MathML). Superscript text has a standard size of 83% = 5/6em so typically a superscript non-breaking space has the relative width of 83% × 1/4 ÷ 1/5 = 104% compared to a thin space space, a close approximation but without the compatibility problems.
 * Thus:
 * test 1&thinsp;2&frasl;3 (1&thinsp;2&frasl;3, existing version for comparison)
 * test 12&frasl;3 (12&frasl;3, three parameters with superscript NBSP)
 * test 1&frasl;2 (1&frasl;2, two parameters)
 * test 1 (1, one parameter)
 * — Richardguk (talk) 09:38, 13 July 2010 (UTC)
 * I really prefer to do the spacing on the character level, but since that doesn’t seem to work out we could settle on your suggestion or we use negative.
 * no space: 12⁄3 ,
 * and normal space, $1/undefined$em - $1⁄2$em => -0.05em: 1 2⁄3 ,$1/2$em - $1⁄2$em =$24 1⁄2$em => -0.083em: 1 2⁄3, $1⁄2$em - $1⁄2$em =$24 1⁄2$em => -0.125em: 1 2⁄3 ,
 * non-breaking space, -0.05em: 1 2⁄3, -0.1em: 1 2⁄3 , -0.15em: 1 2⁄3 , -0.2em: 1 2⁄3 , -0.25em: 1 2⁄3 , -0.3em: 1 2⁄3 , -0.4em: 1 2⁄3 , -0.5em: 1 2⁄3.
 * This is, at least, a cleaner solution than negative margins. It should be done in common.css for  or , not in the template itself. — Christoph Päper 09:38, 15 July 2010 (UTC)
 * Could you clarify your reasons for preferring this to using a superscript non-breaking space character, as proposed above? Doesn't undefined achieve the desired visual effect, without any semantic impairment and with more widely-implemented code? Conversely, since the width of a space in ems varies from one typeface to another, isn't an em-spacing adjustment inappropriate? — Richardguk (talk) 12:37, 15 July 2010 (UTC)
 * I’m not preferring  over moving the space into the superscript (nor vice versa), I just added it for completeness. Your solution has the benefit of being the simplest, i.e. there’s no special CSS involved, and most backward compatible. We will have to do something else if we some day decide to remove the ‘sup’ and ‘sub’ elements. For now, let’s do it your way. — Christoph Päper 08:46, 16 July 2010 (UTC)

Proposal with superscript non-breaking space
Sample: 12⁄3 , 2⁄3, 1⁄3 — Christoph Päper 08:46, 16 July 2010 (UTC)
 * Does this proposal have consensus? TFOWR 08:54, 16 July 2010 (UTC)
 * Change has been thoroughly discussed so I've implemented. &mdash; Martin (MSGJ · talk) 09:39, 16 July 2010 (UTC)
 * The issue with no-break space as I see it is justification. Between the integer and the fraction, a narrow no-break space U+202F would keep always the same width while not being too large by default neither. This space character has become quite common. -- Hnvnc (talk) 17:06, 18 January 2017 (UTC)

Problem
If you look at the "vert jump" part of the table here it only displays "1⁄2 in" but in the source code it is written out as "| vertical = 24{fraction|1|2}". This previosly made the table display the proper "24 1⁄2 in" but I had to change the source code to "| vertical = {fraction|24|1|2}" to make it display properly. Anyone know how this was changed. It could affect a decent amount of articles. WikiOriginal-9 (talk) 09:29, 28 December 2017 (UTC)
 * The issue is that Tom Brady uses NFL predraft which does some clever things to use convert to provide metric conversions. For some reason it is failing with . DePiep could work out what is going on. The before-and-after wikitext from the article follows, with the first "Vert jump" currently showing $24 1⁄2$ in:


 * Johnuniq (talk) 10:01, 28 December 2017 (UTC)
 * I don't think that is necessarily the problem, nor even its direct subtemplates such as  or . It uses Module:Convert/helper, and it seems that the module cannot handle the integer part if it's outside the :
 * The module documentation implies that either form is valid. You could ask at Template talk:Convert, that being the centralised talk page for this module set. -- Red rose64 &#x1f339; (talk) 10:42, 28 December 2017 (UTC)
 * As Redrose says: input  is not treated right, numerically, by Convert/helper. 2400 transclusions of  potentially affected. I have no indication of usage in other templates (convert/helper is quite recent). See convert. -DePiep (talk) 10:51, 28 December 2017 (UTC)
 * Got it. This line  in Module:Convert/helper can't handle  by . The  template emits a bare Unicode Character 'ZERO WIDTH SPACE' (U+200B) whereas  emits   the   character being identical to Unicode Character 'HAIR SPACE' (U+200A). It's the lack of a span that causes it. -- Red rose64 &#x1f339; (talk) 10:59, 28 December 2017 (UTC)
 * Right, the fix it might be a simple change to Template:Frac :
 * Anybody foresee any problems with that, or should we revert Jc86035's edit? -- Red rose64 &#x1f339; (talk) 11:11, 28 December 2017 (UTC)
 * (ec) OK, better even. I did not see it was a edit. Since /helper is maintained from, I opened Template _talk:Convert. - DePiep (talk) 11:12, 28 December 2017 (UTC)
 * re Redrose: in general, convert/helper should follow, not the other way around. So unless Jc86035's edit by itself is incorrect, any change should be made in module:Convert/helper. Maybe it is best to wait for to reply. -DePiep (talk) 11:16, 28 December 2017 (UTC)
 * Thanks for the analysis. I fixed the regex so it works with the zwsp edit, or without. In other words, it shouldn't matter if Jc86035's edit is reverted or not. I put some crude tests at Module talk:Convert/helper. Johnuniq (talk) 04:28, 29 December 2017 (UTC)
 * Anybody foresee any problems with that, or should we revert Jc86035's edit? -- Red rose64 &#x1f339; (talk) 11:11, 28 December 2017 (UTC)
 * (ec) OK, better even. I did not see it was a edit. Since /helper is maintained from, I opened Template _talk:Convert. - DePiep (talk) 11:12, 28 December 2017 (UTC)
 * re Redrose: in general, convert/helper should follow, not the other way around. So unless Jc86035's edit by itself is incorrect, any change should be made in module:Convert/helper. Maybe it is best to wait for to reply. -DePiep (talk) 11:16, 28 December 2017 (UTC)
 * Thanks for the analysis. I fixed the regex so it works with the zwsp edit, or without. In other words, it shouldn't matter if Jc86035's edit is reverted or not. I put some crude tests at Module talk:Convert/helper. Johnuniq (talk) 04:28, 29 December 2017 (UTC)


 * Thanks for your help guys. WikiOriginal-9 (talk) 04:36, 29 December 2017 (UTC)

No solidus
Why doesn't this have a slash or solidus between the numbers? It looks like just a superscript and subscript: https://i.imgur.com/yRxo70z.png 71.167.61.115 (talk) 22:13, 16 April 2017 (UTC)
 * I don't know. Which article is it in? -- Red rose64 &#x1f339; (talk) 19:02, 17 April 2017 (UTC)
 * The Direct Stream Digital article. Works fine for me though. — Preceding unsigned comment added by 99.123.188.73 (talk) 05:49, 9 November 2018 (UTC)

Template Sfrac messed up on m.wikipedia on Ps4 Pro browser.
I'm using the Ps4 Pro's built-in browser to read wp articles on my TV (Yes, I realize how nerdy this is.) and for some reason wikipedia decides that I should be given the mobile UI (en.m.wikipedia.org) by default. I'm just reading the article on typographic points and there's a section of that uses the Sfrac template over and over, but the browser displays it wrong. If I switch to the desktop UI the problem goes away. Perhaps someone could figure out a workaround for this browser/UI combo & code it into this template? — Preceding unsigned comment added by 99.123.188.73 (talk) 06:04, 9 November 2018 (UTC)

Integrity
Following above, see this:


 * A: $1⁄2$


 * B: 24$24 1/2$

Returns


 * A: $1/2$


 * B: 24$24 1/2$

Doing copy/paste:

A: ​24 1⁄2

B: 24​1⁄2

In expanded code:
 * A: &amp;#x200B; 24 1&frasl;2


 * B: 24&amp;#x200B; 1&frasl;2

Clearly, the copy/paste check fails in B. It produces a different number!

Also, the expanded code differs. Understandably for the "24" (integer) text, but also for the classes used. May I expect more similar code? -DePiep (talk) 12:58, 28 December 2017 (UTC)
 * The above are ok. Using Special:ExpandTemplates gives these results:

$1/2$ &amp;#x200B; 24 &amp;nbsp; 1&amp;frasl;2

24$24 1/2$ 24&amp;#x200B; 1&amp;frasl;2
 * The difference is that when 24 is included in the template, the output includes the following:
 * where the span is not visible, but is copied as a space if Ctrl+C is used.
 * I don't think there is anything the template can do differently. Johnuniq (talk) 04:05, 29 December 2017 (UTC)
 * Agree. Maybe advise, per documentation, to always include the integer into the template? That's because of the side effects only. Line-breaking might be affected too. (I have fixed the expanded code I provided, now showing &amp; characters). -DePiep (talk) 11:35, 29 December 2017 (UTC)
 * In fact, there is something the template could do differently: semantically, there should be a plus sign between the integer and the fraction. There are two ways to encode it:  or . Both have been discussed here several years ago. As far as I remember without searching through the archives, we decided against them because of missing font support and problems with copy-pasting. The technical constraints might have changed in the meantime, so it may be sound to reconsider. — Christoph Päper 10:16, 6 September 2019 (UTC)
 * PS: That brief discussion about U+2064 took place in late 2011. — Christoph Päper 11:24, 19 September 2019 (UTC)
 * PS: That brief discussion about U+2064 took place in late 2011. — Christoph Päper 11:24, 19 September 2019 (UTC)

Google crawling
When Google crawls Wikipedia and display the first couple of lines of a page, they do not render the sfrac template properly. For example, Google "Integer" and you may come across the line "For example, 21, 4, 0, and −2048 are integers, while 9.75, 5+, and √2 are not". Can this be fixed, or it is just Google's fault? Benica11 (talk) 01:27, 20 November 2020 (UTC)
 * A better place to ask this would be at WP:VPT. You might link Integer to show the fraction. Johnuniq (talk) 02:33, 20 November 2020 (UTC)

zwsp and Remex
Do you know if the zwsp is removable now? I don't know what case you were worried about. :) --Izno (talk) 04:43, 3 December 2020 (UTC)
 * Reviewing the page history, I think my edit was supposed to be an improvement over 's 2016 addition, which seems to have been something related to the pre-RemexHtml automatic fixes, which are no longer a concern. I don't remember anything about my edit, but maybe Fram remembers why the space was added. Jc86035 (talk) 20:46, 3 December 2020 (UTC)
 * At the time, when you got e.g. 2 1/4, the template not only reduced the size of the"1/4", but also of the preceding "2". This was obviously unwanted, and solved by my edit (yay!). If it is no longer necessary, then feel free to remove it of course. Fram (talk) 08:04, 4 December 2020 (UTC)
 * Ah, Tidy was helpfully putting things where they didn't belong. Let me take a look. --Izno (talk) 05:48, 12 December 2020 (UTC)

visualhide removal
This template/module uses the visualhide class. It has a TemplateStyles solution and will accordingly be removed from Common.css soon. Your feedback regarding the timeline is requested at. Izno (talk) 17:10, 2 December 2020 (UTC)
 * Reviewers of this section may also be interested in the discussion occurring at Template talk:Convert. --Izno (talk) 03:42, 15 December 2020 (UTC)

Templatestyles and citation templates
Hi, what is the fix for [//en.wikipedia.org/w/index.php?search=templatestyles&title=Special:Search&go=Go&ns0=1 these]? Most seem to have popped up when this template was changed over to templatestyles last month. Thanks! Plastikspork ―Œ (talk) 22:17, 8 January 2021 (UTC)
 * Cute. The template should never have been used in citation templates in the first place. I would personally recommend   as a replacement, or to use &lt;math>, which is also supported from memory. --Izno (talk) 22:19, 8 January 2021 (UTC)

Strange rendering bug in sfrac
The last few edits to Dirac equation were trying to work around a rendering bug in sfrac. It's rather strange. If the first usage of sfrac is inside a piped link, like $1/2$, then the bug is triggered and all further occurrences of $1⁄2$ are also borked. However, if the first usage is a regular one, then putting it in a piped link afterwards doesn't cause any problems.

Here is how it looks like with the bug triggered: $1⁄2$ $1⁄2$ $1⁄2$ $1⁄2$.

I hope somebody here can fix it. Tercer (talk) 17:10, 20 December 2020 (UTC)

EDIT: lol, the bug is triggered in the preview, but it is gone when I actually save the page. To see it in action then just edit this section and click preview, or take a look at this old version of Dirac equation. Tercer (talk) 17:15, 20 December 2020 (UTC)
 * Great, and  need something to work on! Looking at the HTML source when previewing shows that the piped link damages templatestyles and the raw strip marker (seen as "UNIQ...QINU") is present. I have no idea but maybe a piped link does not work (in preview?) with something requiring a strip marker. I tried a reference but it worked, although the [1] was not in superscript. Johnuniq (talk) 23:17, 20 December 2020 (UTC)
 * A template using TemplateStyles cannot be used inside a link (this is a known issue(?), see phab:T200704). I would honestly find most fractions in links to be a specious use. --Izno (talk) 23:50, 20 December 2020 (UTC)
 * The particular use in that page, I am kind of at a loss, to be honest. :) The IP's use of a precomposed Unicode fraction would have some detractors and there's at least one MOS that says not to do it, but in that specific case, it seems like a reasonable work around for the bug if you don't want to use a basic . (Or   which of course renders as 1&frasl;2.) --Izno (talk) 00:00, 21 December 2020 (UTC)
 * Another way to avoid it is to ensure it's not the first instance of invoking the particular templatestyles on the page. For yourself, this renders as expected. --Izno (talk) 00:12, 21 December 2020 (UTC)

Just a note, I'm having the same problem with, where the expression is $Z[1 + √5⁄2]$. The breakage is visible in the mainspace article; no need to preview. 64.44.80.252 (talk) 16:58, 26 December 2020 (UTC)
 * I asked for opinions on the wikitext at WT:WikiProject Mathematics. Johnuniq (talk) 23:28, 26 December 2020 (UTC)

I noticed this on Number. The first use is $1⁄2$. UserTwoSix (talk) 20:59, 28 January 2021 (UTC)
 * Actually, $1⁄2$ . UserTwoSix (talk) 21:03, 28 January 2021 (UTC)
 * I used an ugly workaround to fix Number. frac and sfrac do not work in a piped link unless a previous instance of the template is on the page, without a link. The workaround is to insert the current Template:Screen reader-only/styles.css style page. Johnuniq (talk) 23:30, 28 January 2021 (UTC)

Sfrac conflict with wikilinks
There seems to be a problem with sfrac that means if it's put inside a Wikilink, it will break all further usages of sfrac in an article. See here for an example, where the inclusion of $1⁄2$ broke all other fractions in the article and had to be replaced with Frac
 * That's due to a fairly recent change to use WP:TemplateStyles. See just above. A klunky workaround is shown in this edit—the aim is to insert that before the first use of sfrac when that first use is in a piped link. The workaround is only needed if the first usage is in a link. My workaround was replaced with an alternative, namely moving the fraction out of the piped link. Both solutions are pretty awful. Johnuniq (talk) 02:12, 13 February 2021 (UTC)
 * Ahh, thanks, didn't see that. I've used that fix in Percentage for now then. Volteer1 (talk) 02:41, 13 February 2021 (UTC)

Requested move 21 March 2021

 * The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion. 

The result of the move request was: moved (closed by non-admin page mover) DannyS712 (talk) 06:01, 1 April 2021 (UTC)

Template:Frac → Template:Fraction – WP:TG states that "Template function should be clear from the template name, but redirects can be created to assist everyday use of very popular templates." JsfasdF252 (talk) 17:08, 21 March 2021 (UTC)


 * Support - easily supported by the quoted guideline. Suggest a speedy close. -- Netoholic @ 18:46, 21 March 2021 (UTC)
 * Support although template names are abbreviated more this one is excessive.  Crouch, Swale  ( talk ) 19:35, 21 March 2021 (UTC)
 * Oppose, same notation/name as used in . Christian75 (talk) 09:42, 22 March 2021 (UTC)
 * Support per the guideline listed above. Concern about "frac" used in   can be alleviated partially by making frac a redirect to this template. ~  Aseleste  (t, e &#124; c, l) 13:25, 22 March 2021 (UTC)
 * Support - this is an unnecessary abbreviation. Gnominite (talk) 14:32, 22 March 2021 (UTC) CU-confirmed sock, please see Sockpuppet investigations/CuriousGolden --Blablubbs&#124;talk 16:25, 29 March 2021 (UTC)

Well, this was a stupid decision. This template is implemented in many local Wikipedias and several of them retain the English-based name frac, probably simply because it's very similar to the TeX/&lt;math&gt; macro and various HTML named entities like. Also, it's often used within prose an short, yet mnemonic names for templates make sense there – the quoted guideline suggests long descriptive names for navboxes and the like, which is good, but the function of this template is no more clear from fraction than it was for frac. Furthermore, this decision implies we should move the more opaque sfrac to something like stacked fraction, which would just make its use rather cumbersome for many editors. — Christoph Päper 07:26, 12 April 2021 (UTC)
 * Yes, that is the implication for sfrac.
 * At worst, this name has the same opacity as the old name. For most people, I expect it will be less opaque what "fraction" means than "frac". The number of people who know TeX is a smaller number than the people who edit articles that might need access to a fraction.
 * Obviously, you can still use "frac" if you prefer. --Izno (talk) 19:10, 27 April 2021 (UTC)

Pinging to finish cleaning up after this move, please. Something has gone wrong with the CSS, and it is unclear why redirects were not left in some cases; see https://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:Frac/styles.css and https://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:Frac/sandbox/styles.css and https://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:Frac/sandbox. – Jonesey95 (talk) 15:36, 12 April 2021 (UTC)
 * Fixed - sorry, I thought I had got them all. I couldn't leave a redirect for the main template, because it was a round robin page move, and there is not an option to leave a redirect for the subpages DannyS712 (talk) 15:47, 12 April 2021 (UTC)
 * Still not fixed. I created another redirect for you, but see https://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:Frac/sandbox/styles.css. Maybe can help us clean up these errors. They may originate in Module:Convert/sandbox, but I am not great at Lua code. – Jonesey95 (talk) 17:06, 12 April 2021 (UTC)
 * The Special:WhatLinksHere/Template:Frac/sandbox/styles.css only shows a single link from a discussion archive - where are you seeing errors? DannyS712 (talk) 17:33, 12 April 2021 (UTC)
 * It was showing about ten transclusions. Maybe the change I made to Module:convert/sandbox, while not entirely successful, fixed those transclusions but took some time to refresh the affected pages. Looks like everything is sorted now. Thanks for your attention. – Jonesey95 (talk) 18:32, 12 April 2021 (UTC)

Triple-click select
I use triple-click with drag paragraph select in Firefox all the time, which ordinarily selects the paragraph triple-clicked and any additional paragraphs dragged through until click release. Very fast to select an entire Wikipedia lead for copy and paste. If you start your click in the right place, you only have to drag from the bottom of the first para to the top of the last para.

sfrac as currently implemented causes my Firefox instance to detect spurious paragraph breaks. If it occurs in the final para, I end up with a fragment of the final para when I drag only down to the top line, and not the whole thing.

This is a fine point that maybe someone could look into down the road. &mdash; MaxEnt 01:03, 7 October 2021 (UTC)

Fractions are not readable with screen readers or virtual assistants
Rather than reading the fraction that's shown visually, screen readers either say "math", "formula", or nothing at all. The result depends on the screen reader used. Virtual Assistants such as Siri also have the same issues. As you can appreciate this is far from ideal. Can this be fixed? KaraLG84 (talk) 08:50, 23 May 2022 (UTC)
 * The background is at Template talk:Convert where said they have been removing fractions from convert when finding them in articles. Using "what links here" and "Transclusion count" for Fraction shows that the template is used 31,198 times. It's harder to measure how many times convert outputs the same kind of fraction, but some old files I have suggest the number is over 12,000. That's why I said that systematically removing such accepted wikitext would first require a clear consensus. Please do not remove any more until a big discussion has been held. Johnuniq (talk) 10:24, 23 May 2022 (UTC)
 * Has the issue of Template:Fraction being bad for screen readers come up before? I'll follow this with example wikitext to generate the fraction one and two thirds. $45⁄100$ Johnuniq (talk) 10:39, 23 May 2022 (UTC)
 * Not before the discussions referenced above, because I only tested it with JAWS where it works fine and assumed it would work everywhere else (which it clearly doesn't). Graham 87 11:34, 23 May 2022 (UTC)
 * KaraLG84@undefined In addition to the  attribute, we could add a less styled output of the parameters inside  . I do not have screenreaders available to test that, though.   — Christoph Päper 14:49, 5 October 2022 (UTC)

Fractions are not readable in page previews
Please see T334273. In the case of page previews, TemplateStyles do not get applied to previews, as the preview appears outside the context of the page.

I suggest using inline styles rather than template styles for this particular use case as the styles are the same regardless of media, and should likely be more portable across devices/APIs. I usually hate inline styles, but this seems one of the cases where they completely make sense.

Pinging User:Izno as recent modifier of the styles. Jdlrobson (talk) 15:03, 15 May 2023 (UTC)


 * I've responded on Phabricator, as I believe that's the correct place to have this discussion. Izno (talk) 17:00, 15 May 2023 (UTC)

Fractions in category names
If anyone has opinions, there's a discussion at Wikipedia talk:Manual of Style/Dates and numbers. -- Beland (talk) 20:05, 10 August 2023 (UTC)

My recent edit
Please see my forthcoming message at Wikipedia talk:Manual of Style/Accessibility. I said in this edt that I was going to write a message on this talk page, but it turns out to be a more general issue, so this can serve as a notification for now. Graham87 (talk) 08:00, 14 January 2024 (UTC)

Broken formatting with Template:Sfrac
Line wrapping can occur immediately before and after the rendered output of, which is problematic and evidently unintended ( and are fine). Here are examples. You will need to change the browser window width to see the effect:
 * sfrac2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx($1 2/3$).................................................
 * sfrac3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx($bbbbbbbbbbbbbbbbbbbbb⁄ccccccccccccccccccccccc$).................................................
 * frac2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx($a bbbbbbbbbbbbbbbbbbbb⁄cccccccccccccccccccccc$).................................................

Somehow the nowrap property in the style sheet appears to be getting lost. —Quondum 00:38, 10 January 2024 (UTC)


 * The issue is that when narrowing the browser window, as soon as the right margin hits the trailing dots, the first row inserts a line break before the right paren. The other lines do not wrap. I don't know why the examples behave differently but the wrap seems to make sense because how could the template affect the rest of the line? At any rate, if someone wants to investigate, using Special:ExpandTemplates shows the following for the output of simplified versions of the first and second examples.


 * Johnuniq (talk) 01:30, 10 January 2024 (UTC)


 * Line breaks are not permitted other than at defined points. Look at the following examples, in which only one wraps punctuation inappropriately (you can't think that it makes sense for a comma or period to wrap).  Notice how the bad wrapping behaviour in the last case below has been remediated by wrapping the template output in nowrap, something that the template could (and already tries to) do.
 * 12345/6789, (12345/6789), 12345/6789.
 * Though I am not familiar with style sheets, I think I can see the problem. I may get to using the sandbox to experiment with cleaning up the problem, but it will take time with no assurance of success.  —Quondum 21:30, 10 January 2024 (UTC)
 * The person to ask is taking a short wikibreak at the moment so I won't hassle them. Johnuniq (talk) 22:22, 10 January 2024 (UTC)
 * Thanks – obviously there is no urgency; it is unusual to notice this effect in an article. Hopefully the problem is reasonably clearly characterized in the above, though.  —Quondum 00:34, 11 January 2024 (UTC)
 * Actually, I have just sandboxed a version that seems to work just fine at sfrac/sandbox. —Quondum 01:33, 11 January 2024 (UTC)
 * ✅ —Quondum 19:19, 15 January 2024 (UTC)
 * Actually, I have just sandboxed a version that seems to work just fine at sfrac/sandbox. —Quondum 01:33, 11 January 2024 (UTC)
 * ✅ —Quondum 19:19, 15 January 2024 (UTC)