Template talk:Frac

src: arsenal-s3.gomedia.us

Video Template talk:Frac

Possible code

Matter of 2 3/4, 2 3/4, 2?2/3, 2+3/4, 2_3/4, 2-3/4, 2-3/4, 2.3/4, 2'3/4, 2'3/4 not touched yet. -- Christoph Päper 16:05, 15 June 2010 (UTC)

Maps Template talk:Frac

frac problems

Frac wraps its numerator and denominator in <small>. As subscripts and superscripts, they are already in a smaller font; the result of two smalls is nearly unreadable for me. So I prefer

2³/₄

to

2³/₄

But wikipedia is for the consumer; some readers may want to see

${\displaystyle 2{\frac {3}{4}}.}$ or even the special case

2¾

So I think that (1) frac should be customizable, and so (2) using it with subst: defeats the purpose.

I don't know a technical answer to the problem. -Dan Hoey 13:14, 17 April 2007 (UTC)

The first two look exactly the same to me, but I do have a user stylesheet to make that happen. I did not find such CSS rules, that would lower the fontsize for sub and sup, on a quick search through Wikipedia's standard stylesheets. Are you sure that subscripts and superscripts are already in a smaller fontsize?

I think I could incorporate another parameter to allow the selection to generate math markup, but I think images (or tables) look terrible in running text. While precomposed vulgar fractions probably look better than those generated by this template, there are only three (¼, ½, ¾) available for certain on virtually all major platforms (save some installations of Mac OS 9). The template could be updated to automatically generate at least 1/3 , 2/3 , 1/8 , 3/8 , 5/8 and 7/8 , though, but it does not look that good if generated and precomposed fractions appear near each other, say in a table. Christoph Päper 16:46, 18 April 2007 (UTC)

