Decimal point alignment in a table

[Dr J R Stockton]

After simplification, I have

<table border=1>
<tr><td>1.0</td><td>123.67</td></tr>
<tr><td>22.5</td><td>1.6</td></tr>
</table>

What do I need to do to get the decimal points to line up vertically?
I'm sure I've seen it described somewhere, but can no longer find it.
Font is default serif, but if necessary could be monospace.

--
(c) John Stockton, nr London, UK. Mail via homepage. Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.

[tlvp]

On Mon, 9 Feb 2015 20:38:14 +0000, Dr J R Stockton wrote:

> After simplification, I have
>
> <table border=1>
> <tr><td>1.0</td><td>123.67</td></tr>
> <tr><td>22.5</td><td>1.6</td></tr>
> </table>
>
> What do I need to do to get the decimal points to line up vertically?
> I'm sure I've seen it described somewhere, but can no longer find it.
> Font is default serif, but if necessary could be monospace.

Use the align and char attributes, w/ values "char" and ".", respectively:

: <td align="char" char="."> .

That's reportedly OK in HTML 4.0 Strict, anyway :-) .
How often? Beats me; play around with it.
HTH. Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[Jukka K. Korpela]

2015-02-10, 6:11, tlvp wrote:

> On Mon, 9 Feb 2015 20:38:14 +0000, Dr J R Stockton wrote:
>
>> After simplification, I have
>>
>> <table border=1>
>> <tr><td>1.0</td><td>123.67</td></tr>
>> <tr><td>22.5</td><td>1.6</td></tr>
>> </table>
>>
>> What do I need to do to get the decimal points to line up vertically?
>> I'm sure I've seen it described somewhere, but can no longer find it.
>> Font is default serif, but if necessary could be monospace.
>
> Use the align and char attributes, w/ values "char" and ".", respectively:
>
> : <td align="char" char="."> .
>
> That's reportedly OK in HTML 4.0 Strict, anyway :-) .

Unfortunately, this part of HTML 4 was never implemented, and neither
was the CSS counterpart (text-align with a quoted string as value; this
was part of CSS 2.0 but not implemented, and it was dropped in CSS 2.1.

Various workarounds have been suggested, see e.g.
http://stackoverflow.com/questions/1363239/aligning-decimal-points-in-html

Two simple approaches:
1) Use monospace font and append no-break spaces &nbsp; to the values so
that each of them has the same number of characters to the right of the
decimal point, and set text-align: right on the cells in CSS (or
align=right in HTML).
2) As above but use U+2007 FIGURE SPACE, &#x2007;, instead of no-break
space and use any fonts that contain this character. So the font won’t
need to be monospace. Font coverage is good,
http://www.fileformat.info/info/unicode/char/2007/fontsupport.htm
but I’m afraid some older versions of the fonts listed there may lack
FIGURE SPACE. Moreover, you need to select a font where all digits are
of equal width; this applies to most fonts commonly used on web pages,
but some fonts have “1” narrower than other digits.

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

[Evertjan.]

Dr J R Stockton <repl...@merlyn.demon.co.uk.invalid> wrote on 09 feb 2015
in comp.infosystems.www.authoring.stylesheets:

> After simplification, I have
>
> <table border=1>
> <tr><td>1.0</td><td>123.67</td></tr>
> <tr><td>22.5</td><td>1.6</td></tr>
> </table>
>
> What do I need to do to get the decimal points to line up vertically?
> I'm sure I've seen it described somewhere, but can no longer find it.
> Font is default serif,

methinks, that is where tables are for:

<style type='text/css'>
.tr1 {text-align:right;padding-right:0;}
.tr2 {text-align:left;padding-left:0;}
</style>

<table>
<tr><td class=tr1>12<td class=tr2>.123
<tr><td class=tr1>12555<td><td class=tr2>
<tr><td class=tr1><td class=tr2>.12345999
<tr><td class=tr1>5<td class=tr2>.123
<table>

> but if necessary could be monospace.

then, alternatively, you could use clientside javascript to
leftfill or rightfill with computed padding.

Serverside javascript code would be even easier:

<%
var w = Math.max(Math.round(Math.log(n)/Math.LN10),0)
%>

<span style='padding-left:<% = cpx*w %>px;'><% = n %></span>

where cpx is the character width and n is positive.

[not tested]


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Jukka K. Korpela]

2015-02-10, 11:12, Evertjan. wrote:

> methinks, that is where tables are for:

This is all about a table in the first place. What you are suggesting
means breaking the table structure so that a data item is split across
cells just for visual appearance:

> <tr><td class=tr1>12<td class=tr2>.123

