Template talk:Su

Bug when using same value for "p" and "b"

Why is the ‘p’ parameter ignored when it has the same value as the ‘b’ parameter, e.g., {{su|p=2|b=2}}, which would seem a reasonable use for the template)? JeffConrad (talk) 04:34, 11 August 2008 (UTC)

That's a coding mistake that I made; normally {{su}} will create HTML to put the "p" and "b" parts in the right location. If you only supply "p" and not "b" (or the other way around), I tried to make the code smart and have it use <sup> or <sub> rather than the complex HTML required to put one above the other. Unfortunately, this "smart" code has a bug where it drops the "p" part if "p" and "b" are the same. The template is currently protected, so I can't fix this - I'll try to track down who protected it and get access to make a fix.

To anybody reading this: let me know if you can help me get access. I wrote the original, I think I should have access to it to fix such bugs :)     — SkyLined {^talk_contribs 12:16, 17 August 2008 (UTC)

From what I've read, I think that using {{editprotected}} should get somebodies attention: {{editprotected}}

I'm not quite sure if this is the right thing, as {{su}} is marked as semi-protected, which should give me access, but I can't edit it, so something seeems off.    — SkyLined {^talk_contribs 12:37, 17 August 2008 (UTC)

Not done: The reason the template is currently protected is because it is transcluded onto today's featured article, which has its templates cascade-protected to prevent vandalism. When the template comes off TFA, it will be automatically unprotected, and you'll be able to edit it. Happy‑melon 16:16, 17 August 2008 (UTC)

> 24 hours later and the template is still protected...     — SkyLined {^talk_contribs 15:35, 18 August 2008 (UTC)

Fixed.     — SkyLined {^talk_contribs 20:47, 22 August 2008 (UTC)

IE6

Well, i finally got it working in FF2 and IE7 - turns out it doesn't work in IE6: the sub-script is too low, the sup-script is invisible. I've not looked into it, I don't know why this happens. :(     — SkyLined {talkcontribs 03:59, 5 May 2008 (UTC)

A simpler approach

Your CSS seems overly complicated. Please evaluate and consider the following approach:

X_cd X^{ab Xab_cd}

It has the advantage of being more semantic . The declarations for ADSCRIPT are in my style sheet.

--Yecril (talk) 10:27, 10 June 2008 (UTC)

The reason why I created {{su}} in the first place is to be able to have supscript OVER subscript. This is impossible using your approach.     — SkyLined {^talk
_contribs 15:20, 11 June 2008 (UTC)

For unknown reasons, this fix was reverted!? I fixed it again.     — SkyLined (talk) 11:51, 14 June 2009 (UTC)

CSS complexity/problem with IE 7

The CSS for the combined subscript and superscript also seems a bit complicated (and fragile) to me; moreover, the vertical alignment with IE 7 doesn't always come out right. For example, when an instance with both sub and super is followed on the same line by an instance with only a sub:

X³
₂

and

X³
₂ X³
₂

work fine, but

X³
₂ X
₂

does not. I see a similar but less severe problem with Opera 9.5; all work fine with Firefox 3 and Safari 3.1.

For what it's worth, you might want to see what I did with {{SubSup}}. I had a slightly different primary purpose (HTML-coded inline mathematics matching the surrounding text), so I put the first argument in italics and made the subscripts and superscripts the same size under all circumstances, but the approach is otherwise similar. JeffConrad (talk) 00:40, 18 August 2008 (UTC)

The reason why it so complex is because I made it compatible with FireFox 2 (at the expense of IE6 it seems). Your solution is not compatible with FireFox 2, as you can see here:

If you can find a way of making it work on IE6/7/8, FF2/3, Opera and Safari, that would be great :)     — SkyLined {^talk_contribs 17:25, 28 August 2008 (UTC)

Horizontal lineup problems when placed in <small> tags

• The regular X⁺³⁶
  _-24 looks fine. (Could be a weeeeeeeeeeeee bit higher if you ask me, but thats a rather minor complaint)
• The errors in X⁺³⁶
  _-24 don't line up properly for me. They are slightly lower than they should be. This is more of a problem. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 14:52, 31 May 2009 (UTC)

(Copied and adjusted from {{val}} by     — SkyLined (talk) 21:53, 4 June 2009 (UTC))

TOC compatibility: x^a
₊

Is it possible to have the template display something reasonable in the TOC? Sławomir Biały (talk) 20:29, 22 November 2009 (UTC)

Up-down alignment for all browsers & fontsize=80%

21-Dec-2010: I have added new parameter fontsize=80% to alter the size of the superscript and subscript text. I have changed Template:Su to work on all browsers, including Microsoft Internet Explorer 6 (IE6), by using a vertical alignment of the superscript and subscript. I have added extensive NOTES comments inside the template to explain the markup coding and logic flow. -Wikid77 (talk) 09:08, 21 December 2010 (UTC)

Great job! I made some minor changes, like bypassing the sub and sup templates and using the correct <br />. — Edokter • Talk — 12:01, 21 December 2010 (UTC)

The new version of the template is broken in Konqueror, where it worked before. I am also skeptical about other changes made to the template, for example "display:-moz-inline-box;-moz-box-orient:vertical;" in the original was there presumably because of older versions of Firefox that did not support "display:inline-block". Why was it removed? It seems to me that the changes were done hastily without proper testing, and that Wikid77's (demonstrably false) claim about it working on "all browsers" really only means that it works in his browser.—Emil J. 15:10, 21 December 2010 (UTC)

• Trying other alignments for more browsers - There are other possible ways to get the vertical alignment, such as "line-height:1.1em" and we could try other margin changes:

• T1. Using "line-height:1.1em" -  X{{{p}}}
  {{{b}}}     or X12345678
  abcd

• T2. Including "text-align:right" (or left) -  Xaaaa
  b     or X12345678
  abcd

• T3. Plus text-align & "margin-bottom:-.1em" -  Xaaaa
  b     or X12345678
  abcd

All options T1, T2 or T3 work in IE6 or Firefox. What about other browsers? Does option T3 show a better alignment? -Wikid77 16:18, 21 December 2010 (UTC)

I have taken the liberty to add a base letter to your examples so that the alignment is better visible. Otherwise, there is basically no change: all three variants look OK in Firefox (3.5.5) and Opera (9.27), but none of them works in Konqueror (3.5.8): the subscript is more or less aligned with the base letter, and the superscript flies high above. T2 and T3 look slightly better than T1 as the gap between the subscript and superscript is reasonable, but the main problem I think is that the browser does not interpret the "vertical-align: -0.4em" the way you want it to.—Emil J. 17:15, 21 December 2010 (UTC)

I also think it would be a good idea to get User:SkyLined's opinion on this.—Emil J. 17:17, 21 December 2010 (UTC)

More variations: Consider the following alternatives:

• T4. With "margin-bottom:-0.3em" -  Xaaaa
  b     or X12345678
  abcd
• T5. Omit "vertical-align:-0.4em" -  Xaaaa
  b     or X12345678
  abcd

Option T5 raises both super/subscript slightly in IE6. I have changed Template:Su to use "line-height:1.1em" to better support Konqueror (3.5.8) and combined as 1 <span> tag to allow "text-align:right" in IE6 (which often does not inherit from a prior style="..."). -Wikid77 (talk) 18:43, 21 December 2010 (UTC)

T4 is much better: in Konqueror it corrects the subscript position; the superscript is still too high, though not as high as before. It continues to work OK in Firefox and Opera. T5 is broken in all three browsers, in Firefox and Opera it makes the subscript appear above the baseline.—Emil J. 19:00, 21 December 2010 (UTC)

Monospace

X⁵⁶⁷⁸
₁₂₃₄ (not fixed)

X⁵⁶⁷⁸
₁₂₃₄ (fixed)

X
₁₂₃₄ (b only)

X⁵⁶⁷⁸
(p only

Monospace (|w=f) only work when both b and p are used. I don't know if that is intended. Also, the way how it is implemented is not very reliable; on Mozilla and Webkit based browsers, the font becomes way too small, inelligable even. One way of fixing that would be to use font-family:monospace, "Courier New";, or to just use <tt> instead, which assigns the proper font-family in common.css. — Edokter • Talk — 19:16, 21 December 2010 (UTC)

Also, 80% is a bit arbitrairy. If you use font-size:smaller;, it will be consistent with <sup and <sub. Scrap that. Better is to use 85%; it matches sub and sup better accross browsers. — Edokter • Talk — 19:25, 21 December 2010 (UTC)

Shouldn't the generic family come last? Otherwise there is no way how anything after it could match.—Emil J. 19:26, 21 December 2010 (UTC)

No, that's the whole point. Monospace always matches. There can be anything after 'monospace' to trigger correct behaviour from those browsers. — Edokter • Talk — 19:49, 21 December 2010 (UTC)

Rewriting logic to always format the same

21-Dec-2010: Now that we have people, this week, testing the results, I think we should totally rewrite the template in a logical manner: always assume either {p}, {b} or both will be specified and check them, each, without nesting the #if logic:

Always use a <span> tag, and expect either {p} or {b}:

<span style="vertical-align:-0.4em; line-height:1.1em;
             margin-bottom:-0.3em;...">{{
#if:{{{p|}}}|{{{p}}}}}{{
#if:{{{b|}}}|<br />{{{b}}}}}</span>

(No longer use <sup> or <sub> tags for single cases.)

Hence, the font-size and "w=f" monospace options would apply to all cases, and single superscripts or single subscripts would be of identical placement to both combined, because every case would use the same span-style settings. That is how I would have originally designed the template to avoid different sizes/positions of subscripts or superscripts. Even though the large HTML span-tag is issued for every possible usage, it would be better than risk future changes might cause different font-sizes for single superscript or subscript. Having the font-size & font-family in just one span-tag ensures all forms will maintain identical alignment. Does that seem better? -Wikid77 (talk) 20:16, 21 December 2010 (UTC)

Look in the sandbox; working single-span version. Checked in IE, Firefox and Chrome. As a side note: Why is monospace needed? — Edokter • Talk — 22:23, 21 December 2010 (UTC)

I thought we needed "margin-bottom:-0.3em;" not -0.2, but so far we get:

• X{Su/sandbox|p=aa}X{Su/sandbox|b=bb}X{Su/sandbox|p=aa|b=bb} → X⁠^aa
  ⁠X⁠
  _bb⁠X⁠^aa
  _bb⁠

The monospace font can appear cleaner for letters such as "vwrn" which might appear jumbled in arial font on some browsers:

• X{Su/sandbox|p=vwrn|b=wvw}X{Su/sandbox|p=vwrn|b=wvw|w=f}Y → X⁠^vwrn
  _wvw⁠X⁠^vwrn
  _wvw⁠Y

How did Chrome handle "margin-bottom:-0.3em" (option T4 above)? Konqueror did not support "vertical-align:-0.4em" and might need "line-height:1em" not 1.1em. -Wikid77 22:54, 21 December 2010 (UTC)

There is a slight difference between no margin and -0.1em, but going further down does not show any difference in Chrome. — Edokter • Talk — 23:37, 21 December 2010 (UTC)

Noincluded parameters need line-height 1.2: I changed Template:Su/sandbox to show some noincluded parameters (an accuracy technique I often use to proofread results faster), and sure enough, I detected the problem where "line-height:1.1" is too small for IE6 to display the lower hook on subscript "gH". Because few of us have time to check every extreme case, separately, the accuracy technique is to always use noincluded parameters, such as:

• Inside {{{b|}}}, put: <noinclude>{&#123;{b&#124;gH}}}</noinclude>.

That noincluded parameter value (omitted from formatted articles) will display as "{{{b|gH}}}" to tell the reader the parameter is "b" but also show the test-value as "gH" with extreme lower hook on "g" and tall letter "H". Then, while casually looking at template pages, many performance problems can be spotted simply by looking at the noincluded default results, chosen to be most likely to show problems if the template is changed. That saves us time, when you know we need to be fixing 100 (500?) other very important templates. Also, tag "<includeonly>" is the evil enemy of seeing these noincluded defaults. I often nix "includeonly" and set noincluded defaults to avoid parser errors. This trick also requires remembering codes &#123-&#124-&#125 to easily embed the characters "{-|-}" within those parameter defaults. Anyway, I'm thinking we might have to leave Konqueror (3.5.8) with a high superscript because "line-height:1.2em" is the minimum required by IE6 to show "g". At least Konqueror will show a good subscript while a too-high superscript. I can also confirm many readers are stuck with IE6 due to Microsoft making IE7, IE8 (etc.) too big to use. Also, many fragile laptop computers are dying, leaving users to run old, reliable desktop computers with IE6. We must fix these simple text templates, while knowing Wikipedia needs to have very clever video templates for the future. -Wikid77 03:23, 22 December 2010 (UTC)

I updated Template:Su (22Dec10) with the latest ideas, setting {b} as &nbsp to force a lone superscript, plus "line-height:1.2em" for IE6 subscript "g". I also omitted "text-align:left;" to shorten the HTML <span> tag, only putting such style options when not the default settings. I guess we need to check Firefox 2, but since Firefox tends to force users to accept updates, I don't think many FF2 users exist. It's not like IE6, where the usage stats prove that IE6 is still widely used. Like all of us, I need to improve several other templates, but will check back here later. -Wikid77 06:28, 22 December 2010 (UTC)

----

Thanks Wikid77! I spent hours, if not days, trying to come up with something that worked on all browsers when I created this 3 years ago: imagine my surprise when I saw how simple your solution is! I confirmed that your solution works with:

• Chrome 8(Win7) & 10(Win7)
• Firefox 3.5(WinXp), 3.6(Win7), 4.0 beta(Win7)
• MSIE 6 (WinXP), 7 (WinXP), 8(Win7), 9(Win7)
• Opera 10(Win7) & 11(Win7)

IIRC the -moz-* stuff was indeed there to make things work on FF2, but I believe it is safe to say there are a lot less FF2 users than IE6 users.

    — SkyLined (talk) 10:20, 22 December 2010 (UTC)

I confirm that the current version behaves as I wrote above: it works on Linux for Firefox 3.5.5 and Opera 9.27, while for Konqueror 3.5.8 the superscript is too high. Given its market share, I think this is acceptable.—Emil J. 14:01, 22 December 2010 (UTC)

Can anyone confirm if the sandbox version works in all browsers? (It works for me in Chrome, Firefox and IE8.) It uses a dynamic bottom margin instead of a &nbsp; in case only p is used. This avoids having that nbsp in copied code. — Edokter • Talk — 00:17, 23 December 2010 (UTC)

Confirmed with the following

• Chrome 8(Win7) & 10(Win7)
• Firefox 3.5(WinXp), 3.6(Win7), 4.0 beta(Win7)
• MSIE 6 (WinXP), 7 (WinXP), 8(Win7), 9(Win7)
• Opera 11(Win7)

    — SkyLined (talk) 08:37, 23 December 2010 (UTC)

Excellent. I'll put that in. — Edokter • Talk — 22:54, 23 December 2010 (UTC)

Line breaking

Since people are now hacking on the template, I would like to raise one more issue with the template: namely, in all versions I've seen, there is nothing to prevent the browser from wrapping the line after the base symbol just before the template, making the subscript and superscript alone to start a new line. This can be countermanded by putting all the stuff in a {{nowrap|...}}, but people usually don't as they are not aware of the problem. Is it somehow possible to fix this within the template itself?—Emil J. 14:01, 22 December 2010 (UTC)

I'd recommend against this because it would be hard to do this automatically: {{su}} is used both before and after a symbol by various templates (eg. ¹²
₆C
), so any such code would have to allow for this, making it very complex and hard to maintain. Do you have an example of such use? The only reasons I can think of would be generic enough to create a template such as {{ComplexNuclide2}}: that way you don't have to worry about this kind of thing at all.     — SkyLined (talk) 15:24, 22 December 2010 (UTC)

• Possibly, we would change the way symbols are encoded, so that the base symbol is also a parameter to an Su-style template. Meanwhile, any templates using {Su} should put their own {nowrap} spans as needed. Of course, ideally, we would have "smart" browsers which know how to word-join or hyphenate text, so a browser could be set to nowrap "H₂SO⁺" or "1 km" or "a dog" but split "antisimplifi-cation" while German users would activate auto-hyphenation for long words such as "Gesund-heit" (health) or "Gesell-schaft" (society). I think multi-language support in browsers has hurt the chances of auto-hypenating text, due to conflicting syllable rules. -Wikid77 (talk) 18:05, 22 December 2010 (UTC)

See arithmetical hierarchy or reverse mathematics for the usage I had in mind. In general, it's pretty common in mathematics to have both a subscript and a superscript on the same symbol; the only special thing here is that the notation is heavily used inline and it is simple enough that one would want it to be in HTML rather than in PNG. If this template is only intended to be used embedded in other templates, then (1) we need a wrapper template for end users, which could then have a parameter for the base symbol and supply the nowrap, and (2) we need to document this. For now, I have documented the current behaviour.—Emil J. 20:36, 23 December 2010 (UTC)

Recent breakage

This edit totally breaks the template in my version of Firefox (Iceweasel 2.0). It causes spurious line breaks to be inserted. I am tempted to revert back to the revision of 24 September 2010 until this bug is fixed. Sławomir Biały (talk) 15:15, 27 December 2010 (UTC)

Is IceWeasel perhaps based on an old version of FireFox (as 2.0 suggests)? What will help best to fix any problem is to post example code used and a screenshot of the result. — Edokter • Talk — 15:26, 27 December 2010 (UTC)

Yes, Iceweasel is identical to Firefox 2.0. The image is a screenshot of the example code ''C''{{su|p=(α)|b=''n''}}(''x''): C^(α)
_n(x). Sławomir Biały (talk) 16:15, 27 December 2010 (UTC)

Needs some work devising a fix that does not effect other browsers, but we'll figure it out. — Edokter • Talk — 16:57, 27 December 2010 (UTC)

This is why I had problems creating the original template, and why I had to use -moz-* specific CSS styles. However, better to drop FF2.0 support than IE6.0 as the later affects a lot more people. Btw. Mozilla dropped development of FF2 in 2006 - you should *really* update.     — SkyLined (talk) 09:19, 28 December 2010 (UTC)

I have to agree here, FF2.0 has negligable market share. Sorry about that. — Edokter • Talk — 12:41, 28 December 2010 (UTC)

I'm not sure I agree that the market share is "negligible". Sure, many users are running fully up-to-date systems. But a three year old browser should hardly be considered deprecated yet. Many Unix timesharing services and Linux distributions don't upgrade very often because of downtime and the need to prevent potential problems. I am currently running Debian etch at home, which only supports Firefox 2.0. I have an older system that still runs the previous distribution of Debian. At my university, I checked the unix timesharing service, and it still runs Firefox 1.0 (!). Both the Red Hat and Solaris systems in my department still run Firefox 2.0. Sławomir Biały (talk) 18:03, 31 December 2010 (UTC)

We try to accomodate everyone, but up to a point. We support all major browser families, and even old version when their market share warrants it (like IE6 used to be). But we cannot be expected to support every old version until the end of time. — Edokter • Talk — 20:18, 31 December 2010 (UTC)

This isn't netscape 1.0 or anything. This is a version of a major browser that is still widely deployed. Four years old is hardly "the end of time" I should think. Sławomir Biały (talk) 12:27, 1 January 2011 (UTC)

Firefox 2.0 has a share of 0.43% ([1]), whereas Firefox 3.6 has over 23%. That is too little to consider a fix. I would seriously consider deployment of a more recent version. — Edokter • Talk — 13:19, 1 January 2011 (UTC)

I've requested further input at WT:WPM. It seems to me that a template that is completely broken for a substantial number of users (at least ~20,000) should probably be either fixed or retired. Our own accessibility guideline discourages content that would not display properly for users with limited Javascript/CSS support, for instance. These are, I believe, a much smaller "market share". Sławomir Biały (talk) 16:22, 1 January 2011 (UTC)

That sounds like a good idea, Sławomir; we should have wide consensus on what browsers we will and won't support and under what conditions. I know from experience that opinions vary widely. However, {{su}} is used by many non-mathematics pages, so it might be useful to take it up a level and either include other projects such as Physics, or the whole of wikipedia, as I'm sure similar questions will pop-up in other areas.     — SkyLined (talk) 11:54, 2 January 2011 (UTC)

Ok. Would an RfC be the way to proceed in your opinion then? Thanks, Sławomir Biały (talk) 13:29, 2 January 2011 (UTC)

Not a clue TBH; I've not had to escalate anything so far :D     — SkyLined (talk) 16:50, 2 January 2011 (UTC)

using template with small letters

I know all the examples you consider come from chemistry and physics, but it would be really nice if the template was able to accommodate super+subscripts after small letters as well. For example, currently σ²
₀ just doesn't look right, regular <sup/>+<sub/> tag displays it as σ²₀. Would it be possible to maybe include an additional parameter which would make the distance between the sub- and sup- lines smaller, more appropriate for sub/superscripts after small letters?  // stpasha »  00:19, 13 February 2011 (UTC)

There's also the template {{SubSup}} which gives σ 2
0 , and more at Category:Mathematical formatting templates.--JohnBlackburne^words_deeds 00:26, 13 February 2011 (UTC)

Formulas are a bit too tall

The {{chem}} template, that is based on {{su}}, has a bad effect on line spacing, because the formulas come out a bit too tall. This problem does not occur with ordinary ^... See

Lorem ipsum blabla gallia omnia
Lorem ipsum blabla gallia omnia
Lorem ipsum blabla gallia omnia
Lorem ipsum CH⁺
₃ gallia omnia
Lorem ipsum blabla gallia omnia
Lorem ipsum blabla CH⁺ omnia
Lorem ipsum blabla gallia omnia

(I am using Chrome with the default "vector" skin for Wikipedia.) Would it be possible to reduce the font size of sub/sup scripts, and/or push them closer together, and/or lie to the browser about the height of the result to avoid this problem?
Should I take this complaint to the {{chem}} talk page instead?
Thanks, and all the best, --Jorge Stolfi (talk) 00:53, 22 February 2013 (UTC)

iirc the reason for this is that regular sub/sup would overlap, so either so has to be raised or sub lowered. the first was chosen, resulting in bad line height. there may be ways to solve this using some css tricks; of you know how let me know and we can fix it together. or feel free to implement the fix yourself if you have the templating skills:) — SkyLined (talk) 07:41, 27 February 2013 (UTC)

I understand the reason, but perhaps the sub/sup font size can be reduced a bit? Unfortunately I do not have the skills to do that myself.--Jorge Stolfi (talk) 14:59, 27 February 2013 (UTC)

Well, here is the result of editing the raw HTML source, to say "font-size:75%" (instead of 85%) and "line-height:1.0em" (instead of 1.2em):

Lorem ipsum blabla gallia omnia
Lorem ipsum CH+ggglll
3fffppp gallia omnia
Lorem ipsum CH+ggglll
3fffppp gallia omnia
Lorem ipsum blabla gallia omnia

With the Vector skin at least, the line spacing looks correct and there is still one pixel gap between superscript ascenders in one line and subscripts descenders in the line above. Of course, if one still wants to uses capital letters with accents in superscripts...--Jorge Stolfi (talk) 16:23, 27 February 2013 (UTC)

We've had much debate about such issues before and ran into technical limitations when resolving them because Wikipedia MUST be readable in a lot of older browser. However, the market shares of older version of browsers may have slipped sufficiently by now to drop support for them in order to improve rendering in newer browsers. I'm certainly willing to give it a try.

Problem with your solution is that this looks bad when mixing {{su}} with <sup> and <sub>, as the both the font size and line heights are now off. However, it seems we can bring the sup and sub parts of {{su}} closer together, at the risk of overlapping in some cases, to make it look better:

Current:	75% font:	Reduced line-height:	Control:
AAAAAAAAA AsupAsup subAsubA AAAAAAAAA	AAAAAAAAA AsupAsup subAsubA AAAAAAAAA	AAAAAAAAA AsupAsup subAsubA AAAAAAAAA	AAAAAAAAA AAAAAAAAA AAAAAAAAA

The third column looks best to me: overall line-height is the same as the control, the font size in {{su}} is the same as <sup> and <sub> and the vertical line alignment is closer to <sup> and <sub> than current {{su}}.

If nobody objects, all that's left to do is checking on all supported browsers, on all supported platforms that this renders better than current {{su}} before we can implement the change.... sigh. I'll check latest Chrome, FF and MSIE 10 now. — SkyLined (talk) 19:09, 27 February 2013 (UTC)

Just great: in FF the 75% font size is actually closer to that of sup/sub than su (exactly the same afaict). In MSIE 10, 75% is also closer to sup/sub than current su, but it still appears slightly larger - probably 70% would get them to be exactly the same. In other words: reducing the font size would be a better way to go on FF/MSIE, reducing line-height would be better in Chrome.... hurray for HTML5 :S. — SkyLined (talk) 19:25, 27 February 2013 (UTC)

But I have another trick that we could try: use a <sub> tag to get whatever font-size the browser uses for sup/sub and tweak some of it's properties to fit our needs:

Current:	75% font:	Use sub:	Control:
AAAAAAAAA AsupAsup subAsubA AAAAAAAAA	AAAAAAAAA AsupAsup subAsubA AAAAAAAAA	AAAAAAAAA AsupAsup subAsubA AAAAAAAAA	AAAAAAAAA AAAAAAAAA AAAAAAAAA

I'll go and check this in Chrome, FF and MSIE right now — SkyLined (talk) 19:25, 27 February 2013 (UTC)

Okay - this last suggestion of mine looks better than current su in Chrome, Firefox and MSIE 10 to me. Let me know what you think — SkyLined (talk) 19:26, 27 February 2013 (UTC)

Any reduction in font size or line height is going to be detrimental to readability. I spent a lot of time in optimizing the template to avoid any readability issues such as overlapping text, and usage of sup/sub was avoided specifically to make it consistent across browsers. — Edokter (talk) — 19:33, 27 February 2013 (UTC)

Bringing the two lines closer together without reducing the font size will cause the ascenders and descenders to overlap. Not a problem for chemistry since they rarely have superscripts with descenders, but other people may object. On the other hand, the size mismatch is a problem only if people mix explicit <sub>/<sup> with {{su}} for the same kind of formulas in the same article. How likely is that? Perhaps we can tell those people "sorry, if that bothers you use {{su}} for everything". --Jorge Stolfi (talk) 20:16, 27 February 2013 (UTC)

PS. (a) Methinks that the uneven line spacing is more disturbing to people than an eventual size mismatch between <sub>/<sup> and {{su}}; the latter should seem to be a logical necessity. (b) Stacked sub/superscripts are also used in math articles. However, now that mathJAX is working and is reasonably efficient, faked-math (with the {{math}} template or ''...'') should be seen as obsolete. Thus the math community is unlikely to complain about the font size mismatch above: the visual difference between faked-math in text and TeX-<math> in display is infintely worse. Moreover, mathJAX already yields stacked sub/sup scripts without affecting the line spacing, so its fonts must be smaller than those of HTML <sub>/<sup>. --Jorge Stolfi (talk) 20:30, 27 February 2013 (UTC)

Rendering problem on Chrome

I apologize for discussing a Chinese Wikipedia issue here, but I got little help there. There is a rendering problem when using Chrome on both Mountain Lion and iPad, where there is a huge space before the sup/b-scripts. This only occurs when template is used with inline text, but not in tables or bullet lists. Safari has shown no problem. Please see the first post for a screen shot of the problem. This occurs with other similar templates like {{chem}}, {{Nuclide}} and {{ComplexNuclide}}, etc. Upon directly copying the code for template:su to the Chinese wiki, the space is removed only for the subscript, but the superscript remains mis-rendered. The names of the Chinese templates should be exactly the same as the English ones. Can anyone offer some help, please? Yinweichen (talk) 21:04, 22 March 2013 (UTC)

Conversion to Lua

I've just finished converting this template to Lua. The code is at Module:Su. This isn't a particularly resource-intensive template, but I needed to convert it to Lua to use in Module:Vandal-m, which is in turn going to be used in Module:Protection banner, as {{pp-usertalk}} uses it. You can test the code out by using {{su/sandbox}}, and there are test cases at Template:Su/testcases. I've designed this to be a one-to-one conversion, so there shouldn't be any difference in terms of output. If anyone does notice anything, though, please let me know. And if there are no objections in the next few days, I'll update the main template to use the module. — Mr. Stradivarius ^{♪ talk ♪} 10:46, 17 June 2014 (UTC)

I can't see any problems, we should just be alert when it's rolled out for any reports. Does this mean it would have to be protected? Probably not a bad idea anyway, as it's used a lot and is the sort of template that could be easily broken.--JohnBlackburne^words_deeds 19:45, 17 June 2014 (UTC)

I've just made the switch, so be on the lookout for any anomalies. And I've semi-protected Module:Su. — Mr. Stradivarius ^{♪ talk ♪} 10:57, 27 June 2014 (UTC)

The Lua version is slower then the old template. Isnt it used a lot of times at some pages? {{chem}} uses it. Christian75 (talk) 20:14, 28 June 2014 (UTC)

lh line-height parameter

on {{Su/sandbox}} and the corresponding sandbox Lua module, I added a |lh=1.2em parameter that allows the default line-height css to be specified. This change would be used in {{Time signature}} where, contrary to the other applications of this template, we want the sup and sub parameters to touch or even overlap slightly. Because this change does nothing to the default setting of the template (I hope), normally I'd be bold and include but since this is my first Lua code and the template is used in so many places, I'd love to have a little confirmation before updating the template, module, and docs. -- Michael Scott Cuthbert (talk) 19:33, 27 January 2015 (UTC)

I moved the default value definition. I tested it in {{Time signature/sandbox}} and it works as (not yet) advertised. Go ahead with the updates. -- [[User:Edokter]] {{talk}} 20:43, 27 January 2015 (UTC)

Would it not be better to create arguments that allow you to add arbitrary style definitions to both the sup and sub part? I am thinking of an argument called "style" the value of which is added to the style attribute of both the sup and sub part, as well as a "stylep" and "styleb" argument, to be added to the sup and sub parts respectively. This would prevent a proliferation of additional arguments to add styles, should there be other use cases (and I bet there will be). This would complicate their use slightly, but since the average user is not expected to do this, I feel the flexibility this offers is worth that. You would end up adding |style=line-height: 1.2em in this scenario. — SkyLined (talk) 22:19, 27 January 2015 (UTC)

I think this particular template does not lend itself for an (open) style parameter; there is too much potential for breakage as it already depends on a tight set of CSS rules with little room for additional styling. And having |lh=1.2em is easier to type. -- [[User:Edokter]] {{talk}} 00:01, 28 January 2015 (UTC)

• What kind of breakage are you thinking of? All I can think of is somebody shooting themselves in the foot by adding style declarations that overwrite/break the ones already there. That would result in incorrect output, so there is immediate feedback that what you're attempting does not work. This would not affect any of the pages already using {{su}}.
• The current use case for line-height is inside one template. I do not expect there to be very many more in the future, and if there are, I expect these to be inside other templates as well. In this scenario I don't see how having to type |style=line-height: 1.2em rather than |lh=1.2em in a few places is a lot of effort. On the other hand, the generic approach would prevent a growing number of argument being added when additional style tweaks are requested in the future. This keeps the code for {{su}} simpler, faster and easier to maintain in the long run. I believe that would save more time than a slightly shorter parameter for line-height. — SkyLined (talk) 10:54, 28 January 2015 (UTC)
• Also: I assume it will be much easier for anybody editing {{Time signature}} in the future to guess what |style=line-height: 1.2em does, as opposed to |lh=1.2em. It would save such editors time when they don't have to look it up in the documentation for {{su}}. — SkyLined (talk) 10:57, 28 January 2015 (UTC)

I just don't see a case (yet) for an open style parameter. So let's go with the "as needed" approach for now. This is a meta template anyway, so regular editors are not going to encounter it in the wild. -- [[User:Edokter]] {{talk}} 11:50, 28 January 2015 (UTC)

This is what I am trying to avoid!? Having to retroactively replace the lh parameter with style in this template and any pages using it would be more work than implementing style now. I don't see how typing a slightly longer parameter in one location now outweighs the risk of having to do a lot more work in the future. 83.84.42.5 (talk) 15:38, 28 January 2015 (UTC)

What is there to avoid? If the need for more styling options are needed (and I don't expect any), a style paramter can always be added later, without having to remove the legacy options. I do think an open style (three of them no less) is potentially more dangerous then the added benefits. -- [[User:Edokter]] {{talk}} 16:47, 28 January 2015 (UTC)

We can start with adding only style which would apply to both the sup and sub part. We can add stylep and styleb later as needed. Either way, I'm pretty sure that by now we've both adequately explained why we prefer the two different options, and that we're not going to agree on this. I suggest we wait and see if others are going to chime in. I'm sure we're not the only people with an opinion on this? 83.84.42.5 (talk) 23:07, 28 January 2015 (UTC)

Anyone can chime in. For now, I added the lh option. -- [[User:Edokter]] {{talk}} 23:28, 28 January 2015 (UTC)

Adding va option

I'm adding a verticalAlign option to accomodate {{chem}}. I nned to know if the following line is valid: ['vertical-align'] = options.verticalAlign or sub and '-0.4em' or '0.8em',. The origonal being: ['vertical-align'] = sub and '-0.4em' or '0.8em',. -- [[User:Edokter]] {{talk}} 19:31, 28 February 2016 (UTC)

subscript/superscript height matching

The subscript/superscript generated by {{su}} aren't quite at the right height, which can create a few issues in article which mix usage between the template and the html tags. Compare

• Λ{{su|b=t}}_t → Λ
  _tt
• Λ{{su|p=t}}^t → Λ^{t
  t}

Is there a way of aligning them at the correct height? Headbomb {talk / contribs / physics / books} 11:40, 23 August 2016 (UTC)

Actually, the height make sense to me. When you have both superscipts and subscripts, a bit more vertical separation is required to ensure that they don't collide. Note how the <sub> and <sup> versions overlap vertically: Λ_t^t. Worse yet if there are capital letters: Λ_H^p. Those letters would clearly overlap if horizontally aligned, so {{su}} should not try to match the native HTML super/subscripts vertically. The one problem I've run into is the horizontal separation. Because Λ is a wide letter and lower-case t has a crossbar the protrudes to the left, Λ
_t touches on my display, making a hard-to-read mess. (Using <sub>, Λ_t does not quite touch.) 71.41.210.146 (talk) 16:47, 23 August 2016 (UTC)

Having created the original template, I can tell you that it was very hard to find something that worked in all browsers, provided sufficient vertical separation and used an acceptable font size. I don't think you can find a way to improve it in one aspect without compromising another, but I encourage you to try! After all, I originally created it to support browsers such as IE6 as well and I don't think we need to do that anymore :) While you're at it, please add better support for mobile browsers: it looks terrible on Firefox for Android :(. — SkyLined (talk) 17:42, 23 August 2016 (UTC)

In either case, it should very likely match the height unless both |b= and |p= are specified. Headbomb {talk / contribs / physics / books} 11:10, 24 August 2016 (UTC)

Why? If you're thinking it would make things look better, consider that it would make things like this passage from Alpha particle look worse: "Because they are identical to helium nuclei, they are also sometimes written as He²⁺
or ⁴
₂He²⁺
indicating a helium ion with a +2 charge (missing its two electrons)." — SkyLined (talk) 17:20, 24 August 2016 (UTC)

Using the 'chem' template as a standard seems circular. I find that the offsets there are jarringly large even purely in the chemical context, and would like to see the spacing sup/sub there (and with template su) reduce to something like 1 em. A small amount of touching or even overlap of tops and tails is tolerable (i.e. of the bottom of a lower-case 'p' with the top of a lower=case 'f'), and in the few cases where that occurs, the spacing can be manually increased on a per-use basis. The (aesthetic visual) cost of mismatch of 'su' with 'sup' and 'sub' in mathematical and related articles seems great (subjectively, to me). Of course, I could override the line height on a case-by-case basis in mathematical articles, but that might also not be popular ... —Quondum 22:24, 14 January 2017 (UTC)

What if you need such a thing in a citation template?

The documentation says not to use this template inside citation templates, but doesn't say what to do instead.

I'm trying to cite https://arxiv.org/abs/hep-ph/0611102 whose title is "Improved predictions for g-2 of the muon and α_QED(M²
_Z)". How do I cite this? Currently it's

• Hagiwara, K.; Martin, A.D.; Nomura, Daisuke; Teubner, T. (May 2007). "Improved predictions for g−2 of the muon and α_QED(M_Z²)". Physics Letters B. 649 (2–3): 173–179. arXiv:hep-ph/0611102. CiteSeerX 10.1.1.346.6143. doi:10.1016/j.physletb.2007.04.012.

Any suggestions? 23.83.37.241 (talk) 22:31, 23 April 2018 (UTC)

I say use it anyway. At worse, it corrupts some citation metadata, it's more important that things are presented correctly to the reader. Headbomb {t · c · p · b} 23:19, 23 April 2018 (UTC)

Thanks. Shall I update the docs to clarify that it's discouraged but not forbidden as there is no real alternative? 23.83.37.241 (talk) 23:39, 23 April 2018 (UTC)

parameter table column width

There have been various attempts to fix the line-breaking in the table of parameters by setting a width of the column, none of which fixed that issue. I've asked that {{para}} (provide an option to) automatically add html/css to prevent line-breaks. That should fix the problem at the root. — SkyLined (talk) 17:15, 3 April 2023 (UTC)

Line breaking (again)

Contrary to the view expressed by SkyLined in § Line breaking above, I have found fix for the line breaking problem, which (crucially) is very simple, and I suggest that it be implemented in this template. Specifically, wrapping the template output only from within the template (i.e. not including adjacent text that we do not want to break away from it on wrapping) reasserts "proper" wrapping behaviour of text. This results in no line breaks between the template output and adjacent text if the adjacent text does not inherently admit line breaks. Thus, normal cases will not wrap, but wrapping might occur between the nowrap section and breaking characters such as a hyphen or space. This holds both before and after the nowrap section. I successfully implemented this at {{tmath}}. Example:

wrap:  XXXXXXX{{su|p=aaaa|b=bbbb}}XXXXXXX → XXXXXXX^aaaa
_bbbbXXXXXXX

nowrap: XXXXXXX<span class="nowrap">{{su|p=aaaa|b=bbbb}}</span>XXXXXXX → XXXXXXX^aaaa
_bbbbXXXXXXX

—Quondum 12:14, 10 April 2024 (UTC)

Please replace line 94 of Module:Su

return tostring(span)

with

return '<span class="nowrap">' .. tostring(span) .. '</span>'

to implement the change that I discussed above (but to which no-one has so far responded). This improves the behaviour of the displayed result to being simultaneously more useful and more intuitive. I consider this as a being a low-risk, desirable change. I have tested this in Module:Su/sandbox (see Template:Su/testcases). The same fix at Template:tmath (albeit in a template, not Lua) has been live since Christmas and is used in over 500 mainspace pages, without any apparent reaction. —Quondum 01:45, 14 April 2024 (UTC)

A more comprehensive test report:

• Firefox (124.0 on Ubuntu 22.04): inhibits line breaks both before and after template output
• Safari (17.4.1 on macOS 14.4.1, latest on iOS 17.4.1): inhibits line break before template output, but no effect after it
• Chrome (123.0 on Ubuntu 22.04): no effect (line breaks still occur both sides)

In short, this is an improvement for common use (i.e. for the form X^a
_b) on Firefox and Safari, with no effect on Chrome, with no apparent detriment for any platform.

—Quondum 13:50, 14 April 2024 (UTC)

 Done * Pppery * _{it has begun...} 02:27, 15 April 2024 (UTC)

@Pppery, Quondum: FYI, This change seems to have caused several pages using {{chem}} to exceed the WP:PEIS limit. I've mostly been able to offset it by calling this module directly from {{chem/atom}} instead of using {{su}}. However, I have to wonder if there is a reason why you're adding an additional layer of span tags instead of just adding span:addClass('nowrap') somewhere around line 78. --Ahecht (TALK
PAGE) 18:20, 15 April 2024 (UTC)

@Quondum Could you test {{su/sandbox}} and see if the wrapping behaves as you want?

sandbox: XXXXXXX{{su/sandbox|p=aaaa|b=bbbb}}XXXXXXX → XXXXXXX⁠^aaaa
_bbbb⁠XXXXXXX --Ahecht (TALK
PAGE) 18:33, 15 April 2024 (UTC)

For clarity, I matched your displayed code with your actual code used in your last post above. Although it now produces exactly the HTML that I would have thought would work, the behaviour is now identical on all browsers to what it was before my change (i.e. even Firefox allows breaking before and after the template output). —Quondum 18:55, 15 April 2024 (UTC)

Having the style="display:inline-block" in the same <span> appears to nullify the effect of the class="nowrap". Given that there are impacts that I had not anticipated (and although this does suggest that some templates should be reworked to limit depth), together with the fact that this is a considerably less complete a fix than I had supposed initially, I would not object to reverting my change. —Quondum 19:18, 15 April 2024 (UTC)

{{Edit template-protected|Module:Su}} Please replace line 94 of Module:Su again –

return '<span class="nowrap">' .. tostring(span) .. '</span>'

with

return '<span class="nowrap">&NoBreak;' .. tostring(span) .. '&NoBreak;</span>'

This insertion of ⁠ at two points has the following effect:

• Firefox: no impact (it remains fixed)
• Safari: no negative impact (it remains fixed on the left, but can still line-break on the right)
• Chrome: both sides inhibit line break properly (i.e., this fixes the line break issue for Chrome).

I have implemented this fix on both the {{tmath}} and {{sfrac}} templates and have tested it in Module:Su/sandbox. —Quondum 21:30, 13 July 2024 (UTC)

@Ahecht: you may want to weigh in before this change is made. —Quondum 21:44, 13 July 2024 (UTC)

@Quondum This will have an even larger WP:PEIS impact. With this change, do you still need the additional layer of span tags, or would the version at Module:Su/sandbox2 work? I've never been able to reproduce the wrapping bug that you're seeing in Chrome. --Ahecht (TALK
PAGE) 01:21, 14 July 2024 (UTC)

Ahecht: No, sandbox2 doesn't work. As before, the ":addClass('nowrap')" does not have desired effect when combined into the same span as other parameters. Can you modify the sandbox code so that it envelops the whole output in a separate <span class="nowrap"> ...</span>? I'm afraid my Lua coding is nonexistent.

To reproduce the problem, open Template:Su/testcases#Line breaks in a Chrome browser. You should see under the "Main" subheading that line breaking occurs, but so not under "Sandbox". In Firefox, the neither breaks. You may need to reduce your window width. —Quondum 02:11, 14 July 2024 (UTC)

Another thought: since this is presumably impacting pages with a large number of {{su}} transclusions, doesn't it possibly make sense to create a subtemplate Template:Chem/su, which would not need the wrapping prevention? If wrapping prevention is needed, {{tl:Chem}} could include a single top-level <span class="nowrap"> ...</span>. —Quondum 02:25, 14 July 2024 (UTC)