I don't know where it comes from, perhaps the default, but 2^2₂₂₂ has decreasing font sizes in the superscripts and subscripts wherever I've seen them (mostly on mozilla-based browsers on Mac OSX and PC). I also find math code, ugly in rimmomg text, especially with the vertical layout (and I don't know how to get a diagonal layout). But the point is that platforms and users differ, and this would (in an ideal world) be the decision of the user. If a user customization option were available to and used by Template:frac, that would be the way to go, but that is not possible if subst: is used. -Dan Hoey 12:27, 19 April 2007 (UTC)

The unicode fraction characters are likely to present accessibility problems for those with screen-reader software unless it is very up-to-date, and even general usability problems for people with older computers (much of the world). These limited number of fraction characters were not intended for general prose use, but as mathematical tokens (symbols) for limited tablular data use. -- SMcCandlish [talk] [cont] <(-¿-)> 21:12, 9 May 2007 (UTC)

I can grant no credence whatsoever to such complaints, as long as Wikipedia uses a zillion and a half other Unicode characters which don't work right for everybody. And these numbers are commonly used in English; the rest are for the most part not used in English. Gene Nygaard (talk) 23:10, 13 January 2008 (UTC)

Yes: default is font-size: smaller;. -- Hnvnc (talk) 16:42, 18 January 2017 (UTC)

Poor font support as an argument against the use of a character is not the way Unicode and the world work. Many Latin-script using languages need later encoded characters that are uncommon in fonts for a time, till updates happen. There is IMO no good reason that English should stick with ASCII only. -- Hnvnc (talk) 16:42, 18 January 2017 (UTC)

src: energynow.ca

Major accessibility issue

Screen reader software for the visually impaired is not going to handle this properly. The template and its documentation need to updated, to consistently say to use it like "4-{{frac|3/4}}", not ""4{{frac|3/4}}", and to generate a hyphen automatically when the third parameter is used. The weird <s style="display:none">+</s> code in there can simply be removed, as it is unlikely to have any effect on anything at all due to the display:none (which basically makes it dead code); and it is an abuse of the strikethrough element anyway; use span if you want to apply a style to something. Display:none is useful for things like showing and hiding tables of contents and stuff, but as a fixed parameter in a template it's just "noise", unless I'm missing something and there's a new text-to-speech browser that parses for such a string, or whatever. -- SMcCandlish [talk] [cont] <(-¿-)> 21:12, 9 May 2007 (UTC)

The template should be used like this: {{frac|2|3|4}}, although it works also almost the same with this : 2 {{frac|3|4}}.

Unlike the minus sign you propose the usually invisible plus sign is not mathematically incorrect, an underscore would have have been acceptable, too. It was in fact intended for accessibility and may therefore be removed safely if it indeed poses problems in that very area. Note that CSS is not always available.

There are so many uncommon characters in use on WP, the fraction slash should be one of the better supported. Nevertheless, I don't feel strongly about '/' vs. plain old '/'. Christoph Päper 20:44, 13 May 2007 (UTC)

In principle at least, speech browsers should ignore "display:none". There's a separate declaration, "speak:none" for those [1]. I've no idea how this works in practice, though, having never used one. --Ilmari Karonen (talk) 22:44, 13 May 2007 (UTC)

At least in the UK, "4 1/2" is standard, and the hyphenated form, "4-1/2" looks extremely confusing. To the unfamiliar eye, that looks like it should be a mathematical equation giving a value of 3.5 Please bear in mind WP has an international audience. Rhialto 20:17, 5 July 2007 (UTC)

Note that, according to the CSS working group, display:none; does affect non-visual display. --Ms2ger (talk) 19:39, 2 February 2008 (UTC)

src: upload.wikimedia.org

Changes

I set it not to use small (since the sup/sub are already small) and added a class for user style sheets to be able to use. --Random832 07:50, 23 June 2007 (UTC)

Math

{{#if:{{{3|}}}|{{#tag:math|{{{1}}}\tfrac{ {{{2}}} }{ {{{3}}} } }}|{{#tag:math| \tfrac{ {{{1}}} }{ {{{2}}} } }} }}

gives ${\displaystyle A{\tfrac {B}{C}}}$ or ${\displaystyle {\tfrac {A}{B}}}$. --Random832 07:10, 27 January 2008 (UTC)

Perhaps that would be better. I'm not happy with the typesetting of fractions produced by the current template. They look fine in isolation, but are really ugly when used inline in a paragraph of text.--Srleffler (talk) 03:48, 31 March 2008 (UTC)

I'm not too happy with how they are currently displayed either, but don't you think the math-formatted output is a tad too big for inline use?--Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) o (yo?); 14:44, 31 March 2008 (UTC)

The raw HTML super/sub scripting is inappropriate for fractions because contrary to typographic conventions (vertical alignment between base line and ascender line). Further it usually messes up the line-spacing. Therefore, some fine-tuning with CSS could be fine: <sup style="font-size: 70%; vertical-align: 0.4em;">{{{1}}}</sup>/<sub style="font-size: 70%; vertical-align: 0em;">{{{2}}}</sub> -- Hnvnc (talk) 16:48, 18 January 2017 (UTC)

Do you need <BIG> ?

Not using <BIG> gives a better look for me:

3 ¹/₂ 3 ¹/₂ 3 ¹/₂ 3 ¹/₂ 3 ¹/₂ 3 ¹/₂

The latter three don't use <BIG>. What do you think? And how about using a small space instead of the hidden "+" ? - TAKASUGI Shinji (talk) 13:34, 6 March 2008 (UTC)

{{frac2}}

Just created this, thought it might make things more readable in some cases.

What's with the rows of the nbsps, though? :)--Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) o (yo?); 16:25, 15 April 2008 (UTC)

That has been addressed, &ampnbsp; no longer required-- SkyLined (talk) 22:44, 22 April 2008 (UTC)

+pl:Szablon:U

{{editprotected}} Please add pl interwiki: pl:Szablon:U. 83.29.153.144 (talk) 12:27, 27 April 2008 (UTC)

 Done Happy-melon 14:12, 27 April 2008 (UTC)

Denominators disappear

Denominators for fractions such as ³/₅ partly disappear or are covered by subsequent lines in Microsoft Internet Explorer. I am going to investigate the problem further. Example:

³/₅₅₅₅
³³³³/₅

The culprit is the interplay between font: x-small sans-serif; and font-size:127% in main.css. --Yecril (talk) 17:58, 12 September 2008 (UTC)

Unicode fractions

Is there any consensus about using the Unicode fraction characters when available? Or not?

• 1/8 ¼ 3/8 ½ 5/8 ¾ 7/8 1 -- eighths series
• 1/3 2/3 -- thirds series

-- ¾-10 16:12, 28 December 2008 (UTC)

I can't recall the exact location of the discussion (it was a while ago), but the possibility of using Unicode fraction characters was indeed discussed in the past and discarded (mostly due to the accessibility issues).--Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) o (yo?); 17:58, December 29, 2008 (UTC)

Thanks! -- ¾-10 01:39, 30 December 2008 (UTC)

Fraction slash not displaying in Firefox

When using the frac template, the fraction slash does not appear in Firefox when using the default Monobook skin. Firefox does display a fraction slash, but the particular combination of HTML markup in the frac template, Monobook skin and the Firefox browser causes it to disappear.

In Firefox using Monobook skin:

• [sup]1[/sup][big]/[/big][sub]5[/sub] works, gives ¹/₅
• [sup]1[/sup]/[sub]5[/sub] does not work, gives ¹₅

-- B.D.Mills  (T, C) 12:38, 26 January 2009 (UTC)

Retesting this with real code:

• ¹/₅

and it looks perfectly fine in modern Firefox. -- SMcCandlish ? ? ¢ ?^???_??^?? 03:30, 20 October 2014 (UTC)

Sorting issue

I'm using this template on DHL Delivery Man Award, and as you can see in the IP column of the monthly section, the fractions aren't sorting properly. Any idea why?--Muboshgu (talk) 01:37, 18 October 2009 (UTC)

This has been fixed [2].--Patrick (talk) 08:49, 15 December 2009 (UTC)

Not really. We figured out a work-around for it, but this template still doesn't sort properly on its own. --Muboshgu (talk) 12:46, 15 December 2009 (UTC)

I made {{sortfrac}}, a combination of {{frac}} and {{sort}}. Perhaps we do not need separate templates {{frac}} and {{sortfrac}}, then we can replace the content of {{frac}} by that of {{sortfrac}}.--Patrick (talk) 06:33, 16 December 2009 (UTC)

Tightening formatting (Fork from Wikipedia talk:Manual of Style (mathematics)#Poll)

This template has been discussed at Wikipedia talk:Manual of Style (mathematics)#Poll. Since that discussion suggests this sort of fraction isn't appropriate in most mathematics contexts, lets move that portion of the discussion here. In particular (as mentioned elsewhere on this talk page), this template could be changed to give renderings much closer to the precomposed fraction symbols by making the denominator not subscript but just small. Compare ¹⁰⁰/200 to ¹⁰⁰/₂₀₀. The first one is

<small><sup>100</sup><big>/</big><small>200</small></small>

The same formatting compares well with the precomposed symbol (compare: ¹/2 ½). While that does use the <small> tag, which I gather is not in HTML5, there must be some way to get that effect in HTML5. --Ben FrantzDale (talk) 12:33, 5 April 2010 (UTC)

With <small> you lose the certainty that the numerator font will be the same size as the denominator font. And IE8 at least does indeed render the denominator in a larger size font than the numerator using your method. -- Richardguk (talk) 13:03, 5 April 2010 (UTC)

What about 1/2 (vs ½)? That's:

<font style="vertical-align:top;font-size:xx-small;">1</font><font style="font-size:big;margin-left:0.1em;">/</font><font style="font-size:xx-small;">2</font>

That's already beyond my HTML skills, but at least will show the same size numerator as denominator. --Ben FrantzDale (talk) 15:22, 5 April 2010 (UTC)

The two parts are now equal in size, but both numbers are a bit large (rendered on IE8): larger than in the ½ glyph and, more importantly for the general case, overlapping with the fraction-slash (which was presumably designed with sup/sub characters in mind). -- Richardguk (talk) 16:36, 5 April 2010 (UTC)

OK; it works in Firefox. Is there a way to implement this gist in HTML5? --Ben FrantzDale (talk) 17:54, 5 April 2010 (UTC)

In Firefox 33 on Mac OS X 10.9 in 2014, it looks a bit awkward (the fraction-slash is closer to the 2 than the 1), but it's not insanely awful. The current output of the template looks better, compared side by side: Current template: ¹/₂ vs. Ben's HTML: 1/2 vs. Unicode: ½

Some might find the current template's numerals rather large compared to these alternatives, but they must have much better eyesight than I do. I much prefer the current template's size. To cobble together an HTML alternative based on Ben's that fixes the Firefox display problem and the too-small size, this would work: <font style="vertical-align:top;font-size:xx-small;">1</font><font style="font-size:medium;margin-left:0.1em;">/</font><font style="font-size:xx-small;">2</font> - 1/2 (But I'd bet good money it looks like crap is some other browser.) -- SMcCandlish ? ? ¢ ?^???_??^?? 03:41, 20 October 2014 (UTC)

Template:frac considered harmful

This template is a bad idea. It misuses markup in a misguided attempt to provide an alternative to the standard Unicode characters. Here's how that table above looks in Lynx:

                              Markup                                 Result     {{subst:frac|2|3|4}}                                     2+^3/[4]     {{frac|2|3|4}}                                           2[DEL: + :DEL] ^3/[4]     2 3/4                                                    2 3/4     2<sup><small>3</small></sup>/<sub><small>4</small></sub> 2^3/[4]     2<small><sup>3</sup><big>/</big><sub>4</sub></small>     2^3/[4]     2<small><sup>3</sup>/<sub>4</sub></small>                2^3/[4]     2<small><sup>3</sup>&frasl;<sub>4</sub></small>          2^3/[4]     2 3&frasl;4                                              2 3/4     2 3/4                                                    2 3/4     2<sup><small>3</small></sup>/<sub><small>4</small></sub> 2^3/[4]     2<small><sup>3</sup><big>/</big><sub>4</sub></small>     2^3/[4]     2<small><sup>3</sup>/<sub>4</sub></small>                2^3/[4]     2<small><sup>2</sup><big>/</big><small>3</small></small> 2^2/3     2&frac34;                                                2¾     2¾                                                       2¾  

Speech browsers will undoubtedly have similar issues.--Chowbok ? 06:28, 1 June 2010 (UTC)

I'd say the template should be improved, not that it's "harmful" or a "bad idea". With all due respect to the accessibility concerns (which do need to be addressed, yes), the template provides value to the vast majority of users who use browsers other than Lynx or speech-based browsers.--Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) o (yo?); June 1, 2010; 14:24 (UTC)

Upon further reflection, I've decided to nominate this for deletion, so please respond there. Nothing personal.--Chowbok ? 14:59, 1 June 2010 (UTC)

Note that the table has been changed since Chowbok posted that. -- Christoph Päper 16:31, 15 June 2010 (UTC)

Nomination for deletion of Template:Frac

Template:Frac has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. --Chowbok ? 14:56, 1 June 2010 (UTC)

Discussed at Wikipedia:Templates for discussion/Log/2010 June 1#Template:Frac:

"The result of the discussion was Keep, and suggest that discussion concerning improvements or restriction of the use of this template could be continued at say Template talk:Frac. Plastikspork _-OE^(talk) 01:37, 9 June 2010 (UTC)"

-- Richardguk (talk) 23:02, 20 June 2010 (UTC)

New style

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

Current (1+2/3):

Sample: 1+²/₃, ²/₃, ¹/₃

Proposal with thin space U+2009

Sample: 1 ²/₃, ²/₃, ¹/₃

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:

To clarify from the original discussion:

1. Are   and ⁄ 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×10⁵). 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   (or its equivalents   and  ), 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   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,[3] or 1/6em in MathML[4]). Superscript text has a standard size of 83% = 5/6em[5] 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 ²/₃ (1&thinsp;<sup>2</sup>&frasl;<sub>3</sub>, existing version for comparison)
• test 1 ²/₃ (1<sup>&nbsp;2</sup>&frasl;<sub>3</sub>, three parameters with superscript NBSP)
• test ¹/₂ (<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: 1²/₃,

white-space:nowrap and normal space, ¹/₄em - ¹/₅em => -0.05em: 1 ²/₃, ¹/₄em - ¹/₆em = ¹/₁₂em => -0.083em: 1 ²/₃, ¹/₄em - ¹/₈em = ¹/₈em => -0.125em: 1 ²/₃,

non-breaking space, -0.05em: 1 ²/₃, -0.1em: 1 ²/₃, -0.15em: 1 ²/₃, -0.2em: 1 ²/₃, -0.25em: 1 ²/₃, -0.3em: 1 ²/₃, -0.4em: 1 ²/₃, -0.5em: 1 ²/₃.

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}}

