By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,648 Members | 1,190 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,648 IT Pros & Developers. It's quick & easy.

Alignment to char and other things

P: n/a
[My first post from Google Groups. Hope it's readable.]

I'm working with some semi-advanced tables with lots of decimal
numbers in, and I can't get the alignment to work.

http://www.algonet.se/~gustafl/temp/output_ib.html

I want numbers aligned to the decimal point. The HTML 4 spec says User
agents doesn't need to support 'char' and 'charoff', so I wonder if
the problem is lack of support? If so, can the same results be
achieved in another way?

Next best would be aligning the number to right, but there seem to be
a problem with support for <colgroup> aswell. Am I right? Best
solution I found was to have a class for right alignment and call it
from each <td>.

Also, can someone give me a way to prevent negative numbers to break
after the minus? A solution that adds the least clutter to the code?
Would it be right typographically to replace the minus with an
'endash' (#x2013;)?

Thanks,

Gustaf
Jul 20 '05 #1
Share this Question
Share on Google+
30 Replies


P: n/a
Gustaf Liljegren wrote:
[My first post from Google Groups. Hope it's readable.]
Looks fine.
I'm working with some semi-advanced tables with lots of decimal
numbers in, and I can't get the alignment to work.

http://www.algonet.se/~gustafl/temp/output_ib.html

I want numbers aligned to the decimal point. The HTML 4 spec says User
agents doesn't need to support 'char' and 'charoff', so I wonder if
the problem is lack of support? If so, can the same results be
achieved in another way?


Use (or at least suggest) a monospaced font for the numbers. There's
little benefit to be achieved from decimal point-aligning numbers unless
each fo the place values line up.

--
Mark.
Jul 20 '05 #2

P: n/a
On 24 May 2004, Gustaf Liljegren wrote:
Also, can someone give me a way to prevent negative numbers to break
after the minus?
Have a look at
<http://www.cs.tut.fi/~jkorpela/html/nobr.html>
<http://www.cs.tut.fi/~jkorpela/dashes.html>
Would it be right typographically to replace the minus with an
'endash' (#x2013;)?


No.
- is a hyphen
− is a minus sign
– is an en-dash

Prefer decimal character references to hexadecimal references.

--
Top-posting.
What's the most irritating thing on Usenet?

Jul 20 '05 #3

P: n/a
"Gustaf Liljegren" <gu*****@algonet.se> wrote in
comp.infosystems.www.authoring.html:
I want numbers aligned to the decimal point. The HTML 4 spec says User
agents doesn't need to support 'char' and 'charoff', so I wonder if
the problem is lack of support?


I'm afraid that is exactly the problem.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #4

P: n/a
Gustaf Liljegren wrote:
[My first post from Google Groups. Hope it's readable.]
It looks fine; be careful when replying, as Google Groups replies tend
to use stange "quote" markers.
I want numbers aligned to the decimal point. can the same results be achieved in another way?
Use a fixed width font, and make sure the data has the same number of
decimal places, e.g., 2.087, 3.340, 4.000, etc.
Next best would be aligning the number to right,
Right, add right align presentation, and see how that works for you.
but there seem to be a problem with support for <colgroup> aswell. Am
I right?
No. text-align does not apply to <col> or <colgroup>.

http://www.w3.org/TR/CSS21/tables.html#q4

http://ln.hixie.ch/?start=1070385285&count=1
Best solution I found was to have a class for right alignment and
call it from each <td>.


I'm afraid that's the best solution for aligning only 1 column of a table.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/
Jul 20 '05 #5

P: n/a
On Mon, 24 May 2004 10:52:20 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:
I want numbers aligned to the decimal point.

can the same results be achieved in another way?


Use a fixed width font, and make sure the data has the same number of
decimal places, e.g., 2.087, 3.340, 4.000, etc.


You can also use %nbsp; to replace leading 0's, as in 10.42, 58.30,
&nbsp;9.85 ...
Jul 20 '05 #6

P: n/a

"Andreas Prilop" <nh******@rrzn-user.uni-hannover.de> wrote in message
news:Pine.GSO.4.44.0405241525400.12520-100000@s5b003...
On 24 May 2004, Gustaf Liljegren wrote:
Also, can someone give me a way to prevent negative numbers to break
after the minus?


Have a look at
<http://www.cs.tut.fi/~jkorpela/html/nobr.html>
<http://www.cs.tut.fi/~jkorpela/dashes.html>
Would it be right typographically to replace the minus with an
'endash' (#x2013;)?


No.
- is a hyphen
− is a minus sign
– is an en-dash

Prefer decimal character references to hexadecimal references.


Why is that, actually? It's certainly easier just to use the codes the way
they appear in the Unicode reference, and I don't know any benefit to using
decimal values. Also, assuming any can be cited, why would they be
applicable to Unicode references and not to color references?

Jul 20 '05 #7

P: n/a

"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net...
On Mon, 24 May 2004 10:52:20 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:
I want numbers aligned to the decimal point.

can the same results be achieved in another way?


Use a fixed width font, and make sure the data has the same number of
decimal places, e.g., 2.087, 3.340, 4.000, etc.


You can also use %nbsp; to replace leading 0's, as in 10.42, 58.30,
&nbsp;9.85 ...


You'll find that &nbsp; doesn't have the width of a digit. It seems to be
just over half of the width of a digit on IE6, Firefox, and Opera.

Unicode has &#x2007; ( ), "figure space", to serve this purpose. In my
IE6, though, this gives a box; in my Firefox it produces a space that's
slightly too wide; and in my Opera it seems to work just fine.

Jul 20 '05 #8

P: n/a
On Mon, 24 May 2004, Harlan Messinger wrote:
Prefer decimal character references to hexadecimal references.
Why is that, actually?


Decimal references are better supported among browsers:
<http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist.html>
<http://ppewww.ph.gla.ac.uk/~flavell/charset/quick#cons>
e.g. Netscape 4.x.
It's certainly easier just to use the codes the way
they appear in the Unicode reference,
Easy reading is hard writing.
_You_ as the author, as a single person convert only once. But your
million readers read a million times (hopefully).
and I don't know any benefit to using decimal values.


See above.

--
Top-posting.
What's the most irritating thing on Usenet?

Jul 20 '05 #9

P: n/a
On Mon, 24 May 2004, Harlan Messinger wrote:
Use a fixed width font, [ ... ]


You can also use %nbsp; to replace leading 0's, [ ... ]


You'll find that &nbsp; doesn't have the width of a digit.


It does - in a monospaced font.

--
Top-posting.
What's the most irritating thing on Usenet?

Jul 20 '05 #10

P: n/a

"Andreas Prilop" <nh******@rrzn-user.uni-hannover.de> wrote in message
news:Pine.GSO.4.44.0405241845390.13134-100000@s5b003...
On Mon, 24 May 2004, Harlan Messinger wrote:
Prefer decimal character references to hexadecimal references.
Why is that, actually?


Decimal references are better supported among browsers:
<http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist.html>
<http://ppewww.ph.gla.ac.uk/~flavell/charset/quick#cons>
e.g. Netscape 4.x.


Ah. Version 4.77 does understand the hex references, but indeed 4.02
doesn't.
It's certainly easier just to use the codes the way
they appear in the Unicode reference,


Easy reading is hard writing.
_You_ as the author, as a single person convert only once. But your
million readers read a million times (hopefully).


Aw, come on, you gave me a perfectly good reason above. Why did you have to
go and spoil it? Millions of people are going to read the code behind my
page--and I should be concerned with their ability to comprehend it? :-)

Jul 20 '05 #11

P: n/a

"Andreas Prilop" <nh******@rrzn-user.uni-hannover.de> wrote in message
news:Pine.GSO.4.44.0405241849140.13134-100000@s5b003...
On Mon, 24 May 2004, Harlan Messinger wrote:
Use a fixed width font, [ ... ]

You can also use %nbsp; to replace leading 0's, [ ... ]


You'll find that &nbsp; doesn't have the width of a digit.


It does - in a monospaced font.


Snort--well, *yeah*. :-P

Jul 20 '05 #12

P: n/a
"Harlan Messinger" <h.*********@comcast.net> wrote:
You'll find that &nbsp; doesn't have the width of a digit.
To be exact, there isn't even any guarantee that digits have equal width.
It just happens that almost (?) all fonts used by browsers have "tabular
digits" that have such a property. In traditional typography, this was
often not the case for digits used in running text - quite conceivably,
"1" was often narrower than "8".

But the space, or the no-break space, does not usually have the same
width as digits, as you say. Using a monospace font solves this problem
but results in a really poor, computerish look.
Unicode has &#x2007; ( ), "figure space", to serve this
purpose. In my IE6, though, this gives a box; in my Firefox it
produces a space that's slightly too wide; and in my Opera it seems
to work just fine.


I don't quite understand the Firefox behavior, but otherwise this is
understandable. Most fonts lack the figure space character, but
e.g. Arial Unicode MS has got it. If you say nothing about fonts on your
page, then your IE probably uses Times New Roman, and most probably some
font that hasn't got the character. Netscape class browsers and Opera
know how to use glyphs from different fonts when needed (which is
sometimes a stylistic problem), though Opera seems to have odd settings
in this respect. In any case, you probably see the Arial Unicode MS
glyph, or maybe a glyph from some less common font.

Consequently, the figure space is not a good solution at present for WWW
pages. It might work well for the purpose of nice alignment in intranets
where everyone has a sufficiently rich font and a sufficiently advanced
browser.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #13

P: n/a

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn*****************************@193.229.0.31. ..
"Harlan Messinger" <h.*********@comcast.net> wrote:
You'll find that &nbsp; doesn't have the width of a digit.
To be exact, there isn't even any guarantee that digits have equal width.


Granted, though practically speaking they do in modern fonts--at least, in
my experience, I've always been able to count on it--precisely because
anyone designing a general body font knows perfectly well that people need
them to align!
It just happens that almost (?) all fonts used by browsers have "tabular
digits" that have such a property. In traditional typography, this was
often not the case for digits used in running text - quite conceivably,
"1" was often narrower than "8".

But the space, or the no-break space, does not usually have the same
width as digits, as you say. Using a monospace font solves this problem
but results in a really poor, computerish look.
Unicode has &#x2007; ( ), "figure space", to serve this
purpose. In my IE6, though, this gives a box; in my Firefox it
produces a space that's slightly too wide; and in my Opera it seems
to work just fine.
I don't quite understand the Firefox behavior, but otherwise this is
understandable. Most fonts lack the figure space character, but
e.g. Arial Unicode MS has got it. If you say nothing about fonts on your
page,


I've got font: sans-serif on my test pages.
then your IE probably uses Times New Roman, and most probably some
font that hasn't got the character. Netscape class browsers and Opera
know how to use glyphs from different fonts when needed (which is
sometimes a stylistic problem), though Opera seems to have odd settings
in this respect. In any case, you probably see the Arial Unicode MS
glyph, or maybe a glyph from some less common font.

Consequently, the figure space is not a good solution at present for WWW
pages. It might work well for the purpose of nice alignment in intranets
where everyone has a sufficiently rich font and a sufficiently advanced
browser.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html


Jul 20 '05 #14

P: n/a
On Mon, 24 May 2004, Harlan Messinger wrote:
Decimal references are better supported among browsers:
e.g. Netscape 4.x.


Ah. Version 4.77 does understand the hex references, but indeed 4.02
doesn't.


Not only 4.02 but newer versions, too. Support for the hexadecimal form
was introduced somewhere between 4.6 and 4.8.

--
Top-posting.
What's the most irritating thing on Usenet?

Jul 20 '05 #15

P: n/a
On Mon, 24 May 2004, Jukka K. Korpela wrote:
You'll find that &nbsp; doesn't have the width of a digit.


But the space, or the no-break space, does not usually have the same
width as digits, as you say. Using a monospace font solves this problem
but results in a really poor, computerish look.


How about a zero (0) in the same colour as the background? It does not
much harm when displayed black-on-white.

--
Top-posting.
What's the most irritating thing on Usenet?

Jul 20 '05 #16

P: n/a
Andreas Prilop <nh******@rrzn-user.uni-hannover.de> wrote:
But the space, or the no-break space, does not usually have the same
width as digits, as you say. Using a monospace font solves this
problem but results in a really poor, computerish look.


How about a zero (0) in the same colour as the background? It does
not much harm when displayed black-on-white.


A shrewd idea. If you use a program to generate the markup, it's fairly
easy; to write it by hand would be a bit boring, but possible:
<td>123.45<span class="sp">00</span></td>
(with .sp { color: white; background: white; }, if your overall
background is white).

There's the risk that people start wondering what's wrong when they see
zeroes or blank depending on the browser and its mode.

For example, they see 123.45 on screen but 123.4500 on paper, maybe with
the digits 00 in gray. This is not serious unless users start thinking
this is a symptom of something serious!

But it seems that using (instead of color setting) just
..sp { visibility: hidden; }
solves the problem both on screen and on print. Maybe even in speech. Or
is there any problem with this approach (apart the usual CSS caveats of
course)?

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #17

P: n/a
Jukka K. Korpela wrote:
Andreas Prilop <nh******@rrzn-user.uni-hannover.de> wrote:
But the space, or the no-break space, does not usually have the

same >> width as digits, as you say. Using a monospace font solves
this >> problem but results in a really poor, computerish look.

How about a zero (0) in the same colour as the background? It does
not much harm when displayed black-on-white.


A shrewd idea.


And one that might get you banned in search engines.

--
Google Blogoscoped
http://blog.outer-court.com
Jul 20 '05 #18

P: n/a
On Thu, 27 May 2004, Jukka K. Korpela wrote:
How about a zero (0) in the same colour as the background? It does
not much harm when displayed black-on-white.


<td>123.45<span class="sp">00</span></td>
(with .sp { color: white; background: white; }, if your overall
background is white).

For example, they see 123.45 on screen but 123.4500 on paper, maybe with
the digits 00 in gray.

But it seems that using (instead of color setting) just
.sp { visibility: hidden; }
solves the problem both on screen and on print.


The question was about right-aligning of numbers, therefore writing

00123
01234
12345

for example.

--
Top-posting.
What's the most irritating thing on Usenet?

Jul 20 '05 #19

P: n/a
On 27 May 2004, Philipp Lenssen wrote:
How about a zero (0) in the same colour as the background? It does
not much harm when displayed black-on-white.


A shrewd idea.


And one that might get you banned in search engines.


Have you got any evidence?

--
Top-posting.
What's the most irritating thing on Usenet?

Jul 20 '05 #20

P: n/a
Andreas Prilop wrote in
<Pine.GSO.4.44.0405271455430.5348-100000@s5b003>
On 27 May 2004, Philipp Lenssen wrote:
How about a zero (0) in the same colour as the background? It does
not much harm when displayed black-on-white.

A shrewd idea.


And one that might get you banned in search engines.


Have you got any evidence?


Google certainly takes exception to text that's hidden by making it the same
colour as the background. However, there is some doubt as to whether this is
currently detectable by Google during the indexing of the site - if it's
reported as spam, then someone from Google would look at the site and, since
the implementation suggested above is patently not spam, I would have
thought that there should be no problem.

Never-the-less, as a general principle I'd avoid such methods if possible. I
wouldn't want to find that Google had found a way to automatically check for
same-colour text and had de-listed my site because it had discovered some on
my site. The Googlebot is probably less understanding than a Google human.

--
PeterMcC
If you feel that any of the above is incorrect,
inappropriate or offensive in any way,
please ignore it and accept my apologies.

Jul 20 '05 #21

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in
comp.infosystems.www.authoring.html:
Andreas Prilop <nh******@rrzn-user.uni-hannover.de> wrote:
But the space, or the no-break space, does not usually have the same
width as digits, as you say. Using a monospace font solves this
problem but results in a really poor, computerish look.


How about a zero (0) in the same colour as the background? It does
not much harm when displayed black-on-white.


A shrewd idea.
There's the risk that people start wondering what's wrong when they see
zeroes or blank depending on the browser and its mode.
For example, they see 123.45 on screen but 123.4500 on paper, maybe with
the digits 00 in gray.


I think there's a bigger problem: 123.45 and 123.4500 are not the
same number. 123.45 connotes accuracy to the nearest 0.01 (one part
in ten thousand, here), but 123.4500 connotes accuracy to the
nearest 0.0001 (one part in a million).

If CSS is supposed to be about presentation (as I think we all
agree), then putting in those zeroes as _content_ is not really
correct. They could be done as CSS with ":after", but support is
poor.

The only 100%-supported solution I can see is to use <pre> for the
table of numbers and supply the necessary blanks as &nbsp;.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #22

P: n/a
On Thu, 27 May 2004 14:59:47 +0200, Andreas Prilop
<nh******@rrzn-user.uni-hannover.de> wrote:
On 27 May 2004, Philipp Lenssen wrote:
How about a zero (0) in the same colour as the background? It does
not much harm when displayed black-on-white.

A shrewd idea.


And one that might get you banned in search engines.


Have you got any evidence?

From:

<http://www.google.com/webmasters/2.html>

<quote>
B. My web pages used to be listed and now they aren't.
.. . . .
3. Other reasons

If your page does not appear at all, here are some other possible
explanations.

.. . .

Your page was manually removed from our index, because it did not
conform with the quality standards necessary to assign accurate
PageRank. We will not comment on the individual reasons a page was
removed and we do not offer an exhaustive list of practices that can
cause removal. However, certain actions such as cloaking, writing text
that can be seen by search engines but not by users...
</quote>

However, although I can se how they can tell if you have hidden text
by using the <font> element, I haven't sen any requests in my logs
(last time I looked) for a style sheet by the googlebot.

Nick

--
Nick Theodorakis
ni**************@hotmail.com
nicholas_theodorakis [at] urmc [dot] rochester [dot] edu
Jul 20 '05 #23

P: n/a
On Fri, 28 May 2004 02:53:13 GMT, ni**************@hotmail.com (Nick
Theodorakis) wrote:

[...How about a zero (0) in the same color as the background?...]
[...one that might get you banned in search engines...]
[...Have you got any evidence?...]
"Your page was manually removed from our index,
because it did not conform with the quality
standards necessary to assign accurate PageRank." However, although I can se how they can tell if you have hidden text
by using the <font> element, I haven't sen any requests in my logs
(last time I looked) for a style sheet by the googlebot.


And you would not find such a request from any other search engine
either. Indexers treats "optional information", like CSS, for just
what it is, i.e. "optional".

Think about it; millions after millions of www pages to scan and
evaluate, how much extra processing power would it take for an indexer
to also start looking at presentational suggestions, combine those
with marked up content, and then try to judge how the combination
_may_look_ on the user side?

What "pisses me off" when it comes to indexing bots is that most of
them "through's in the towel" if they find a site that has its content
presented in two or more languages at the same time.

I do have a (not quite finished) site that Google lets me find _only_
if I do a search for _exact_ words and word-sequences that are
available on my _main_page_.

The available pages that makes for the site has been up and mostly
stable for months now but still I can not search for fragments of my
sub pages content and get a hit.

As I see it; Google does not like Swedish and English mixed into one
and the same set of documents.

--
Rex

Jul 20 '05 #24

P: n/a
Andreas Prilop <nh******@rrzn-user.uni-hannover.de> wrote:
The question was about right-aligning of numbers, therefore writing

00123
01234
12345

for example.


I guess we have been discussing different alignment issues. I don't see
much problem in right-aligning integers - the only question is whether
you use HTML (align="right") or CSS (text-align: right) and exactly how -
we would normally want to right-align entire columns, but there are
different problems involved in it.

Right-aligning numbers with a decimal point, "aligning to a character"
(as indicated in the Subject line) is much more difficult, and applying
your suggestion of 0's hidden with CSS looks like best shot so far.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #25

P: n/a
Under Subject: Re: Alignment to char and other things
Jan Roland Eriksson <jr****@newsguy.com> wrote:
What "pisses me off" when it comes to indexing bots is that most of
them "through's in the towel" if they find a site that has its
content presented in two or more languages at the same time. - - As I see it; Google does not like Swedish and English mixed into one
and the same set of documents.


I wonder why Google would do so. It surely _can_ do so, since it has
some (presumably simplistic) "heuristics" for guessing the content
language, probably still ignoring all protocol-correct ways of
announcing the language (maybe reasonably in practice, since I'm afraid
there are many pages with lang attributes provided by an authoring tool
by default, without paying the slightest attention to the actual
content language).

Maybe it just thinks that (what it sees as) language mixing is a
symptom of some attempt to fool search engines. We know that people
often put <meta> keywords in different languages not appearing in the
content, and this might (arguably) be regarded as a form of spamdexing.
And people might try the same by using various hiding techniques, e.g.
by putting the foreign language stuff as white on white text. (When you
do it in CSS, Google probably won't detect it, as discussed in this
thread.)

_Or_ bilingualism might just switch off some of the processing that
Google would otherwise do for the page. If it uses some techniques that
are somehow related to content language (for example, idealistically
speaking, techniques for reducing all inclined words to their base form
for indexing), it might simply not use them for a page that does not
seem to be in one particular language.

On the other hand, most bilingual pages are results of suboptimal
design. It's often a lazy man's solution to put two languages on one
page instead of creating two interlinked pages.

Consider, for example, a city where both Finnish and Swedish are
official languages. Should it create a bilingual site? Just as printed
material is often bilingual? (This puzzles me, but maybe it _is_
cheaper than printing two versions and taking care of the problem of
sending everyone the version he prefers.) I would say emphatically
"no". _People_ need not be bilingual, and even if they are, they
normally prefer reading in one of the languages. Bilingual pages waste
space and confuse people. (It is occasionally useful for a user to read
both versions, especially if neither of the languages is his native
language or if he knows both fairly well but does not understand a
particular wording. But links will let people access the other version
in such cases.)

But, of course, there are exceptions, such as bilingual dictionaries
and studies that present different language versions of a text for
critical or other purposes.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #26

P: n/a
Stan Brown <th************@fastmail.fm> wrote:
I think there's a bigger problem: 123.45 and 123.4500 are not the
same number.
Actually, they are. They are two different numerals for exactly the same
number. OK, this is nitpicking, since I do get your point:
123.45 connotes accuracy to the nearest 0.01 (one part
in ten thousand, here), but 123.4500 connotes accuracy to the
nearest 0.0001 (one part in a million).
This relates to the _practical meaning_ assigned to the numeral.
Since so many people say that trailing zeroes connote accuracy (I have
had interesting discussions on this in misc.metric-system), we need to
admit that they actually do - for some people at least. But such
conclusions are drawn at everyone's own risk. Similarly, if I say that
something is 800 mm wide, it is everyone's own choice to deduce that I
make the claim of being accurate to 0.5 millimeter (since I did not write
80 cm or 8 dm or 0.8 m). The only accuracy information that one has the
right to make the author responsible for is the information that has been
explicitly specified by the author, e.g. by writing
800 mm &plusmn; 0.4 mm
(Note that real accuracies in measurements and estimates would seldom be
describably in any reasonable accuracy by using just the idea that
trailing zeroes mattter.)
If CSS is supposed to be about presentation (as I think we all
agree), then putting in those zeroes as _content_ is not really
correct. They could be done as CSS with ":after", but support is
poor.
The difference between 123.45 and 123.4500 is in the presentation, not in
the number denoted. We probably disagree on the impact on connotations,
though I think we agree on the observation that the strength of
connotations depends on the context. If all numbers in a column of a
table have exactly four digits to the right of the decimal point, it is a
fair assumption that they are used for justification, so that trailing
zeroes might not connote accuracy. If I use an isolated 123.4500 in
prose, I admit that most people would probably think that I meant to
express greater accuracy than by 123.450 or 123.45.
The only 100%-supported solution I can see is to use <pre> for the
table of numbers and supply the necessary blanks as &nbsp;


I don't think we need <pre> for that, and if we use <pre>, we surely
don't need &nbsp;. If monospace fonts are acceptable, it is sufficient to
use <tt> and &nbsp;. Of course using CSS (e.g.,
td { font-family: Courier New, monospace }) is much simpler than using
<tt> in each cell, but the <tt> works when CSS is off, too.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #27

P: n/a
Jan Roland Eriksson wrote:
What "pisses me off" when it comes to indexing bots is that most of
them "through's in the towel" if they find a site that has its content
presented in two or more languages at the same time.
I used to have a small personal site on a university account whose
home page had text in two languages, and it showed up quite high in
Google, on the first page after several domains all used by one
individual. (insert minor grumble about domain selfishness here)
I do have a (not quite finished) site that Google lets me find _only_
if I do a search for _exact_ words and word-sequences that are
available on my _main_page_.

The available pages that makes for the site has been up and mostly
stable for months now but still I can not search for fragments of my
sub pages content and get a hit.


It seems that Google is slower than it used to be. It took me months
to get a restaurant's new site at the top of Google for a search of
the restaurant's name. It was not a question of getting indexed;
Googlebot had crawled the site. But Google was convinced that other
sites with very little relevant content should be higher. Eventually,
it caught up, and the new site is rated where I think it ought to be.

It may be a question of patience.

--
Brian (remove ".invalid" to email me)

Jul 20 '05 #28

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in
news:Xn*****************************@193.229.0.31:
As I see it; Google does not like Swedish and English mixed into one
and the same set of documents.

If you do a Google search of www.confluence.org using the terms
swedish english, you will find this page:
http://www.confluence.org/confluence.php?visitid=8092
On the other hand, most bilingual pages are results of suboptimal
design. It's often a lazy man's solution to put two languages on one
page instead of creating two interlinked pages. But, of course, there are exceptions, such as bilingual dictionaries
and studies that present different language versions of a text for
critical or other purposes.


When we have multiple language versions of a confluence visit
narrative, we present them in the same page. In part this is
done for 'historical reasons', due to the design of the
database and codebase. And we know there are issues with how
the confluence.php page is designed. Other than such issues,
do you(collectively) see it as a "problem" that we sometimes
have two(or more) versions of the narrative text on one page?

--
Dave Patton
Canadian Coordinator, Degree Confluence Project
http://www.confluence.org/
My website: http://members.shaw.ca/davepatton/
Jul 20 '05 #29

P: n/a
Dave Patton <no**@none.com> wrote:
When we have multiple language versions of a confluence visit
narrative, we present them in the same page. In part this is
done for 'historical reasons', due to the design of the
database and codebase.
It should be straightforward to modify the system so that two pages are
generated, with links to each other. But it might mean some hard work.
And we know there are issues with how
the confluence.php page is designed. Other than such issues,
do you(collectively) see it as a "problem" that we sometimes
have two(or more) versions of the narrative text on one page?


I'm not sure I see what you see as the design issue. But if I read the
English text on the page, I won't see the pictures at the start. The
Swedish text eats up space and prevents natural layout. Moreover, if I
didn't know Swedish, I might get a bit disturbed. Think about a page
containing first some text that is completely incomprehensible to you, or
just comprehensible enough to irritate you to ask what it is, or maybe
text in unknown characters.

Besides, the navigation (and some other essential parts) is in English
only. What would I do if I only knew Swedish? (If all the rest on the
site is in English only, it would still be useful to a Swedish-only
person who found the page via Google to know what the situation is, maybe
via a short note in Swedish about the site.)

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #30

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in
news:Xn*****************************@193.229.0.31:
Dave Patton <no**@none.com> wrote:
When we have multiple language versions of a confluence visit
narrative, we present them in the same page. In part this is
done for 'historical reasons', due to the design of the
database and codebase.
It should be straightforward to modify the system so that two pages
are generated, with links to each other. But it might mean some hard
work.


Yes - we pretty much know what we want to do, but to do it involves
quite a bit of work, so it's a matter of the people that can do the
work having the time to do it.
And we know there are issues with how
the confluence.php page is designed. Other than such issues,
do you(collectively) see it as a "problem" that we sometimes
have two(or more) versions of the narrative text on one page?


I'm not sure I see what you see as the design issue.


Things like table-based layout, validation errors, etc.
But if I read the
English text on the page, I won't see the pictures at the start.
Actually, there are no 'pictures', only thumbnails, but I know
what you mean. To really see each picture, you either have to
'click' on the thumbnail link, or use the "all pictures" links
at the bottom of the page. We have language issues with the
picture captions as well - currently, we allow multiple languages
in the captions:
http://www.confluence.org/confluence.php?visitid=8475
The
Swedish text eats up space and prevents natural layout.
Maybe not to someone who knows Swedish ;-)
Moreover, if I
didn't know Swedish, I might get a bit disturbed. Think about a page
containing first some text that is completely incomprehensible to you,
or just comprehensible enough to irritate you to ask what it is, or
maybe text in unknown characters.
Our philosophy has been to always have the narrative represent what
the confluence visitor submits. We always provide a version of the
narrative in English, but we do get submissions that provide narrative
text only using the native language of the person making the submission.
In such cases, we always have that language first, followed by English.
Some people have commented that they like this, because it gives them
a chance to better understand other languages, but that would also
be true if we had the different language versions on different pages.
Besides, the navigation (and some other essential parts) is in English
only.
What would I do if I only knew Swedish? (If all the rest on the
site is in English only, it would still be useful to a Swedish-only
person who found the page via Google to know what the situation is,
maybe via a short note in Swedish about the site.)


They could use our not-yet-released "translate this page" option :-)
It's simply going to make it easy to be on any page on our site,
and chose one of the online translation engines(e.g Google,
AltaVista) to 'machine translate' the page.

I do think the suggestion of a "short note about the site",
in multiple languages, is a good idea - I'll discuss it with
the other site coordinators. With confluence visits now in
148 countries, we have 'a few' language variations to deal with ;-)

--
Dave Patton
Canadian Coordinator, Degree Confluence Project
http://www.confluence.org/
My website: http://members.shaw.ca/davepatton/
Jul 20 '05 #31

This discussion thread is closed

Replies have been disabled for this discussion.