This creates a major accessibility problem.

> then, alternatively, you could use clientside javascript to
> leftfill or rightfill with computed padding.

And how would you compute it?

> Serverside javascript code would be even easier:
>
> <%
> var w = Math.max(Math.round(Math.log(n)/Math.LN10),0)
> %>
>
> <span style='padding-left:<% = cpx*w %>px;'><% = n %></span>
>
> where cpx is the character width and n is positive.
>
> [not tested]

Obviously not tested, since simple testing when carried out properly
shows that is does not work. You don’t even have a “character width” to
start from. Using some experimentally determined value means that the
setup is font-dependent.

If you consider using padding, you should primarily consider using the
ch unit with some reasonable fallback using the em unit.

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

[Evertjan.]

"Jukka K. Korpela" <jkor...@cs.tut.fi> wrote on 10 feb 2015 in
comp.infosystems.www.authoring.stylesheets:


I:

>> Serverside javascript code would be even easier:
>>
>> <%
>> var w = Math.max(Math.round(Math.log(n)/Math.LN10),0)
>> %>
>>
>> <span style='padding-left:<% = cpx*w %>px;'><% = n %></span>
>>
>> where cpx is the character width and n is positive.>
>>
>> [not tested]

> Obviously not tested,

Of course, I just said so, You are smart!

> since simple testing when carried out properly

Did you?

> shows that is does not work.

What nonsense, are you just trying to be nasty?

The principle is ok, perhaps it needs some trimming.

"does not work" is not a valid term on this NG.

[JJ]

On Mon, 9 Feb 2015 20:38:14 +0000, Dr J R Stockton wrote:

> After simplification, I have
>
> <table border=1>
> <tr><td>1.0</td><td>123.67</td></tr>
> <tr><td>22.5</td><td>1.6</td></tr>
> </table>
>
> What do I need to do to get the decimal points to line up vertically?
> I'm sure I've seen it described somewhere, but can no longer find it.
> Font is default serif, but if necessary could be monospace.

You can use preformatted text for the values with monospace font using
non-breaking spaces at start of each values. Preformat it either from the
server side script (e.g. PHP) or JavaScript. When there are large number of
values to process, it's faster using server side script, but it burders the
server processing time.

If you're expecting 4 integer digits part of the values (e.g. 123456.12),
use 4 characters as the "aligning width". If the values can be negative,
increase the aligning width by 1 character. Use the aligning width and the
number of significant digits of each values to get the number of characters
needed for inserting the non-breaking space characters.

The result of the HTML code should be like below for 3 digits alignment
width:

<style>
td { font-family: monospace; }
</style>
<table border=1>
<tr><td>&nbsp;&nbsp;1.0</td><td>123.67</td></tr>
<tr><td>&nbsp;22.5</td><td>&nbsp;&nbsp;1.6</td></tr>
</table>

That was based on left alignment. You can use right alignment based on the
number of fractional digits part of the values. This would be simpler
because you don't have to bother about the negative sign.

The result of the HTML code should be like below for right alignment and 2
digits alignment width:

<style>
td { text-align:right; font-family: monospace; }
</style>
<table border=1>
<tr><td>1.0&nbsp;</td><td>123.67</td></tr>
<tr><td>22.5&nbsp;</td><td>1.6&nbsp;</td></tr>
</table>

To avoid having spaces before/after the values, you'll have to use the
highest number of integer/fractional digits of all of the values in the same
column, as the alignment width.

[Stan Brown]

On Tue, 10 Feb 2015 13:13:48 +0100, Evertjan. wrote:
> "does not work" is not a valid term on this NG.
>

If only. I do tech support in my day job, and probably half the
trouble reports I get are "does not work", with not a single detail.

Just once I'd like to write, "Sorry, you moron, my crystal ball is in
the shop. In exactly which way does it not work? Is there an error
message, perchance? Could you perhaps get an effing clue and send me
a screen shot?

But I don't.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You: http://preview.tinyurl.com/WhyWont

[tlvp]

On Tue, 10 Feb 2015 10:02:04 +0200, Jukka K. Korpela wrote:

> 2015-02-10, 6:11, tlvp wrote:
>
>> On Mon, 9 Feb 2015 20:38:14 +0000, Dr J R Stockton wrote:
>>
>>> What do I need to do to get the decimal points to line up vertically?
>>>

>> Use the align and char attributes, w/ values "char" and ".", respectively:
>>
>>: <td align="char" char="."> .
>>
>> That's reportedly OK in HTML 4.0 Strict, anyway :-) .
>

> Unfortunately, this part of HTML 4 was never implemented ...