Sample: 1 ²/₃, ²/₃, ¹/₃ -- 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)

Old {{Fraction}} discussion

Why?

It seems like it would be nice to have a Fraction template where you could write {{Fraction}} to get 1/2 in a pretty format. See Fraction (mathematics) for a good place where it could be used to clean up the text. Markkawika 07:04, 3 January 2006 (UTC)

Merge

I would rather see this template's functionality merged into Template:Frac, perhaps with a parameter to trigger the "pretty" display. Then the whole template could be moved here. -- Martin (MSGJ · talk) 14:59, 2 July 2010 (UTC)

Appearing of {{frac}} i certain browsers.

See Wikipedia_talk:Manual_of_Style#That_wretched_fraction_template for the discussion. Headbomb {talk / contribs / physics / books} 23:30, 3 November 2010 (UTC)

Behavior with no parameter specified

In Wikipedia:Templates for discussion#Template:FracText user:76.65.128.198 suggested that {{frac}} should output a fraction slash only, i.e. '/'. This can easily be done with another #if (the last one above) without distorting any existing usage. If we also want to support stacked fractions (by adding rules to user or sitewide stylesheets), all instances of ⁄ should probably be wrapped in spans so we're able to hide them more reliably. -- Christoph Päper 16:31, 14 December 2011 (UTC)

Sensible suggestion.  Done. Could you update the documentation as appropriate? -- Martin (MSGJ · talk) 16:49, 14 December 2011 (UTC)

Beat me to it... -- Edokter (talk) -- 16:59, 14 December 2011 (UTC)

Spacing

The space is needed, both for display (which could be handled by classes) and for copy/paste. We don't want {{frac|1|2|3}} to copy as "12/3", do we? See previous discussions. -- Arthur Rubin (talk) 17:47, 14 December 2011 (UTC)

It probably need not be non-breaking, if the CSS includes the appropriate nowrap characteristic. -- Arthur Rubin (talk) 18:47, 14 December 2011 (UTC)

The nowrap class already handles this. -- Edokter (talk) -- 19:02, 14 December 2011 (UTC)

We could use U+2064 'invisible plus', but I'm afraid that semantically correct character is not supported well enough: 1?²/₃ -- Christoph Päper 11:39, 20 December 2011 (UTC)

I can confirm that it did nothing useful in Mac OS X; copy-pasted "as 1?2/3". -- SMcCandlish Talk=> ?(^Õ?^?)? Contribs. 16:31, 23 December 2011 (UTC)

That's not nothing, though, since the invisible plus remained - unlike display:none characters. -- Christoph Päper 23:45, 23 December 2011 (UTC)

Lack of a space is a "fatal"-level problem, since it will blatantly falsify the data when it is copy-pasted. One problem I can see is that most people expect the form "1-2/3" when sup/sub styling is not used. Here's a way to do that: 1-²/₃. I think there's a slight off-white color difference in one namespace or another; my eyesight's not really good enough to be sure, but that could be a simple namespace test, and there can be a |bgcolor= parameter for cases were this needs to be used inline on a colored background: 1-²/₃. And a |doc=y for use in green-backgrounded template documentation (or just get rid of the those ugly green backgrounds in template documentation, which I suggest is a better idea). It already works fine with links on normal pages: 1-²/₃. -- SMcCandlish Talk=> ?(^Õ?^?)? Contribs. 16:16, 23 December 2011 (UTC)

Or make the - be a +, but I have to say I've never seen fractions expressed as "1+2/3" in my entire life except on this and related Wikipedia talk pages. -- SMcCandlish Talk=> ?(^Õ?^?)? Contribs. 16:40, 23 December 2011 (UTC)

