Template talk:SubSup

{{su}}

No offence, but this seems to be a variation of {{su}} with no useful added features. It also does not seem to be used by any other page. Is there a reason for having this template?

    — SkyLined {^talk_contribs 17:33, 28 August 2008 (UTC)

There has been an ongoing discussion on one of the photography pages (specifically, {{f/}}) about the proper typography for mathematical symbols in the running text. The discussion initially focused on the proper typography for the f-number (e.g., f/8 vs. f/8); more generally, is the f a special symbol or just a quantity symbol for the lens focal length? But the discussion immediately led to the more general treatment of all inline mathematical material.

Wikipedia is somewhat unusual in that it uses a sans-serif typeface for running text but a serif typeface (via TeX) for displayed mathematics. Normally, quantity symbols are set in the “italic” font of the typeface of the running text. Some things (e.g., subscripts and superscripts, nonbreaking expressions) are tedious to code properly in HTML/CSS. Consequently, it's often tempting to use TeX for inline material to simplify coding; when this is done, the mathematics don't match the running text. {{su}} now seems to address positioning proper positioning of subscripts and superscripts. But that's only part of the problem. For mathematics involving symbols for physical quantities, the quantity symbols are usually set in italic font and the superscripts and subscripts are normally in roman font; to avoid having the subscripts and superscripts overlap the base symbol, it's necessary to add some space, and the coding to make the space nonbreaking is a real mess. {{SubSup}} was written to address this as well as the sub/super positions; {{SubSup}} also requires a bit less typing, at the cost of some versatility.

I suppose I should add some mention to the {{SubSup}} documentation explaining how it differs from {{su}}.

I've held off using {{SubSup}} to replace some of the hand-coded HTML/CSS in the photography articles pending the outcome of the discussion on {{f/}} (which seems to have stalled ...). I'll see if I can't get it restarted. JeffConrad (talk) 23:45, 28 August 2008 (UTC)

FF2

This displays incorrectly on FireFox 2: {{su}} does not have this problem. However, {{su}} displays incorrectly on IE6...

    — SkyLined {^talk_contribs 17:33, 28 August 2008 (UTC)

Obviously, not good. Offhand, I don't have a solution, except to mention the problem in the {{SubSup}} documentation. I could change {{SubSup}} to use much of the coding in {{su}}, but that coding looks very vulnerable to breaking in future browser releases. There's probably a cleaner and more robust way to do both {{su}} and {{SubSup}}, but I've been unable to find it. It seems that almost any nontrivial use of CSS is asking for compatibility problems; for example, your signature doesn't display properly with FF3—the “contribs” overlaps the brace. JeffConrad (talk) 23:56, 28 August 2008 (UTC)

The only real solution I could think of was to have a TABLE with two rows, but wikipedia automatically messes things up for you by ending the paragraph:

<SPAN> this is a test for <TABLE><TR><TD>superscript</TD></TR><TR><TD>subscript</TD></TR></TABLE> in a table.</SPAN>

Looks like this:

this is a test for

superscript

subscript

in a table.

As you can see there are linebreaks before and after. If we could prevent those, we're in business.

    — SkyLined {^talk_contribs 13:12, 29 August 2008 (UTC)

The inline-block display property was new to CSS 2.1, and apparently Firefox 2 doesn't support it. With the table approach, perhaps the answer is to not tell Wikipedia nothin' that we don't want it to know ... for example,

This is a test for <span style="display: inline-table;"><sup style="display: table-row;">superscript</sup><sub style="display: table-row;">subscript</sub></span> in a table

gives

This is a test for ^superscript_subscript in a table

which seems like a good start; with some tweaking of line spacing, font size, and vertical alignment, it might to the job. But it doesn't seem to work with IE 7.

Another approach may be to stick with the inline-block display property but precede it with -moz-inline-box to keep FF 2 happy. For example,

This is a test of <span style="display: -moz-inline-box; display: inline-block;">superscript<br>subscript</span> using inline-block

gives

This is a test of superscript
subscript using inline-block

which would be fine in FF 3 and IE 7 with some tweaking of font size and vertical alignment. How does it look in FF 2? JeffConrad (talk) 09:50, 30 August 2008 (UTC)

Looks like FF 2 doesn't support inline-table, either. I can't find a way to reconcile the vertical-alignment differences between inline-block and -moz-inline-box other than what you have done in {{su}}; even then, there are some problems: I sometimes get clipping of descenders in the superscript with IE 7. For example,

This is a test of ^superscript
_subscript using {{su}}

clips the descender on the p in superscript with IE 7. If the Wikipedia-generated code is pasted into a plain HTML file and viewed with IE 7, the ascender on the b is clipped and the superscript doesn't display at all.

Offhand, I don't see a clean way to do it with pre-CSS 2.1 browsers. JeffConrad (talk) 21:03, 30 August 2008 (UTC)

Which is exactly where I am - tried pretty much everything when I wrote {{su}} but got tired. I have one more trick I want to try: conditional comments. I've not looked into this, but it seems it may allow us to create HTML that only applies to certain browser which may allow us to create code that renders differently in FF compared to IE.

Looks like it might work for IE (at the expense of voluminous code in the already unreadable template format), but the biggest problem seems to be cleanly distinguishing FF 3 from earlier versions—supporting inline-block or not. JeffConrad (talk) 20:42, 1 September 2008 (UTC)

I'm not too worried about bloated unreadable code: You can always use HTML comments to make it more readable (have a look at {{val}}). I can always write a documentation page or even set up a website that generates the code from a more readable format (syntax highlighting, etc..). I would prefer a simple and clean solution of course, but the most important thing is making it work on all browsers.     — SkyLined {^talk_contribs 09:46, 2 September 2008 (UTC)