Jump to content

Template talk:Fraction/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2

New style

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

Current (1+2⁄3): 

{{#if:{{{3|}}}|<span style="white-space:nowrap">{{{1}}}<s style="display:none">+</s><span class="template-frac"><sup>{{{2}}}</sup><big>⁄</big><sub>{{{3}}}</sub></span></span>|
<noinclude>#else:</noinclude>
{{#if:{{{2|}}}|<span style="white-space:nowrap" class="template-frac"><sup>{{{1}}}</sup><big>⁄</big><sub>{{{2}}}</sub></span>|
<noinclude>#else:</noinclude>
<span style="white-space:nowrap" class="template-frac"><sup>1</sup><big>⁄</big><sub>{{{1}}}</sub></span>}}}}

Sample: 1+2⁄3, 2⁄3, 1⁄3

Proposal with thin space U+2009

<span class="template-frac">{{#if:{{{3|}}}
|{{{1}}} <sup>{{{2}}}</sup>⁄<sub>{{{3}}}</sub>
|{{#if:{{{2|}}}
|<sup>{{{1}}}</sup>⁄<sub>{{{2}}}</sub>
|<sup>1</sup>⁄<sub>{{{1}}}</sub>}}}}</span>

.template-frac {white-space: nowrap;}

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:
Unicode Character Decomposition Unicode description
U+0025 % 0/0 PERCENT SIGN
U+002F / / SOLIDUS
U+00BC ¼ 1/4 VULGAR FRACTION ONE QUARTER
U+00BD ½ 1/2 VULGAR FRACTION ONE HALF
U+00BE ¾ 3/4 VULGAR FRACTION THREE QUARTERS
U+0337 ̷ / COMBINING SHORT SOLIDUS OVERLAY
U+0338 ̸ / COMBINING LONG SOLIDUS OVERLAY
U+2030 ‰ 0/00 PER MILLE SIGN
U+2031 ‱ 0/000 PER TEN THOUSAND SIGN
U+2044 ⁄ / FRACTION SLASH
U+2153 ⅓ 1/3 VULGAR FRACTION ONE THIRD
U+2154 ⅔ 2/3 VULGAR FRACTION TWO THIRDS
U+2155 ⅕ 1/5 VULGAR FRACTION ONE FIFTH
U+2156 ⅖ 2/5 VULGAR FRACTION TWO FIFTHS
U+2157 ⅗ 3/5 VULGAR FRACTION THREE FIFTHS
U+2158 ⅘ 4/5 VULGAR FRACTION FOUR FIFTHS
U+2159 ⅙ 1/6 VULGAR FRACTION ONE SIXTH
U+215A ⅚ 5/6 VULGAR FRACTION FIVE SIXTHS
U+215B ⅛ 1/8 VULGAR FRACTION ONE EIGHTH
U+215C ⅜ 3/8 VULGAR FRACTION THREE EIGHTHS
U+215D ⅝ 5/8 VULGAR FRACTION FIVE EIGHTHS
U+215E ⅞ 7/8 VULGAR FRACTION SEVEN EIGHTHS
U+215F ⅟ 1/ FRACTION NUMERATOR ONE
U+2215 ∕ / DIVISION SLASH
To clarify from the original discussion:
  1. Are &thinsp; and &frasl; both widely implemented in browsers? Might older browsers choke on a thinspace character?
  2. Would speech-readers be adversely affected by the loss of the hidden "+" from mixed numbers?
  3. 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 |precomposed=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 precompose parameter – or a more general render which could do <math> 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 {{frac|2|4}}, 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 {{frac|0|00}} 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 <sup>/<sub>). {{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? — 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 < span style="margin-left:0.25em"> 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<span style="white-space:nowrap;margin-left:0.25em;margin-right:0.15em">×</span>10<sup>5</sup>
(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 {{frac|1|2|3}} 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)
 Not done 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 &nbsp; 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,[1] or 1/6em in MathML[2]). Superscript text has a standard size of 83% = 5/6em[3] 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 2⁄3 (1&thinsp;<sup>2</sup>&frasl;<sub>3</sub>, existing version for comparison)
  • test 1 2⁄3 (1<sup>&nbsp;2</sup>&frasl;<sub>3</sub>, three parameters with superscript NBSP)
  • test 1⁄2 (<sup>1</sup>&frasl;<sub>2</sub>, 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 word-spacing.
no space: 12⁄3,
white-space:nowrap and normal space, 1⁄4em - 1⁄5em => -0.05em: 1 2⁄3,1⁄4em - 1⁄6em =1⁄12em => -0.083em: 1 2⁄3, 1⁄4em - 1⁄8em =1⁄8em => -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 .template-frac or .frac, 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 <sup>&nbsp;</sup> 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 word-spacing 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

{{editprotected}} 

<span class="frac">{{#if:{{{3|}}}
|{{{1}}}<sup>&nbsp;{{{2}}}</sup>⁄<sub>{{{3}}}</sub>
|{{#if:{{{2|}}}
|<sup>{{{1}}}</sup>⁄<sub>{{{2}}}</sub>
|<sup>1</sup>⁄<sub>{{{1}}}</sub>}}}}</span>

Sample: 1 2⁄3, 2⁄3, 1⁄3 — Christoph Päper 08:46, 16 July 2010 (UTC)

 Question: Does this proposal have consensus? TFOWR 08:54, 16 July 2010 (UTC)
Change has been thoroughly discussed so I've implemented. — 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#Professional career uses {{NFL predraft}} which does some clever things to use {{convert}} to provide metric conversions. For some reason it is failing with 24{{fraction|1|2}}. DePiep could work out what is going on. The before-and-after wikitext from the article follows, with the first "Vert jump" currently showing 1⁄2 in:
Pre-draft measurables
Height Weight 40-yard dash 10-yard split 20-yard split 20-yard shuttle Three-cone drill Vertical jump Broad jump Wonderlic
6 ft 4 in
(1.93 m) 		211 lb
(96 kg) 		5.24 s 1.75 s 2.99 s 4.38 s 7.20 s 241⁄2 8 ft 3 in
(2.51 m)		 33
Pre-draft measurables
Height Weight 40-yard dash 10-yard split 20-yard split 20-yard shuttle Three-cone drill Vertical jump Broad jump Wonderlic
6 ft 4 in
(1.93 m) 		211 lb
(96 kg) 		5.24 s 1.75 s 2.99 s 4.38 s 7.20 s 24+1⁄2 8 ft 3 in
(2.51 m)		 33
Johnuniq (talk) 10:01, 28 December 2017 (UTC)
I don't think that {{NFL predraft}} is necessarily the problem, nor even its direct subtemplates such as {{NFL predraft/check}} or {{NFL predraft/ftin}}. It uses Module:Convert/helper, and it seems that the module cannot handle the integer part if it's outside the {{fraction}}:
  • {{#invoke:Convert/helper |number |24{{fraction|1|2}} }} → 241/2
  • {{#invoke:Convert/helper |number |{{fraction|24|1|2}} }} → 24+1/2
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. --Redrose64 🌹 (talk) 10:42, 28 December 2017 (UTC)
As Redrose says: input 24{{fraction|1|2}} is not treated right, numerically, by Convert/helper. 2400 transclusions of {{NFL predraft}} potentially affected. I have no indication of usage in other templates (convert/helper is quite recent). See {{convert}} (talk). -DePiep (talk) 10:51, 28 December 2017 (UTC)
Got it. This line 
		integer = text:match('(%d+)<span class="visualhide">') or text:match('^(%d+)%s*<span')
in Module:Convert/helper can't handle this recent edit by Jc86035 (talk · contribs). The {{zwsp}} template emits a bare &#x200B; Unicode Character 'ZERO WIDTH SPACE' (U+200B) whereas {{space|hair}} emits <span class="nowrap">&#8202;</span> the &#8202; character being identical to &#x200A; Unicode Character 'HAIR SPACE' (U+200A). It's the lack of a span that causes it. --Redrose64 🌹 (talk) 10:59, 28 December 2017 (UTC)
Right, the fix it might be a simple change to Template:Frac like this:
  • {{#invoke:Convert/helper |number |24{{frac/sandbox|1|2}} }} → 241/2
  • {{#invoke:Convert/helper |number |{{frac/sandbox|24|1|2}} }} → 24+1/2
Anybody foresee any problems with that, or should we revert Jc86035's edit? --Redrose64 🌹 (talk) 11:11, 28 December 2017 (UTC)
(ec) OK, better even. I did not see it was a {{frac}} edit. Since /helper is maintained from {{Convert}}, I opened Template _talk:Convert#Convert/helper error. - DePiep (talk) 11:12, 28 December 2017 (UTC)
re Redrose: in general, convert/helper should follow {{frac}}, 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 Johnuniq 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)

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? --Redrose64 🌹 (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 #Problem above, see this:

  • A: {{frac|24|1|2}}
  • B: 24{{frac|1|2}}

Returns

  • A: 24+1⁄2
  • B: 241⁄2


Doing copy/paste:

A: ​24 1⁄2

B: 24​1⁄2

In expanded code:

  • A: &#x200B;<span class="frac nowrap">24<span class="visualhide"> </span><sup>1</sup>⁄<sub>2</sub></span>
  • B: 24&#x200B;<span class="frac nowrap"><sup>1</sup>⁄<sub>2</sub></span>


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:
{{frac|24|1|2}}
&#x200B;<span class="frac nowrap">24<span class="visualhide">&nbsp;</span><sup>1</sup>&frasl;<sub>2</sub></span>

24{{frac|1|2}}
24&#x200B;<span class="frac nowrap"><sup>1</sup>&frasl;<sub>2</sub></span>
The difference is that when 24 is included in the template, the output includes the following:
24<span class="visualhide">&nbsp;</span>
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 & 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: <span class="visualhide">+</span> or U+2064 INVISIBLE PLUS. 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)

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)

@Benica11: 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

@Jc86035: 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)

@Izno: Reviewing the page history, I think my edit was supposed to be an improvement over Fram'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 MediaWiki talk:Common.css § visualhide removal. Izno (talk) 17:10, 2 December 2020 (UTC)

Reviewers of this section may also be interested in the discussion occurring at Template talk:Convert#Module version 25. --Izno (talk) 03:42, 15 December 2020 (UTC)

Templatestyles and citation templates

Hi Izno, what is the fix for 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. @Plastikspork: The template should never have been used in citation templates in the first place. I would personally recommend A&frasl;B as a replacement, or to use <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 [[example|{{sfrac|2}}]], then the bug is triggered and all further occurrences of {{sfrac|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, Izno and RexxS 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 1/2. (Or 1&frasl;2 which of course renders as 1⁄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 Unit (ring theory) § Integers, 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#Piped link breaking with sfrac. Johnuniq (talk) 23:28, 26 December 2020 (UTC)

I noticed this on Number. The first use is {{math|{{sfrac|1|2}}}}. UserTwoSix (talk) 20:59, 28 January 2021 (UTC)

Actually, [[one half|{{math|{{sfrac|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)

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 ⁠45/100⁠ 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 #Strange rendering bug in sfrac 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)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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/<math> macro and various HTML named entities like &frac12;. 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 DannyS712 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://wiki.riteme.site/wiki/Special:WhatLinksHere/Template:Frac/styles.css and https://wiki.riteme.site/wiki/Special:WhatLinksHere/Template:Frac/sandbox/styles.css and https://wiki.riteme.site/wiki/Special:WhatLinksHere/Template:Frac/sandbox. – Jonesey95 (talk) 15:36, 12 April 2021 (UTC)

@Jonesey95: 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)
DannyS712: Still not fixed. I created another redirect for you, but see https://wiki.riteme.site/wiki/Special:WhatLinksHere/Template:Frac/sandbox/styles.css. Maybe Johnuniq 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)
@Jonesey95: 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. — 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#conversions using the frac parameter are not accessible with screen readers where KaraLG84 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)
@Graham87: 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. 1+2⁄3 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). Graham87 11:34, 23 May 2022 (UTC)
KaraLG84@ In addition to the role attribute, we could add a less styled output of the parameters inside aria-label. I do not have screenreaders available to test that, though. 
<span class="frac" role="math" aria-label="{{#if:{{{3|}}}|{{{1|0}}}+{{{2|0}}}/{{{3}}}|{{#if:{{{2|}}}|{{{1|0}}}/{{{2}}}|{{#if:{{{1|}}}|1/{{{1}}}|/}}}}}}">
— Christoph Päper 14:49, 5 October 2022 (UTC)

Fractions are not readable in page previews

Please see phab: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#Fractions in category names. -- Beland (talk) 20:05, 10 August 2023 (UTC)

My recent edit

Please see my forthcoming message at Wikipedia talk:Manual of Style/Accessibility#Role=math. 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 {{sfrac|b|c}}, which is problematic and evidently unintended ({{frac|b|c}} and {{sfrac|a|b|c}} are fine). Here are examples. You will need to change the browser window width to see the effect:

sfrac2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx(⁠bbbbbbbbbbbbbbbbbbbbb/ccccccccccccccccccccccc⁠).................................................
sfrac3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx(⁠a+bbbbbbbbbbbbbbbbbbbb/cccccccccccccccccccccc⁠).................................................
frac2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx(bbbbbbbbbbbb⁄cccccccccccc).................................................

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 ({{sfrac|b|c}}) 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.
{{sfrac|b|c}}
<templatestyles src="Sfrac/styles.css" /><span role="math" class="sfrac tion"><span class="num">b</span><span class="sr-only">/</span><span class="den">c</span></span>

{{sfrac|a|b|c}}
<templatestyles src="Sfrac/styles.css" /><span role="math" class="sfrac ">a<span class="sr-only">+</span><span class="tion"><span class="num">b</span><span class="sr-only">/</span><span class="den">c</span></span></span>
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.
⁠01234567689/01234567689⁠, (⁠01234567689/01234567689⁠), ⁠01234567689/01234567689⁠.
⁠01234567689/01234567689⁠, (⁠01234567689/01234567689⁠), ⁠01234567689/01234567689⁠.
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)
 Done —Quondum 19:19, 15 January 2024 (UTC)

Template-protected edit request on 14 January 2024

Could the first line be split for readability of the template structure? That is, please replace the first line 

<templatestyles src="Fraction/styles.css" /><span class="frac">{{#if:{{{3|}}}<!-- if 3

with 

<templatestyles src="Fraction/styles.css" /><span class="frac"><!--
-->{{#if:{{{3|}}}<!-- if 3

—Quondum 20:28, 14 January 2024 (UTC)

 Done – Jonesey95 (talk) 00:53, 16 January 2024 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Fraction/Archive_2&oldid=1252487166"