Template talk:Fraction/Archive 1

Possible code
Matter of 2&thinsp;3⁄4, 2 3⁄4, 2&#x2064;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)

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)

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-$2 3/4$ ", not "" 4$2 3/4$ ", and to generate a hyphen automatically when the third parameter is used. The weird + 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  &#91;talk&#93; &#91;cont&#93;  ‹(-¿-)› 21:12, 9 May 2007 (UTC)
 * The template should be used like this:, although it works also almost the same with this :.
 * 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 ‘&frasl;’ vs. plain old ‘/’. Christoph Päper 20:44, 13 May 2007 (UTC)


 * In principle at least, speech browsers should ignore " ". There's a separate declaration, " " for those .  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,  does affect non-visual display. —Ms2ger (talk) 19:39, 2 February 2008 (UTC)

Do you need &lt;BIG> ?
Not using &lt;BIG> gives a better look for me:

$1/undefined$ $1/undefined$ $2 3/4$ 3 1⁄2 3 1⁄2  3 1⁄2

The latter three don't use &lt;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) • (yo?); 16:25, 15 April 2008 (UTC)

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

+pl:Szablon:U
Please add pl interwiki: pl:Szablon:U. 83.29.153.144 (talk) 12:27, 27 April 2008 (UTC)
 * ✅ Happy‑melon 14:12, 27 April 2008 (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. —  &#x7B;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. —  &#x7B;talkcontribs 11:15, 7 September 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  and 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? — ¾-10 16:12, 28 December 2008 (UTC)
 * ⅛ ¼ ⅜ ½ ⅝ ¾ ⅞ 1 — eighths series
 * ⅓ ⅔ — thirds series
 * 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) • (yo?); 17:58, December 29, 2008 (UTC)


 * Thanks! — ¾-10 01:39, 30 December 2008 (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 .--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)

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 2                                    2+^3⁄[4]   $3/4$                                           2[DEL: + :DEL] ^3⁄[4] 2 3/4                                                   2 3/4   23/4 2^3/[4]   2 3 / 4     2^3/[4]   2 3/4                2^3/[4]   2 3&amp;frasl;4          2^3⁄[4] 2 3&amp;frasl;4                                             2 3⁄4 2 3⁄4                                                   2 3⁄4   23⁄4 2^3⁄[4]   2 3 ⁄ 4     2^3⁄[4]   2 3⁄4                2^3⁄[4]   2 2 ⁄ 3  2^2⁄3   2&amp;frac34;                                                2¾ 2¾                                                      2¾

Speech browsers will undoubtedly have similar issues.&mdash; 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) • (yo?); June 1, 2010; 14:24 (UTC)
 * Upon further reflection, I've decided to nominate this for deletion, so please respond there. Nothing personal.&mdash; 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. &mdash; Chowbok  ☠  14:56, 1 June 2010 (UTC)


 * Discussed at Templates for discussion/Log/2010 June 1:
 * "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 ―Œ (talk) 01:37, 9 June 2010 (UTC)"
 * — Richardguk (talk) 23:02, 20 June 2010 (UTC)

Why?
It seems like it would be nice to have a Fraction template where you could write 1 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. &mdash; Martin (MSGJ · talk) 14:59, 2 July 2010 (UTC)

sfrac: Nested fractions
Nested fractions render incorrectly in Mozilla/Chrome: renders as