Well, so much for my faith in Molly Holzschlag's {Special Edition Using
HTML 4, 6th Ed.} as "bible" for answering such questions -- destroyed :-{ !

So now, if I wanted to align along decimal points, I'd probably use a
3-column table approach, with each row including TD elements for: (i) a LH
column with flush-right, ragged-left text, to hold the integer portion of a
number; (ii) a very narrow center column, with centered text, to hold only
the decimal point; and (iii) a RH column, with flush-left, ragged-right
text, to hold the digits expressing the fractional part of a number:

... <TR><TD> ... </TD><TD align="right" width="20%"> 103</TD>
<TD align="center" width="3">.</TD>
<TD align="left" width="20%">14159... </TD>
<TD> ... </TD></TR> ...

The above for a row to display 103.14159... .

Sadder but wiser now, and grateful to you for having opened my eyes, I send
you my thanks and my cheers, -- tlvp

[tlvp]

On Tue, 10 Feb 2015 22:42:42 -0500, Stan Brown wrote:

> I do tech support in my day job, and probably half the
> trouble reports I get are "does not work", with not a single detail.
>
> Just once I'd like to write, "Sorry, you moron, my crystal ball is in
> the shop. In exactly which way does it not work?

Hi, Stan. For most users, "doesn't work" is the invitation to start a
conversation in which you extract the information most helpful to you in
sorting out the user's difficulties. Actual user has no idea which of the
myriad bits and pieces of circumstances surround the "not working" will be
of use to you, or would you rather be overwhelmed with all sorts of trivia,
most of them likely irrelevant to the problem at hand :-) ?

Case in point: my kitchen sink's garbage disposal recently stopped working.
Turn on the power to it, no disposal action. More details? Sure: it worked
just fine every time I needed it the day before. Of no interest? OK, maybe:
But water flows through it just fine, the sink isn't stopped up. No use
either? How about: the little hex wrench the OEM supplied turns the motor
rotor freely, with no binding or resistance, a full 360 degrees in either
direction. Power? Yes, when I throws the power switch on, I can hear a
quiet 60 cycle hum from the body of the disposal unit, it just doesn't do
anything.

Now more than half of that was utterly beside the point, and a waste of any
CS rep's time. But how's a user to know *which* part is beside the point?
That's for the CS rep to fish out, as erfficiently as possible, without any
angry "You moron, give me more details!" :-) .

But you knew that, I'm sure, and were just venting because good CS is hard.

Sorry if I've offended -- wasn't meant to happen that way. Cheers, -- tlvp

[PS: new garbage disposal unit is now installed to replace the dead one --
likely, given the hum, a damaged motor winding, or a fried condenser :-) .]

[Evertjan.]

tlvp <mPiOsUcB...@att.net> wrote on 11 feb 2015 in
comp.infosystems.www.authoring.stylesheets:

> Hi, Stan. For most users, "doesn't work" is the invitation to start a

> conversation ...

"I would love to be a volcano.

Just sleeping in the countryside,
and when, occasionally, I smoke,
they say: "Look, he is working."

[Dr J R Stockton]

In comp.infosystems.www.authoring.html message <mbcdsn$1sf$1@dont-
email.me>, Tue, 10 Feb 2015 10:02:04, Jukka K. Korpela
<jkor...@cs.tut.fi> posted:

>> On Mon, 9 Feb 2015 20:38:14 +0000, Dr J R Stockton wrote:
>>
>>> After simplification, I have
>>>
>>> <table border=1>
>>> <tr><td>1.0</td><td>123.67</td></tr>
>>> <tr><td>22.5</td><td>1.6</td></tr>
>>> </table>
>>>
>>> What do I need to do to get the decimal points to line up vertically?
>>> I'm sure I've seen it described somewhere, but can no longer find it.
>>> Font is default serif, but if necessary could be monospace.

>Two simple approaches:
>1) Use monospace font and append no-break spaces &nbsp; to the values
>so that each of them has the same number of characters to the right of
>the decimal point, and set text-align: right on the cells in CSS (or
>align=right in HTML).
>2) As above but use U+2007 FIGURE SPACE, &#x2007;, instead of no-break
>space and use any fonts that contain this character. So the font won’t
>need to be monospace. Font coverage is good,
>http://www.fileformat.info/info/unicode/char/2007/fontsupport.htm
>but I’m afraid some older versions of the fonts listed there may lack
>FIGURE SPACE. Moreover, you need to select a font where all digits are
>of equal width; this applies to most fonts commonly used on web pages,
>but some fonts have “1” narrower than other digits.