Values with fractions are traditionally typeset without a space; it is part of the number. But since modern browsers (except IE) do not copy hidden text, there is a space incorporated. -- Edokter (talk) -- 18:36, 23 December 2011 (UTC)

Arthur, you say that the space is needed for display and for copy & paste. You say that this was discussed above. I'm not, however, convinced that it really was shown above that the space in needed. As Edokter points out, there traditionally is no space so I don't see why it's needed for display. Certainly we don't want " 1 ²/₃" coming out as "12/3" on copy and paste, no. It once was a hidden "+". Okay, "1+2/3" is not a usual way of writing a fraction but it does make logical sense and here, another advantage: we can copy this into a calculation program (e.g. Excel) and it will would ... or at least it would work if the fraction slash copied and pasted as an ordinary one. So that's what I'd prefer to have: no space and and plus sign and ordinary slash on copy and paste. JIMp _talk·cont 03:31, 27 February 2012 (UTC)

MS Office 2010 feedback form or (800) MICROSOFT (642-7676). They should support parsing any combination of the sequence integer, (invisible) plus or any kind of space - both tokens optional -, integer and (fraction) slash or Unicode character for "1/", integer, or Unicode fraction. -- Christoph Päper 08:35, 28 February 2012 (UTC)

Template:Fraction and accessibility

I've started a thread at Wikipedia talk:WikiProject Accessibility/Archive 3#Template:Fraction concerning potential accessibility issues with {{fraction}}. --Redrose64 (talk) 10:00, 6 July 2012 (UTC)

They're more than "possible". {{Frac}} avoid the Unicode fraction characters for several reasons. This template is a bad idea, for reasons that have been gone over at Template talk:Frac and WT:ACCESS more than once. -- SMcCandlish   Talk=> ??¿¤þ   Contrib. 15:47, 19 November 2012 (UTC)

{{Frac}} also avoids vulgar fractions that aren't only "unicode", such as ½ and ¾, for reasons that have never been adequately explained.--Chowbok ? 23:49, 20 November 2012 (UTC)

• Please post at Wikipedia talk:WikiProject Accessibility/Archive 3#Template:Fraction, not here, to avoid a split discussion. Thanks. --Redrose64 (talk) 07:18, 21 November 2012 (UTC)

advertise template:sfrac

Per discussion at Wikipedia talk:Manual of Style/Dates and numbers#frac template for derived units, I propose an addition to the lede on this template documentation: "This template should not be used in science or mathematical articles, per MOS:FRAC and MOS:MATH#Fractions. Use {{sfrac}} instead." I do not have permissions to perform the edit myself.--Yannick (talk) 14:11, 26 November 2012 (UTC)

I've added it; thanks!--Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) o (yo?); November 26, 2012; 15:07 (UTC)

sfrac: Browser compatibility

