text-align: "." fails...

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

kj - 25 Apr 2006 22:48 GMT

I've tried *many* variations of the following:

<TABLE>
<TR><TD STYLE='text-align: "."; font-family: Courier'>0.12</TD></TR>
<TR><TD STYLE='text-align: "."; font-family: Courier'>10.1</TD></TR>
<TR><TD STYLE='text-align: "."; font-family: Courier'>123.001</TD></TR>
<TR><TD STYLE='text-align: "."; font-family: Courier'>0.02</TD></TR>
</TABLE>

but they all fail to produce a column of numbers lined up at the
decimal point. What am I doing wrong?

Thanks!

kj

Signature

NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

Reply to this Message

Jukka K. Korpela - 25 Apr 2006 23:08 GMT

> I've tried *many* variations [ text-align: "." ]

- -

> but they all fail to produce a column of numbers lined up at the
> decimal point.

None of the variations works. Aligning on a character, though formally
possible both in HTML and in CSS, has never been implemented in browsers.

As a workaround, you could right-pad the numbers with zeros so that they have
the same number of digits to the right of the decimal marker, and just right-
align the cells. This will in practice align the numbers on the marker. You
don't need a monospace font for that, since in virtually all fonts used in
browsers, digits share the same width. (In typographical terms, the fonts
have "tabular digits".)

If you think right-padding with zeros is not correct (10.100 might be seen as
having more accuracy than 10.1), you could cheat a little with things like

<td>10.1<span class="z">00</span></td>

with

.z { visibility: hidden; }

Signature

Yucca, http://www.cs.tut.fi/~jkorpela/

Reply to this Message

Harlan Messinger - 25 Apr 2006 23:17 GMT

> As a workaround, you could right-pad the numbers with zeros so that they have
> the same number of digits to the right of the decimal marker, and just right-
[quoted text clipped - 11 lines]
>
> .z { visibility: hidden; }

Too bad   (figure space) doesn't work.

Reply to this Message

Jukka K. Korpela - 26 Apr 2006 07:49 GMT

> Too bad   (figure space) doesn't work.

Well, it works in a few fonts in the intended sense, so it might have limited
applicability in some (generally non-WWW) situations.

Technically, the treatment of figure space, and other fixed-width spaces,
in rendering and otherwise, is _undefined_ according to HTML specifications.
In practice though they are treated as if they were graphic non-whitespace
characters, with all the problems that arise from the fact that their glyphs
might or might not be available in a font and might or might not match the
specified or suggested widths.

Signature

Yucca, http://www.cs.tut.fi/~jkorpela/

Reply to this Message

Harlan Messinger - 26 Apr 2006 13:01 GMT

>> Too bad   (figure space) doesn't work.
>
[quoted text clipped - 3 lines]
> Technically, the treatment of figure space, and other fixed-width spaces,
> in rendering and otherwise, is _undefined_ according to HTML specifications.

Is it undefined in any way that's different from the way that handling
of, say, the letter "A" is undefined?

> In practice though they are treated as if they were graphic non-whitespace
> characters, with all the problems that arise from the fact that their glyphs
> might or might not be available in a font and might or might not match the
> specified or suggested widths.

What choice is there? I supposed the HTML engine could be made
responsible for determining the distance that a "9" in the current font
would span horizontally, including normal character spacing, and then
offsetting that far to the right, but that seems unreasonable. The
figure space ought to be in the font.

Reply to this Message

Jukka K. Korpela - 28 Apr 2006 11:40 GMT

>> Technically, the treatment of figure space, and other fixed-width spaces,
>> in rendering and otherwise, is _undefined_ according to HTML
>> specifications.
>
> Is it undefined in any way that's different from the way that handling
> of, say, the letter "A" is undefined?

It is; there is no corresponding statement about "A". It is a fair
assumption that in the absence of any other specification, a browser is
supposed to render any printable character in some normal way.

> What choice is there?

Quite a many, actually. Theoretically, "undefined" means that a browser
could do just about anything, like start playing Towers of Hanoi when it
encounters a character with an "undefined" effect, or render it as a
smiling face, to take an unimaginative example.

To mention some conceivable and logical alternatives:
1) Treat FIGURE SPACE as just another graphic character, applying the
same algorithms as for other characters when it is not present in the
currently preferred font.
2) Treat it as completely equivalent to SPACE.
3) Treat it as completely equivalent to NO-BREAK SPACE.
4) As 2) or 3) but adjust its width to match the width of digits.
5) Treat it as a disallowed character, issuing an error message or using
an error indicator in place of the character. (This may well be feasible
in specialized applications where the character is not supposed to be used.

In general, the spirit of Unicode - if I dare to use such a phrase - is
against using fixed-width space characters. They are compatibility
characters that have mainly been included due to existing or assumed use
in old-fashioned computerized typography. When supported, their widths
often do not match the Unicode widths, which themselves are partly very
vaguely described.

The problem in WWW authoring is that there are no feasible alternatives.
Technically we can use e.g. <span style="width:1en"> </span> to
create a simulation of a non-breaking EN SPACE, but I don't expect such
approaches to be very successful, and they surely aren't convenient to
use. Besides, for FIGURE SPACE, there is no way to express its width in CSS.

> I supposed the HTML engine could be made
> responsible for determining the distance that a "9" in the current font
> would span horizontally, including normal character spacing, and then
> offsetting that far to the right, but that seems unreasonable. The
> figure space ought to be in the font.

But what if it is not? Since the meaning of FIGURE SPACE is rather
well-defined in Unicode, it would be quite justifiable for a browser to
achieve its effect even when the current font has no such character.
This would in fact be superior, since using a figure space glyph from
_another_ font - which is what is generally supposed to happen in such
situations - would almost always create _wrong_ spacing.

Reply to this Message

Webmaster Forum / HTML, CSS, Scripts / CSS / April 2006

text-align: "." fails...