This is a local data-processing application; come to think of it, I
could have written it perfectly well a quarter of a century ago in
Borland TurboPascal 5 on DOS 3.3 (and I can do that still, but that I
have no printer connected there). And in HTML I could have used a PRE
instead of a TABLE.

But it looks nicer as a Table. Given your suggestions and the routines
already available to my page, I just used my ordinary unsigned number-
formatting function StrT, which previously has always been used either
with monospace or with M=1 and wrapped it as
function STRT(X, M, N) {
return StrT(X, M, N).replace(/ /g, "\u2007") }
which works perfectly.

The font will be a very conventional one, currently Times New Roman. In
Verdana, Centaur, Papyrus, Pristina and Latha, \u2007 is recognised as a
space; the alignment fails only in Pristina and Latha (thin 1).

Thanks, and also to the others who contributed.

--
(c) John Stockton, nr London, UK. E-mail, see Home Page. Turnpike v6.05.
Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Swifty]

On 11/02/2015 05:38, tlvp wrote:
> So now, if I wanted to align along decimal points, I'd probably use a
> 3-column table approach

I was going to suggest a 2-column approach, with the integer portion
right-aligned in the left column and the decimal part (including the
decimal point) left-aligned in the right-hand column.

--
Steve Swift
http://www.swiftys.org.uk/

[Swifty]

On 11/02/2015 06:04, tlvp wrote:
> For most users, "doesn't work" is the invitation to start a
> conversation

In my case (I'm a somewhat argumentative person) it's an opportunity to
reply "Oh, yes it does" or "It does for me"... :-)

Actually, experience has shown me that one of the best ways of finding
out how to get something tricky done, is to assert that it cannot be
done... people just fall over themselves to prove me wrong, supplying my
answer as a by-product.

So, I would have said something along the lines of:

"I'm trying to arrange a numerical column in a table to align on the
decimal point, but it seems this cannot be done..."

[Jukka K. Korpela]

2015-02-19, 21:32, Swifty wrote:

> On 11/02/2015 05:38, tlvp wrote:
>> So now, if I wanted to align along decimal points, I'd probably use a
>> 3-column table approach
> I was going to suggest a 2-column approach, with the integer portion
> right-aligned in the left column and the decimal part (including the
> decimal point) left-aligned in the right-hand column.

Both approaches work in the technical sense of producing the desired
layout. However, they are clumsy and break the logical structure of the
table, and one might say that this is much worse than simple “use of
tables for layout”. Here the data is tabular, but marked up in a manner
that does not correspond to its structure and may break operations that
rely on table markup.

If this is for your own use, or for otherwise limited use, this may not
matter. In accessibility, it matters. For example, a blind person using
a speech browser will have the table content available in a confusing
way, not as a nice grid where cells are accessible with row and column
identifiers.


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

[dorayme]

In article <mc5ibp$q3a$1...@dont-email.me>,

"Jukka K. Korpela" <jkor...@cs.tut.fi> wrote:

> 2015-02-19, 21:32, Swifty wrote:
>
> > On 11/02/2015 05:38, tlvp wrote:
> >> So now, if I wanted to align along decimal points, I'd probably use a
> >> 3-column table approach
> > I was going to suggest a 2-column approach, with the integer portion
> > right-aligned in the left column and the decimal part (including the
> > decimal point) left-aligned in the right-hand column.
>
> Both approaches work in the technical sense of producing the desired
> layout. However, they are clumsy and break the logical structure of the

> table, and one might say that this is much worse than simple łuse of

> tables for layout˛. Here the data is tabular, but marked up in a manner
> that does not correspond to its structure and may break operations that
> rely on table markup.
>
> If this is for your own use, or for otherwise limited use, this may not
> matter. In accessibility, it matters. For example, a blind person using
> a speech browser will have the table content available in a confusing
> way, not as a nice grid where cells are accessible with row and column
> identifiers.

I am pretty sure I argued once here a long time back that the decimal
point itself could be considered a tabular datum. Not sure how good
the argument was, I know I liked it at the time! <g>

--
dorayme

[Jon Fairbairn]

"Jukka K. Korpela" <jkor...@cs.tut.fi> writes:

> 2015-02-19, 21:32, Swifty wrote:
>
>> On 11/02/2015 05:38, tlvp wrote:
>>> So now, if I wanted to align along decimal points, I'd probably use a
>>> 3-column table approach
>> I was going to suggest a 2-column approach, with the integer portion
>> right-aligned in the left column and the decimal part (including the
>> decimal point) left-aligned in the right-hand column.
>
>

> If this is for your own use, or for otherwise limited use,
> this may not matter. In accessibility, it matters. For
> example, a blind person using a speech browser will have the
> table content available in a confusing way, not as a nice
> grid where cells are accessible with row and column
> identifiers.