I have tested this with Internet Explorer and FireFox on Windows XP. There is some concern that it does not render very well in certain situations on Mozilla based browsers, which is being investigated. If you experience this, please let me know what browser and OS you're using and send me a screen-grab.
    -- SkyLined {talkcontribs 11:39, 25 April 2008 (UTC)

Here is what I've found:

• IE 7 - Renders correctly (or rather as intended)
• Firefox 3.0.1 - Renders almost correctly: the horizontal line is too low and crosses the top of the denominator
• Chrome 0.2.149.27 - Same as Firefox 3.0.1
• IE 6 - Renders really badly, the horizontal line extends the full width of the page

Might still be tweaked for Firefox and Chrome, but IE 6 could be difficult. GregorB (talk) 20:38, 5 September 2008 (UTC)

It's based on {{su}} which has similar problems. We're working on a solution there and we should be able to port it to this template.     -- SkyLined {^talk_contribs 11:15, 7 September 2008 (UTC)

sfrac: Nested fractions

Nested fractions render incorrectly in Mozilla/Chrome: {{frac2|1|{{frac2|2|5}} + {{frac2|1|3}}}} renders as 1/2/5 + 1/3

Same code with my experimental code from {{sfrac/sandbox}} (it works in Google Chrome / Mozilla / IE7, I haven't tested other browsers): 1/2/5 +1/3. Also compare ?2
f/?x2
(current template) with ?2
f/?x2
(sandbox template). // stpasha » 06:33, 3 November 2010 (UTC)

sfrac: Single input

 Done {{frac|2}} gives ¹/₂ but {{frac2|2}} gives 1/2. I find the behaviour of {{frac}} much more useful. How often you you want 1 in the denominator?JIMp _talk·cont 05:11, 2 February 2011 (UTC)

Behavior has been synchronized some time ago. -- Christoph Päper 18:28, 6 September 2013 (UTC)

sfrac: Line thickness

The line (vinculum) thickness is specified as 1px. I firmly believe it should be specified in 'em' to be scalable for large font sizes. The most common font size in browsers is 16px (that's CSS pixels of course), numerator and denominator have 85% of the inherited font size, i.e. usually 13.6px (displayed at 14 device pixels where they match CSS pixels well enough). "1px" therefore equals approximately 0.0735em. I had changed the value to 0.075em, but User:Edokter reverted that saying it was "below 1px at default size (aka invisible)", which I doubt. I don't care if we increase it to, say, 0.1em, but let's not keep using 'px' here. Tests:

16px thin, 16px 1px, 16px 2px, 16px 0.1em, 16px 0.075em.

13.6px thin, 13.6px 1px, 13.6px 2px, 13.6px 0.1em, 13.6px 0.075em.

14px thin, 14px 1px, 14px 2px, 14px 0.1em, 14px 0.075em.

85% thin, 85% 1px, 85% 2px, 85% 0.1em, 85% 0.075em. --Christoph Päper 09:00, 30 November 2012 (UTC)

We have lots of browsers to contend with, and some of them will render the vinculum invisible if it tries to render a line who's width in em falls below 1px, meaning the line will not be drawn, which is unacceptable. I chose 1px because it actually matches how most fonts will render horizontal lines in various glyphs at various font sizes; to my suprise, they all mostly render as 1px. So even at large font sizes, 1px matches native horizontal lines just fine. -- Edokter(talk) -- 20:36, 30 November 2012 (UTC)

Spacing in mixed numbers

There is currently a discussion on the use of spacing numbers at: Wikipedia talk:Manual of Style/Dates and numbers#Non-breaking spaces in mixed numbers. --sroc (talk) 00:48, 9 July 2013 (UTC)

Sfrac: accessibility with screen readers

Before my edit to the template, {{Sfrac}} did not read correctly with screen readers; they would read 1/2 as 12. To fix this, I have replaced <span style="display:none;" with <span style="position:absolute;left:-10000px;top:auto;width:1px;height:1px;overflow:hidden;" per this WebAIM article. This allows 1/2 to be read as "1 / 2" to screen reader users, which makes a lot more sense. It shouldn't affect the way the template appears for sighted users, but if it does, feel free to revert and/or tweak my edit. Are there any other fraction templates that could do with this treatment? Graham87 02:52, 6 September 2013 (UTC)

I might turn this into a CSS class. This may likely be usefull in other places. -- Edokter (talk) -- 07:13, 6 September 2013 (UTC)

This will have implications for the frac function in Module:RailGauge, where I copied the {{frac}} classes but didn't include any special styling. Maybe it would be useful to have a Module:Frac instead, so that whatever css we decide on is also used consistently in module space? -- Mr. Stradivarius ^{? talk ?} 11:21, 19 September 2013 (UTC)

Unify {{frac}} and {{sfrac}}

Let's assume there was a class screenreader - which is not a good name - that contained this code or something similar, e.g. using negative text-indent. To make the code more readable, let's also assume the denominator and numerator span styles would come from a central stylesheet, not a style attribute:

As you can see, there would be only few adjustments necessary - i.e. more wrapping spans - to unify {{frac}} and {{sfrac}}. Since these are frequently used templates, their style might go into common.css where generic .frac {} would make vulgar fractions like current {{frac}} and .math .frac {} would generate stacked fractions using the same HTML base. Two possible code variants follow below. (We don't have to keep using sup and sub, of course.) -- Christoph Päper 20:11, 6 September 2013 (UTC)

or

On the whole, these templates are used on only a fraction off all articles on Wikipedia. So putting this CSS in Common.css is undue. We should wait until templates can have their own CSS page. -- Edokter (talk) -- 22:21, 6 September 2013 (UTC)

RfC for spacing mixed numbers

Notice of central discussion affecting {frac}. -Wikid77 18:27, 27 December 2013 (UTC)

Again, people have noticed unusual spaces inside mixed numbers (space before fraction part), and I have tagged the discussion as RfC:

• WT:Manual_of_Style/Dates_and_numbers/Archive 143#Spacing_of_mixed_numbers

This topic of typesetting fractions, possibly hiding a space within a span-tag, crosses into technical means to format fractions with templates ({{frac}}, {{sfrac}}, {{convert}}, etc.), yet support wp:Accessibility for screen readers, as a mix of policy/style and technical issues. As an RfC, we can gain a broader, 30-day consensus to settle the issues in all the various facets, now starting early to gather opinions at year-end in 2013. -Wikid77 18:27, 27 December 2013 (UTC)

discrepancy between abbreviation and display with reducible fractions

When using this template with reducible fractions like 2/4, 2/8 or 3/9, The template displays the irreducible equivalent (1/2, 1/4 and 1/3, in these cases) but the abbreviation uses the original input - "two-quarters", "two-eighths" and "three-ninths". I think this is a problem - may not be a huge one, but it's a problem nonetheless:

²/₄, ²/₈, ³/₉, ⁴/₈, ⁶/₈, ⁶/₉

???????? (aka kipod) (talk) 15:56, 6 March 2014 (UTC)

What is "this template"? Several template talk pages redirect here. --Redrose64 (talk) 16:12, 6 March 2014 (UTC)

Currently, only {{fraction}} uses the HTML element abbr and includes code to generate a title attribute with spelt-out numbers. Since that should be considered experimental - see next section - inconsistent results are to be expected. Fractions could be reduced automatically, but that would require more complex code than the following. -- Christoph Päper 12:45, 12 March 2014 (UTC)

"This template" is {{fraction}}. I agree that the abbreviation should match the fraction displayed the question is whether to reduce both or to reduce neither.

To make things more complicated, the template doesn't display the irreducible equivalent if it there is no Unicode with which to do so. For example, {{fraction|4|14}} gives "4/14" not "2/7".

Either it should reduce all or none. I'd prefer it reduce none. Both the displayed output and the "abbreviation" (I'm only seeing a question mark appear near the cursor) should match the input. This is what template {{frac}}, on the other hand, does (it doesn't reduce fractions).

Perhaps there could be an option to reduce fractions. It seems to me, though, that it would be best if this weren't the default but could be controlled by a parameter or, probably better still, done by another template.

I'm not sure what is meant by "that should be considered experimental". Why would you be experimenting with a template which is used on hundreds of pages especially when you know that "inconsistent results are to be expected"? I'd expect the coders of such a widely-used template to make the effort to ensure their results are as consistent as practically possible.

Actually, I don't believe {{fraction}} should even exist but more on that below. Jimp 13:11, 12 March 2014 (UTC)

Reducing fractions automatically

Suppose we were to make a fraction template which automatically reduces everything, the code may be more complicated but not hugely so. We could use {{gcd}} to calculate the greatest common denominator then take the result and send it along to a subtemplate (call it {{fraction/compose}}), like this.

  {{#if:{{{3|}}}    |{{fraction/compose       |gcd={{#iferror:{{#expr:{{{1}}}+{{{2}}}/{{{3}}}}}          |<!--       -->|{{gcd|{{{2}}}|{{{3}}}}}}}<!--    -->|{{{3}}}|{{{2|}}}|{{{1|}}}<!--  -->}}    |{{#if:{{{2|}}}       |{{fraction/compose          |gcd={{#iferror:{{#expr:{{{1}}}/{{{2}}}}}             |<!--          -->|{{gcd|{{{1}}}|{{{2}}}}}<!--        -->}}<!--       -->|{{{2}}}|{{{1|}}}<!--     -->}}       |{{fraction/compose          |gcd={{#iferror:{{#expr:1/{{{1|}}}}}             |<!--          -->|1<!--        -->}}<!--       -->|{{{1|}}}<!--     -->}}     }}  }}  

Then at the subtemplate we could put together a reduced fraction using the gcd parameter. The code for the "abbreviation" would then look like this (note that by switching the order of the parameters we can get rid of a few {{#if:}}s).

  title="{{{spell|{{#invoke:ConvertNumeric   | numeral_to_english   | {{{3|0}}}   | numerator={{#expr:{{{2|1}}}/{{{gcd|1}}}}}  | denominator={{#expr:{{{1|1}}}/{{{gcd|1}}}}}  }} }}}"  

Then the actual displayed fraction would be put together accordingly (whether it be using the Unicode, slashes and the weird reciprocal character, " 1/", of {{fraction}} or the standard MOS-compliant output of {{frac}}).

The code could actually be simplified further by using two subtemplates instead of one: one for the case where three parameters were originally input and the other for the case of two with the case of one input parameter being dealt with on the main template page (there's no need to calculate the gcd if the numerator is one).

Of course, if we're in the game of "correcting" the input in this way, what about converting improper fractions to mixed numbers and what about negative fractions? Jimp 09:17, 13 March 2014 (UTC)

Deprecated

A reminder: Please note that {{fraction}} is deprecated because the use of Unicode fraction characters is discouraged across the board. -- Edokter (talk) -- 11:04, 13 March 2014 (UTC)

Why does {{fraction}} still exist?

{{Fraction}} uses pre-composed glyphs, which, as noted on the {{frac}} doc page is discouraged by MOS. {{Fraction}}'s own doc page says that it's deprecated. It was resurrected in 2010 after three years of being redirected to {{frac}}. The idea seemed to be to create "nicer-looking common fractions". I'm not convinced that the current output of {{fraction}} is nice-looking at all. Firstly, the output is inconsistent. There are three possible outputs you might get which I'm listing below.

1. A Unicode character (which MOS:FRAC states are "discouraged entirely, for accessibility reasons among others", e.g. " 3/8 ")

   These are hardly nice-looking. Some of them are barely legible to me. Worse still, one-seventh, one-ninth and one-tenth are all appearing as boxes (using Chrome).

2. A fractions using an ordinary slash (e.g. "1 5/12")

   At least these are legible but why use a template instead of just typing a slash? (Okay, there's also a thin space but MOSNUM doesn't recommend that either).

3. The Unicode character " 1/" plus something (e.g. " 1/12")

   This is just weird. I really don't get the idea here. In what sense is " 1/16", " 1/20", " 1/32", etc. nice-looking?

So by using this template you could get " 7/8 " and "?" alongside "3/10" and "1/12" alongside " 1/15" " 1/17", none of them are all that pretty but seen together they're even worse. Beauty, they say, is in the eye of the beholder, so just because this looks ugly to me doesn't mean it is ugly but, æsthetics aside, this template is just violating the WP guidelines apparently on a whim. Why is this so? Why don't we send a bot out to delete the tion in {{fraction and in the mean time reinstate the redirect to {{frac}}? Jimp 12:10, 12 March 2014 (UTC)

Sounds reasonable to me. Seeing as this was resurrected from a redirect, it might be worth sending it to WP:TFD so that we can get a more official decision on what to do with it. -- Mr. Stradivarius ^{? talk ?} 12:47, 12 March 2014 (UTC)

One reason it still exists is the (experimental) code mentioned in the section above. It tries to overcome the accessibility problems that "Unicode characters" - all encodable characters are Unicode characters, except maybe for the ones in the PUAs - allegedly impose by generating <abbr title="one-third"> 1/3 </abbr> and the like. If I remember correctly I added it after related discussion in one of the MOS Talk pages. Of course, this could be done in {{frac}}, too, but that requires an admin to edit and screen readers probably already work more reliably with {{frac}}'s HTML output.

As for the font problems you encountered, that's another story completely. -- Christoph Päper 12:59, 12 March 2014 (UTC)

Shouldn't experimental code trying to overcome problems be found in a sandbox rather than a template used on hundreds of pages? Shouldn't we await the results of the experiment, then discuss the issue at WT:MOSNUM and see whether there is consensus to change the guidelines before unleashing it onto WP? MOSNUM still discourages these characters "entirely" and not only because of accessibility. No magic <abbr title="one-third"> 1/3 </abbr> code is going to help the fact that " 1/3 " looks more like a squashed ant than a number. My screen reader is a pair of eyes, pretty average eyes, I don't even need glasses, but I can hardly read these characters. As for the consistency problem, there are a few things that could be done to improve the situation but in the end there's no real solution since Unicode doesn't and cannot possibly cover all possible fractions. You could ditch " 1/", I can't fathom why it was included in the first place. You could forget the Unicode for one-seventh, one-ninth and one-tenth: there are (apparently) none for two-sevenths, two-ninths, three-sevenths, three-tenths, etc. plus they don't even work (not for me and I suppose many others). The best solution, in my opinion, would be to copy the code into a sandbox, do the experiment there and make {{fraction}} a redirect again. Jimp 13:54, 12 March 2014 (UTC)

See also #Template:Fraction and accessibility (above), Wikipedia talk:WikiProject Accessibility/Archive 3#Template:Fraction and most recently, Wikipedia:Village pump (technical)/Archive 124#Underlines versus fractions. Those are just the ones that I've commented in: there may be others. --Redrose64 (talk) 15:54, 12 March 2014 (UTC)

I agree {{fraction}} should be sent to TFD. I still don't get why some insist on using composed glyphs when they are discouraged across the board. -- Edokter (talk) -- 11:17, 13 March 2014 (UTC)

Jimp, the "spell" code is only experimental in so far as I checked that it does what it was intended to do in simple situations, but didn't run extensive tests. You can consider the deployment in {{fraction}} as a test run for possible inclusion in {{frac}}, which is used much more often - a public sandbox so to say. The prime reason it's currently limited to {{fraction}} is that this one is editable without admin privileges. I agree that all of these related templates should only deal with formatting and hence normalization should be done elsewhere, therefore the only critique that has come up so far is moot.

I don't actually oppose redirecting {{fraction}} to {{frac}} once again, I'd like to unify all of them after all. I just pointed out that the former currently supports things the latter doesn't which may be useful. -- Christoph Päper 21:19, 14 March 2014 (UTC)

Testing in a live template is not encouraged at all; it can disrupt articles. {{Frac}} has evolved to where it is now, a good generic fraction template, and so has {{sfrac}}. I don't see the need to merge sfrac into here; how would you control the appearence? Adding a paramter is more cumbersome the just using another template name.

So barring any objection, I am going to redirect fraction to frac, in order to restore legibility to those articles still using fraction. -- Edokter (talk) -- 21:40, 14 March 2014 (UTC)

"Testing in a live template" is totally in accordance with WP:BOLD, since I tested the code in a sandbox first, but there was left the kind of testing one can only do in the wild. That is why I said "experimental". This template was also deprecated, so not really live. The code furthermore was only an addition that is invisible in most situations, i.e. no disruption. Also, the critique it provoked above was actually about the former existing code which does reduce fractions, although only the ones {{fraction}} could sensibly be used with anyway, i.e. those that have precomposed characters.

With my original creator of the frac template hat on, I firmly believe that {{frac}} is not a good generic fraction template and neither is {{sfrac}}, at least judging from their HTML and CSS code. It's just the best we have and can have currently. Precomposed glyphs, in spite of bad fonts, provide the best possible rendering, but they're limited to a limited set. The Open Type font feature frac (and afrc for {{sfrac}}) is the next best thing, but is not (yet) available in a useful manner in CSS, browsers and popular fonts. -- Christoph Päper 14:34, 15 March 2014 (UTC)

Being transcluded onto two to three thousand pages makes it quite "live" in any relevant sense be it deprecated or otherwise. (We should get a bot through to switch these to {{frac}}.) Fair enough the "spell" code wasn't disruptive (more than I could say than for the glyphs though). I'm not sure that there's much sympathy going around for editors who get to work on a fork because the mainstream version is protected. True, the "spell" code may be useful; test it thoroughly in the sandbox and then put the suggestion to add it to {{frac}} on this page. The automatic reduction of fractions also may have some use but I'd wait unit the need arises (and create a whole new template for this kind of thing). The other thing that {{fraction}} was doing, producing "nice-looking" fractions, was of no use (it was detrimental). Anyhow, I'm glad there are no objections to having {{fraction}} redirected to {{frac}}. Jimp 09:37, 17 March 2014 (UTC)

Accessibility improvement

Proposed code

Explanation

The code above contains these proposed changes from current code:

1. Change from span to abbr element type.
2. Add title attribute and {{{spell}}} parameter. The new optional parameter can be used to override the result of calling the ConvertNumeric module. This shouldn't be necessary often, though.
3. Add style attribute.
   1. border-bottom:0; to inhibit underlining that is often used by stylesheets and browsers to indicate to the user that an expansion is provided. This would be disruptive with fractions.
   2. font-variant-numeric: diagonal-fractions; to enable the frac Open Type feature in browsers that implement module Fonts level 3. This has an effect only if the font also supports it.

All of this has been tested small-scale in a sandbox and large-scale in {{fraction}} before it was redirected to {{frac}}. The feature had been suggested in MOS Talk.

I don't use a screen-reader, so I could only test for code correctness, not for actual usefulness to improve accessibility. If users more knowledgeable in this regard would kindly confirm that automatically spelt-out fractions actually do increase accessibility, I'd then ask for an edit of this protected template. -- Christoph Päper 17:02, 17 March 2014 (UTC)

Several issues:

1. A fraction is not and abbreviation, so using <abbr>...</abbr> is semantically incorrect.
2. font-variant-numeric is only a draft and not supported by any browser, and would conflict with the formatting as it is currently generated (it will only automatically convert fractions given as "1 2/3" to produce 1 ²/₃).

-- Edokter (talk) -- 18:00, 17 March 2014 (UTC)

"1/8" abbreviates ".125". ;) It's about as semantic a use as sup and sub here. Some microformats stretch the meaning of abbr much more. Anyway, if title expansion in screen-readers only works for abbr we have to use it and if it does not I'm fine with span.

CSS Fonts 3 is a Candidate Recommendation. That means it's unlikely the specification for font-variant-numeric will change (especially in any incompatible way). A W3C CR nowadays is about as stable as a REC a few years ago. It's safe to use in stylesheets, even if browser support is spotty. How frac works exactly, depends on the font. It's true that 2/3 is probably a bit better supported than 2/3, although the latter slash character was intended for this very usecase. If I remember correctly there's nothing that stops a browser from applying font features to a text run that spans several elements as in <sup>2</sup>/<sub>3</sub>. -- Christoph Päper 15:13, 18 March 2014 (UTC)

I have seen candidate recomendation change, so nothing is set. Also, there is no telling what wil and will not work with diagonal-fractions; The docs only give an example with a common slash, not a fraction slash, and I'll bet it will only convert a common slash, as that is 'typable'. And yes, the title attribute should work on all elements. -- Edokter (talk) -- 16:29, 18 March 2014 (UTC)

The font-variant-numeric: property is described in CSS Fonts Module Level 3 W3C Candidate Recommendation 3 October 2013.

The title= attribute is one of those known as "global attributes" in HTML5 or as "core attributes" in HTML 4.01 that may be used on any element that is itself valid for use in the body section. --Redrose64 (talk) 18:19, 18 March 2014 (UTC)

(If that was a reply to me) I studied it extensively. It is nowhere near implementation in actual browsers... maby next year. What might work is exploiting the font-features property that does have (some) support: If I type 1 2/3, then the following should appear as a common fraction: 1 2/3. But that also renders way too small, and the "1" should not be small (I saw another website where it did appear corrrect... still wrecking my brain why it doesn't work here turns out used font must support it. I hope font-variant-numeric may emulate OpenType support with non-conforming fonts). -- Edokter (talk) -- 19:25, 18 March 2014 (UTC)

Oh no, not you specifically: it was a FYI for anybody curious as to what a "candidate recommendation" might be or what a title attribute might do. --Redrose64 (talk) 20:17, 18 March 2014 (UTC)

Of course, title is global and can be used with every HTML element type, in theory. The important question was whether, where and how screen-readers make use of it, in practice, because it gained special meaning for the abbr element type, where it usually holds the expansion of the contained abbreviation..

Wikipedia absolutely should not use the low-level interface that is provided by font-feature-settings (even less so with vendor prefixes). It's intended for future and more exotic features. Since several browsers implement this one already, though, it shouldn't take too long for them to support the standardized higher-level properties as well.

You can use custom files with any font in LuaTeX, but nothing like that has been proposed for CSS yet. Font features work on glyphs (not characters) and since their names are arbitrary (though there are de facto standard industry practices whereas characters are standardized by Unicode) browsers could hardly emulate them. (It could work for frac to some extent, because the glyphs associated with superscript and subscript digit characters could be reused.) Furthermore, the current CSS Font editor is very much opposed to such kinds of emulation, incl. fake bold, fake italics and fake small-caps. -- Christoph Päper 15:36, 21 March 2014 (UTC)

I think it is way too early to implement this code, primarily due to zero browser support, and potential conflicting formatting once the properties do become active. I don't get your comment about font-feature-settings; according to the recomendation draft, the intended effects and mechanisms are synonymous. -- Edokter (talk) -- 17:05, 21 March 2014 (UTC)

You only mean the font-variant-numeric part (3.2) I assume. Fair enough, since that's just additional sugar not needed for improved accessibility, I can live without it for now.

What about the abbr (1.) and, most important, title (2.) parts, though? -- Christoph Päper 21:24, 21 March 2014 (UTC)

I think <abbr> is unnecessary, as fractions are not technically abbreviations. The title attribute has no special meaning here, it works just as well on spans in screenreaders. Still begs the question if the auto translation is a desired functionality. -- Edokter (talk) -- 22:17, 21 March 2014 (UTC)

Font problems within collapsed templates?

Please see Template:Timeline_of_the_Lewis_and_Clark_Expedition and expand the template. Scroll down to the bullet "October 8-11" under the 1804 heading and you'll notice that it is a different font size. This is caused by the usage of {{frac}} directly above it in "September 25-29"; if it is removed, the problem no longer occurs. Why is this happening? Browser is Firefox 34.0.5, if it matters. -- 143.85.169.18 (talk) 20:27, 29 December 2014 (UTC)

This has nothing to do with frac... the template was so poorly formatted that it caused HTML Tidy to mess up the whole template. -- [[User:Edokter]] {{talk}} 22:27, 29 December 2014 (UTC)

I love frac. So can I get exp?

I love frac. Love it. It makes typing fractions into the Wiki way easier, and they render great. ¹/₃ looks a whole lot better than 1/3.

Better yet, since you don't use tags, any mistakes just leaves a little extra editing cruft in the article, as opposed to even a single missing character in a tag, which can render the entire rest of the article into the bit bucket.

So...

Can I get an exp template? Something so I can type 10⁷ like {{exp|7}}? Or {{exp|2|7}} instead of 2⁷.

Or maybe such a thing already exists?

Maury Markowitz (talk) 20:19, 1 April 2015 (UTC)

There is {{sup}}. There is no separate template for exponential numbers as it requires no special formatting. -- [[User:Edokter]] {{talk}} 20:34, 1 April 2015 (UTC)

However, there is {{val}} which is useful for scientific notation. Jimp 00:29, 2 April 2015 (UTC)

Yes, SUP is what I was looking for... but then thinking about it, is there something for "multiply-sign, 10, superscript-some-number"? SUP handles the last part, but typing the sign and NBSPs could be improved! Maury Markowitz (talk) 15:29, 15 June 2015 (UTC)

As I mentioned, you can use {{val}}. {{val|2|e=7}} gives "2×10⁷". You also might like {{e}}. {{e|7}} gives "×10⁷". Jimp 13:16, 3 July 2015 (UTC)

Formatting

I might be nice if we had a formatting parameter (say |fmt=) to format numbers. {{frac|12345|54321|67890|fmt=gaps}}, for example, would be easier than {{frac|{{val|12345}}|{{val|54321}}|{{val|67890}}}}. Jimp 04:06, 25 November 2015 (UTC)

{{Val}} itself already handles this. -- [[User:Edokter]] {{talk}} 11:56, 25 November 2015 (UTC)

{{Val}} does the formatting but it doesn't do fractions. Likewise, {{frac}} does the fractions but it doesn't do the formatting. You can put {{val}} inside {{frac}} but this is a bit cumbersome. I'm suggesting we have a template which does both. {{Val}} is complicated enough without adding the capacity to produce fractions to it but adding the capacity to format numbers to {{frac}} would be easy. Jimp 04:39, 26 November 2015 (UTC)

Here's the kind of thing I'm talking about.

• {{frac/sandbox|1234|67890|fmt=gaps5}}   ->  ¹²³⁴/₆₇₈₉₀
• {{frac/sandbox|1234|67890|fmt=gaps}}     ->  ¹²³⁴/₆₇₈₉₀
• {{frac/sandbox|1234|67890|fmt=commas}} ->  ¹²³⁴/₆₇₈₉₀

Jimp 05:40, 26 November 2015 (UTC)

I've changed the sandbox to just pass through the optional fmt parameter, which means that {{val}} is always invoked and maybe should use another default value (currently empty).

Template:frac/testcases#Parameter test

That doesn't work well enough because {{val}} doesn't fall back gracefully if its mandatory argument is not a number. I thin that should be fixed there and not here. -- Christoph Päper 10:26, 26 November 2015 (UTC)

Yes, I'd thought of doing it that way but realised that this problem would arise. Yes, tweaking {{val}} might be good but that would have to be brought up at {{val}}'s talk page (my Lua skills aren't up to the task). There are a couple of other potential problems with always passing through {{val}} (though they may not be huge). Firstly, it may add significant processing time (though now {{val}} has gone Lua that might not be such a problem). Secondly, it would bloat {{val}}'s transclusion list with a load of irrelevant pages. Alternatively, we could skip {{val}} altogether (or perhaps mostly) and use {{formatnum:}} and Module:Gapnum instead. Jimp 12:42, 26 November 2015 (UTC)

I've replaced the {{val}} call in the sandbox with a call to {{frac/output}} (repurposed, at least for now, to do formatting). It seems to be working okay. Jimp 13:59, 26 November 2015 (UTC)

As with manually opting in to Unicode precomposed glyphs, I can't see how anyone would want to add a parameter each time they use this template on a page, and always in the same way. What they would really want was a "local locale" declaration, i.e. metadata for every article that tells the software (incl. templates) how the formatting on this page should differ from the global default. Logged-in users would also be able to enforce their custom settings. I guess that's also why we still have {{sfrac}} instead of {{frac|style=stacked}}. -- Christoph Päper 10:36, 27 November 2015 (UTC)

A local locale declaration would be great if they could get it working but in the meaning time our options are add a parameter to this or write a whole new template. My perspective is that having fewer templates with greater functionality makes editing more straightforward. There may be more typing to do but this is outweighed by the time spent searching for the specific template you're after. Another point is that by including them using parameters, we can combine functions. For example, say we were to create {{gfrac}} for gap formatting, what about stacked-style gap formatting? You'll have to create a whole new template for each combination. I'd have done the same with stacked style, then there'd be no problem, {{frac|1234|fmt=gaps|style=stacked}}. Jimp 23:57, 27 November 2015 (UTC)

If separate templates are easier for editors to use, then that is what should be done instead of creating one monolithic template (like val) with a steep learning curve in parameter use. -- [[User:Edokter]] {{talk}} 10:05, 28 November 2015 (UTC)

Yes, if they are easier to use. We're not really discussing complexity of the likes of {{val}} here we're just considering adding a single parameter. In general, I'd say that adding parameters makes things easier than reinventing the wheel. Sure, {{val}} is monolithic but imagine if we had a separate template for each combination of functions it does, that would go beyond being a steep learning curve and into the realms of nightmare. Jimp 00:41, 3 December 2015 (UTC)

... I wonder whether {{val}} really is too complicated to add fractions to. Jimp 04:47, 15 April 2016 (UTC)

Text wrapping

I just noticed that this template doesn't prevent wrapping within it; it wrapped at 1/ [break] 8, which is clearly bad. Can someone apply white-space: nowrap; to the code, please? -- OwenBlacker (Talk) 20:39, 24 April 2016 (UTC)

It already has the .nowrap class. Chrome has a bug that may occasionally let it break anyway. -- [[User:Edokter]] {{talk}} 21:04, 24 April 2016 (UTC)

Bug in mobile app related to this template

Hey, I just opened a bug report which is related to this template and post it here, in case somebody wants to contribute. Cheers --CaZeRillo (talk) 09:38, 29 September 2016 (UTC)

Forgot to include the screenshot. --CaZeRillo (talk) 09:42, 29 September 2016 (UTC)

Template-protected edit request on 17 January 2017

The display with pure HTML default super/subscripting is suboptimal. It's worse than with Unicode super/sub scripts. I'd suggest apply some CSS fine tuning. Thanks. Hnvnc (talk) 10:41, 17 January 2017 (UTC) Hnvnc (talk) 10:41, 17 January 2017 (UTC)

Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. Cabayi (talk) 11:53, 17 January 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)

Source of the article : Wikipedia