Template:Space/comparison

| | | | | | | |

This is a test of browser rendering of all the inline spacing templates and characters, with pipe (|) symbols as reference points, blown up to 500% font size for visibility. They are, in order of left to right:

| |{{sp|1}}| |{{space|1}}|{{unicode|&emsp;}}|{{unicode|&ensp;}}|{{pad|1px}}|

This test demonstrates crucial points for spacing:

On Mac OS X systems, all of these are exactly the same, using default system and browser fonts and no custom CSS. This is bad wrong, but this is the result in all four major Mac browsers: Safari, Firefox, Chrome and Opera.
On Windows systems, some of these are radically different from one another (as expected), using default system and browser fonts and no custom CSS, as tested in the five major Win browsers: Explorer, Firefox, Chrome (with default font and with Times New Roman, for kicks), Safari and Opera. To wit:
- &emsp; is about 2.2× to 2.7× the size of a regular space (i.e., it is as wide as an em-dash: | |—|).
- &emp;ensp; is about 1.3× to 1.5× the size of a regular space (i.e., it is as wide as an en-dash: | |–|).
- All of the rest are the width of a regular space, including {{pad|1px}} which shouldn't be from what I can tell, but oh well.
Various *n*x systems will probably be all over the map on this (though Linuxes will probably be consistent with each other and BSDs with each other, etc., but not each family with one another); anyone have a big pile of machines to test this with?
I.e., probably none of this works the way most of us thought it did.

Failure of Template:Space

It also means that the {{space}} template, as currently coded, fails as a consistency tool, since it alternates several of these characters as if they were interchangeable. Test the following in multiple browsers on multiple operating systems to see the problem in action:

|Foo| |bar| |baz| |quux|

The test failed in all five of the major Windows browsers (and "passed", i.e. the browsers and OS failed) in all four Mac tests. If {{space}}'s coding made sense, these lines would always be the same length, in all browsers, on all systems, at all font sizes, in all fonts. But, as coded, this would actually be a major error. Testing reveals that both lines will the same on most Mac systems, but will not be on any Windows systems except where users are overriding Arial as the default sans-serif font and using something that is not Unicode-aware. Linux/Unix are as yet untested, but will probably (except for Darwin, which is Mac-like) be mostly the same as Windows. The fact of the matter is that &emsp; is not at all comparable to  . Also, some browsers (especially on mobile devices) will collapse "  " or "  ", so the coding needed to change anyway.

As far as I can tell, Wikipedia's CSS just defaults to "sans-serif" without naming any particular font. On Macs, this defaults to Helvetica, apparently, and the Mac version seems not to be able to distinguish between these characters. The nearly identical Arial can handle them. While this is obviously an OS font issue, 99.9% of Mac users are never going to change the default font, so it is something we have to work around. NB: I can confirm that when you switch a Mac browser to using Arial Unicode MS as the sans-serif font, the display then becomes consistent with Windows browsers (i.e., it shows that {{space}} uses 3 different characters as equivalent, when one of them is more than twice as wide on all properly configured systems).

And even so, it's clear that {{space}} only "works" under these broken Mac conditions. It's a "codependent relationship of enabling".

Solution?

The only cross-platform way to space consistently is probably to use   (or {{space|1}}) either use it in series or alternate it with a plain space character. Some mobile browsers will shrink the plain spaces out of that, and a handful (also mobile) even forcibly collapse multiple  's. But we don't care, I don't think. Those are extreme applications and they do this because their displays cannot handle full webpage rendering. With the rise of comparatively large-screen smartphones, this is old, irrelevant news anyway. I cannot find a single desktop graphical (or text based – lynx(1), etc.) browser that does not properly display "   " and "   " and "   " (note the regular space characters in two of those). The only reason to prefer one over the other is to allow or prevent line wrapping. Given the purpose of this template, it can't really make any sense except as one that does the latter.

So, the obvious solution is to replace the blank space and &emsp; code in {{space}} with all  s. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 02:00, 17 October 2011 (UTC)