Same code with my experimental code from sfrac/sandbox (it works in Google Chrome / Mozilla / IE7, I haven't tested other browsers):. Also compare $3 1/2$ (current template) with (sandbox template). //  st pasha  » 06:33, 3 November 2010 (UTC)

Appearing of frac i certain browsers.
See Wikipedia_talk:Manual_of_Style for the discussion. Headbomb {talk / contribs / physics / books} 23:30, 3 November 2010 (UTC)

Behavior with no parameter specified
In Templates for discussion user:76.65.128.198 suggested that frac should output a fraction slash only, i.e. ‘&frasl;’. This can easily be done with another  (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  s so we’re able to hide them more reliably. — Christoph Päper 16:31, 14 December 2011 (UTC)
 * Sensible suggestion. ✅. Could you update the documentation as appropriate? &mdash; 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 to copy as "12&frasl;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&#x2064;2&frasl;3  — 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  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 - 2&frasl;3. 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 - 2&frasl;3 . And a 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 - 2&frasl;3. — 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 "$3 1/2$" 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. J IM ptalk·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 concerning potential accessibility issues with. -- Red rose64 (talk) 10:00, 6 July 2012 (UTC)
 * They're more than "possible".  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)
 * also avoids vulgar fractions that aren't only "unicode", such as ½ and ¾, for reasons that have never been adequately explained.&mdash; Chowbok  ☠  23:49, 20 November 2012 (UTC)


 * Please post at Wikipedia talk:WikiProject Accessibility/Archive 3, not here, to avoid a split discussion. Thanks. -- Red rose64 (talk) 07:18, 21 November 2012 (UTC)

advertise template:sfrac
Per discussion at Wikipedia talk:Manual of Style/Dates and numbers, 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. 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) • (yo?); November 26, 2012; 15:07 (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. —sroc (talk) 00:48, 9 July 2013 (UTC)

sfrac: Single input
✅ gives $3 1/2$ but gives. I find the behaviour of frac much more useful. How often you you want 1 in the denominator?J IM ptalk·cont 05:11, 2 February 2011 (UTC)
 * Behavior has been synchronized some time ago. — Christoph Päper 18:28, 6 September 2013 (UTC)

Unify frac and sfrac
Let’s assume there was a class  – which is not a good name – that contained this code or something similar, e.g. using negative. To make the code more readable, let’s also assume the denominator and numerator  styles would come from a central stylesheet, not a   attribute:

As you can see, there would be only few adjustments necessary – i.e. more wrapping s – to unify frac and sfrac. Since these are frequently used templates, their style might go into common.css where generic  would make vulgar fractions like current frac and   would generate stacked fractions using the same HTML base. Two possible code variants follow below. (We don’t have to keep using  and , 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)

Sfrac: accessibility with screen readers
Before my edit to the template, Sfrac did not read correctly with screen readers; they would read $2 3/4$ 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 $∂2 f⁄∂x2$ 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? Graham 87 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? — <span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius  ♪ talk ♪ 11:21, 19 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

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 [//en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template_talk:Frac&hidelinks=1 redirect here]. -- Red rose64 (talk) 16:12, 6 March 2014 (UTC)
 * Currently, only fraction uses the HTML element  and includes code to generate a   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 . 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, 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 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 ), like this.

Then at the subtemplate we could put together a reduced fraction using the  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 s).

title=""

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

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 still exist?
Fraction uses pre-composed glyphs, which, as noted on the frac doc page is discouraged by MOS. 's own doc page says that it's deprecated. It was resurrected in 2010 after three years of being redirected to. The idea seemed to be to create "nicer-looking common fractions". I'm not convinced that the current output of is nice-looking at all. Firstly, the output is inconsistent. There are three possible outputs you might get which I'm listing below. So by using this template you could get "⅞" and "⅒" alongside "3/10" and "1/12" alongside "⅟15" "⅟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  in   and in the mean time reinstate the redirect to ? Jimp 12:10, 12 March 2014 (UTC)
 * 1) A Unicode character (which MOS:FRAC states are "discouraged entirely, for accessibility reasons among others", e.g. "⅜") 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 "⅟" plus something (e.g. "⅟12") This is just weird. I really don't get the idea here. In what sense is "⅟16", "⅟20", "⅟32", etc. nice-looking?
 * 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. — <span style="color: #194D00; font-family: Palatino, Times, serif">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  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  code is going to help the fact that "⅓" 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 "⅟", 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 a redirect again. Jimp 13:54, 12 March 2014 (UTC)
 * See also (above), Wikipedia talk:WikiProject Accessibility/Archive 3 and most recently, Village pump (technical)/Archive 124. Those are just the ones that I've commented in: there may be others. -- Red rose64 (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 to  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 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 is not a good generic fraction template and neither is, 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   (and   for ) 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 .) 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  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  was doing, producing "nice-looking" fractions, was of no use (it was detrimental).  Anyhow, I'm glad there are no objections to having  redirected to . Jimp 09:37, 17 March 2014 (UTC)

Explanation
The code above contains these proposed changes from current code:

All of this has been tested small-scale in a sandbox and large-scale in before it was redirected to. The feature had been suggested in MOS Talk.
 * 1) Change from   to   element type.
 * 2) Add   attribute and   parameter. The new optional parameter can be used to override the result of calling the   module. This shouldn’t be necessary often, though.
 * 3) Add   attribute.
 * 4)   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.
 * 5)  to enable the   Open Type feature in browsers that implement |CSS module Fonts level 3. This has an effect only if the font also supports it.

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:
 * A fraction is not and abbreviation, so using <abbr ></abbr> is semantically incorrect.
 * 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 $2$).
 * — Edokter  ( talk ) — 18:00, 17 March 2014 (UTC)
 * “1/8” abbreviates “.125”. ;) It’s about as semantic a use as  and   here. Some microformats stretch the meaning of   much more. Anyway, if   expansion in screen-readers only works for   we have to use it and if it does not I’m fine with.
 * CSS Fonts 3 is a Candidate Recommendation. That means it’s unlikely the specification for  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   works exactly, depends on the font. It’s true that   is probably a bit better supported than , 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  . — 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  property is described in CSS Fonts Module Level 3 W3C Candidate Recommendation 3 October 2013.
 * The  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. -- Red rose64 (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  property that does have (some) support: If I type 1 2/3, then the following should appear as a common fraction: <span style="-moz-font-feature-settings: 'frac' 1; -webkit-font-feature-settings: 'frac' 1; font-feature-settings: 'frac' 1;">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. -- Red rose64 (talk) 20:17, 18 March 2014 (UTC)
 * Of course,  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   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  (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 |feature 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  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  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  (1.) and, most important,   (2.) parts, though? — Christoph Päper 21:24, 21 March 2014 (UTC)
 * I think 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)

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: --<SPAN STYLE="font-family:monospace; color:#008800; background-color:#ffffcc; border:1px solid #ff4444;"> B.D.Mills </SPAN> (T, C) 12:38, 26 January 2009 (UTC)
 * [sup]1[/sup][big]/[/big][sub]5[/sub] works, gives <SUP>1</SUP><BIG>/</BIG><SUB>5</SUB>
 * [sup]1[/sup]&frasl;[sub]5[/sub] does not work, gives <SUP>1</SUP><SUB>5</SUB>


 * Retesting this with real code:

and it looks perfectly fine in modern Firefox. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:30, 20 October 2014 (UTC)
 * 1&frasl;5

Tightening formatting (Fork from Wikipedia talk:Manual of Style (mathematics))
This template has been discussed at Wikipedia talk:Manual of Style (mathematics). 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 100 ⁄ 200 to 100 ⁄ 200. The first one is

The same formatting compares well with the precomposed symbol (compare: 1 ⁄ 2 ½). While that does use the  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  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:
 * 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)
 * 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  than the  ), but it's not insanely awful.  The current output of the template looks better, compared side by side: Current template: $2$ 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:   – 1 &frasl; 2 (But I'd bet good money it looks like crap is some other browser.)  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:41, 20 October 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 1/undefined 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.  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. $1 2/3$ 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 107 like ? Or instead of 27.

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.  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 .   gives "$1/undefined$".  You also might like e.    gives "". Jimp 13:16, 3 July 2015 (UTC)

Formatting
I might be nice if we had a formatting parameter (say ) to format numbers. , for example, would be easier than. Jimp 04:06, 25 November 2015 (UTC)
 * Val itself already handles this.  11:56, 25 November 2015 (UTC)
 * does the formatting but it doesn't do fractions. Likewise,  does the fractions but it doesn't do the formatting.  You can put  inside  but this is a bit cumbersome.  I'm suggesting we have a template which does both.   is complicated enough without adding the capacity to produce fractions to it but adding the capacity to format numbers to  would be easy. Jimp 04:39, 26 November 2015 (UTC)
 * Here's the kind of thing I'm talking about.
 * 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
 * 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  might be good but that would have to be brought up at 's talk page (my Lua skills aren't up to the task). There are a couple of other potential problems with always passing through  (though they may not be huge).  Firstly, it may add significant processing time (though now  has gone Lua that might not be such a problem).  Secondly, it would bloat 's transclusion list with a load of irrelevant pages.  Alternatively, we could skip  altogether (or perhaps mostly) and use  and Module:Gapnum instead. Jimp 12:42, 26 November 2015 (UTC)
 * I've replaced the 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)
 * 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  might be good but that would have to be brought up at 's talk page (my Lua skills aren't up to the task). There are a couple of other potential problems with always passing through  (though they may not be huge).  Firstly, it may add significant processing time (though now  has gone Lua that might not be such a problem).  Secondly, it would bloat 's transclusion list with a load of irrelevant pages.  Alternatively, we could skip  altogether (or perhaps mostly) and use  and Module:Gapnum instead. Jimp 12:42, 26 November 2015 (UTC)
 * I've replaced the 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 . — 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  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, . 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.  10:05, 28 November 2015 (UTC)


 * Yes, if they are easier to use. We're not really discussing complexity of the likes of  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,  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 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  to the code, please? — OwenBlacker (Talk) 20:39, 24 April 2016 (UTC)
 * It already has the  class. Chrome has a bug that may occasionally let it break anyway.   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)
 * Red information icon with gradient background.svg Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. Cabayi (talk) 11:53, 17 January 2017 (UTC)

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


 * 23/4

to
 * 23/4

But wikipedia is for the consumer; some readers may want to see
 * $$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  and , 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  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  ⅓, ⅔, ⅛, ⅜, ⅝ and ⅞, 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 222 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   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   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  &#91;talk&#93; &#91;cont&#93; ‹(-¿-)› 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 . -- 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)

Math
gives or. —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) • (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:  -- Hnvnc (talk) 16:48, 18 January 2017 (UTC)