How much would adding span mark up mess up accessibility? I’m
thinking of something on the lines of:

<td style="text-align: right">
1<span style="text-align: left; display:inline-block; width:3em">.5
</span>
</td>

where “3em” is something picked to be wide enough for the worst
case.

--
Jón Fairbairn Jon.Fa...@cl.cam.ac.uk

[Thomas 'PointedEars' Lahn]

[X-Post comp.infosystems.www.authoring.html,
comp.infosystems.www.authoring.stylesheets;
F'up2 comp.infosystems.www.authoring.stylesheets]

Jon Fairbairn wrote:

> How much would adding span mark up mess up accessibility?

I do not think it would. Screenreaders should be oblivious to asemantic
markup such as “span” elements (if they do not have WAI-ARIA attributes [0a]
specified or speech properties [0b] applied).

> I’m thinking of something on the lines of:
>
> <td style="text-align: right">
> 1<span style="text-align: left; display:inline-block; width:3em">.5
> </span>
> </td>
>
> where “3em” is something picked to be wide enough for the worst
> case.

WFM, thank you; however I would prefer that

text-align: "." center”; /* [1] */

was implemented in order to avoid bloated markup (you would need at least
the start and end tag of an element otherwise). It was supported by either
Chrome or Firefox. I do not understand why this feature was dropped, and
removed from the Specification with [2].

Please do not crosspost without Followup-To.


PointedEars
_______
[0a] <https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA>
[0b] <http://www.w3.org/TR/2012/CR-css3-speech-20120320/>
[1] <http://www.w3.org/TR/2012/WD-css3-text-20121113/#text-align>
[2] <http://www.w3.org/TR/2013/WD-css-text-3-20131010/#text-align-property>
--
When all you know is jQuery, every problem looks $(olvable).

[Thomas 'PointedEars' Lahn]

[X-Post comp.infosystems.www.authoring.html,
comp.infosystems.www.authoring.stylesheets;
F'up2 comp.infosystems.www.authoring.stylesheets]

Jon Fairbairn wrote:

> How much would adding span mark up mess up accessibility?

I do not think it would. Screenreaders should be oblivious to asemantic
markup such as “span” elements (if they do not have WAI-ARIA attributes [0a]
specified or speech properties [0b] applied).

> I’m thinking of something on the lines of:
>
> <td style="text-align: right">
> 1<span style="text-align: left; display:inline-block; width:3em">.5
> </span>
> </td>
>
> where “3em” is something picked to be wide enough for the worst
> case.

[Jukka K. Korpela]

2015-02-20, 11:45, Jon Fairbairn wrote:

> How much would adding span mark up mess up accessibility?

We can expect <span> tags as such to be irrelevant to accessibility,
except perhaps in cases where they break words: foo<span>bar</span>
might be taken as two words foo and bar rather than a single word
foobar. This would be inappropriate, but browsers are known to treat
<span> as “breaking” in some contexts.

> I’m
> thinking of something on the lines of:
>
> <td style="text-align: right">
> 1<span style="text-align: left; display:inline-block; width:3em">.5
> </span>
> </td>
>
> where “3em” is something picked to be wide enough for the worst
> case.

There is a (remote) possibility that a program that would otherwise
treat 1.5 as a number could get it wrong when the <span> markup is used.

But the “wide enough for the worst case” makes this approach rather
awkward. If it is wide, there will be a lot of excessive spacing. If
not, there is a real risk of not being wide enough.

When the code is programmatically generated, you could create the table
in two passes, finding out the maximum number of digits in the decimal
part in the first pass and using it to set widths in ch units in the
second pass. But I think several other approaches are easier to manage.

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

[Jukka K. Korpela]

2015-02-20, 0:36, dorayme wrote:

> I am pretty sure I argued once here a long time back that the decimal
> point itself could be considered a tabular datum. Not sure how good
> the argument was, I know I liked it at the time! <g>

Well, you could argue that a column of decimal numbers could be
alternatively marked up as two or three columns, and you could use
<colgroup> to make them a group. But I don’t think that would be natural.

Consider a trivial example of a table containing the heights and weights
of people. If proper markup is used and the user agent is advanced
enough, a user (who possibly cannot see the entire table in his tiny
display device, or possibly cannot see anything at all) would be able to
use controls that effectively ask “What is the height of Jukka?” (if he
knows the structure of the table and expects Jukka to be one of the row
headers). But if the height is split to two or three cells, things get
much clumsier: the user needs to request for two data items, like “1”
and “.81”.

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