Proposed CSS 3 additions

[C A Upsdell]

Comments re these three related, proposed CSS 3 additions?

1. Add 'text-transform:time', which would transform text in the format
hours:minutes:seconds (24 hour clock) to the local format for displaying the
time, e.g. <span style="text-transform:time;">23:15</span> might be rendered
as 11:15PM or 23:15.

2. Add 'text-transform:date', which would transform text in the format
year-month-day to text in the local format for displaying the date, e.g.
<span style="text-transform:date;">2004-07-23</span> might be rendered
07/23/04, 23/07/04, 07/23/2004, 23/07/2004, or whatever.

3. Add 'text-transform:number', which would transform a number per the
local format for displaying a number, e.g. <span
style="text-transform:number;">123,456,789.01</span> might be rendered as
123,456,789.01, 123 456 789,01, 123.456.789,01, or whatever.

The objective, of course, is to be able to have times, dates, and numbers in
content rendered in formats with which the user is most familiar, e.g. into
the formats which in Windows are specified by Control Panel, Regional
Settings.

[Els]

C A Upsdell wrote:

Comments re these three related, proposed CSS 3 additions?

1. Add 'text-transform:time', which would transform text
in the format hours:minutes:seconds (24 hour clock) to the
local format for displaying the time, e.g. <span
style="text-transform:time;">23:15</span> might be rendered
as 11:15PM or 23:15.

2. Add 'text-transform:date', which would transform text
in the format year-month-day to text in the local format
for displaying the date, e.g. <span
style="text-transform:date;">2004-07-23</span> might be
rendered 07/23/04, 23/07/04, 07/23/2004, 23/07/2004, or
whatever.

3. Add 'text-transform:number', which would transform a
number per the local format for displaying a number, e.g.
<span style="text-transform:number;">123,456,789.01</span>
might be rendered as 123,456,789.01, 123 456 789,01,
123.456.789,01, or whatever.

The objective, of course, is to be able to have times,
dates, and numbers in content rendered in formats with
which the user is most familiar, e.g. into the formats
which in Windows are specified by Control Panel, Regional
Settings.

Why the local format?

If I'm reading an English webpage in Holland, I expect
1000,000 to mean 1 million. If the local format would be
applied, 1000,000 means 1000 and zero thousandths.
(is that an English word?)

Same goes for the date, although maybe less problematic.
My local (Dutch) format for date is day-month-year.
But when I'm reading an American page, I expect 7-3-1999 to
mean the 3rd of July, not the 7th of March.

As for the time, I don't know what the local format would
mean. The format I installed on my pc, or what is most common
in the country? We use both 3pm and 15.00. I prefer the 24
hour system, but not everybody is the same.

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

[C A Upsdell]

"Els" <el*********@tiscali.nl> wrote in message
news:Xn*****************@130.133.1.4...

C A Upsdell wrote:

Comments re these three related, proposed CSS 3 additions?

1. Add 'text-transform:time', which would transform text
in the format hours:minutes:seconds (24 hour clock) to the
local format for displaying the time, e.g. <span
style="text-transform:time;">23:15</span> might be rendered
as 11:15PM or 23:15.

2. Add 'text-transform:date', which would transform text
in the format year-month-day to text in the local format
for displaying the date, e.g. <span
style="text-transform:date;">2004-07-23</span> might be
rendered 07/23/04, 23/07/04, 07/23/2004, 23/07/2004, or
whatever.

3. Add 'text-transform:number', which would transform a
number per the local format for displaying a number, e.g.
<span style="text-transform:number;">123,456,789.01</span>
might be rendered as 123,456,789.01, 123 456 789,01,
123.456.789,01, or whatever.

The objective, of course, is to be able to have times,
dates, and numbers in content rendered in formats with
which the user is most familiar, e.g. into the formats
which in Windows are specified by Control Panel, Regional
Settings.

Why the local format?

If I'm reading an English webpage in Holland, I expect
1000,000 to mean 1 million. If the local format would be
applied, 1000,000 means 1000 and zero thousandths.
(is that an English word?)

Same goes for the date, although maybe less problematic.
My local (Dutch) format for date is day-month-year.
But when I'm reading an American page, I expect 7-3-1999 to
mean the 3rd of July, not the 7th of March.

As for the time, I don't know what the local format would
mean. The format I installed on my pc, or what is most common
in the country? We use both 3pm and 15.00. I prefer the 24
hour system, but not everybody is the same.

How your local formats are determined will, of course, be O/S dependent.
With Windows I believe that the default format is determined by your choice
of keyboard (e.g. Windows supports Dutch/Netherlands and Dutch/Belgium) but
with Control Panel / Regional Settings you can choose the format you
personally prefer. Indeed, I have done this for my PC, by specifying a
preferred date format of year/month/day even though that it not the standard
notation for my country.

When I said 'local format' above, I mean your PC's default format as
customized by you. So if you prefer a 24-hour clock, that is what you would
see.

You say that when you go to a US site, you expect to see information
formatted according to the US conventions. Presumably this means that when
you go to a Canadian site, your would expect to see information formatted
according to Canadian conventions: but do know what the conventions are for
all countries? (Hint: Canada uses both month/day/year and day/month/year.)
My proposal would enable the designer to use my proposed CSS3 additions to
ensure that dates, times, and numbers are formatted in YOUR preferred
format.

[Els]

C A Upsdell wrote:

"Els" <el*********@tiscali.nl> wrote in message
news:Xn*****************@130.133.1.4...

C A Upsdell wrote:

> Comments re these three related, proposed CSS 3
> additions?
>
> 1. Add 'text-transform:time', which would transform
> text in the format hours:minutes:seconds (24 hour clock)
> to the local format for displaying the time, e.g. <span
> style="text-transform:time;">23:15</span> might be
> rendered as 11:15PM or 23:15.
>
> 2. Add 'text-transform:date', which would transform
> text in the format year-month-day to text in the local
> format for displaying the date, e.g. <span
> style="text-transform:date;">2004-07-23</span> might be
> rendered 07/23/04, 23/07/04, 07/23/2004, 23/07/2004, or
> whatever.
>
> 3. Add 'text-transform:number', which would transform a
> number per the local format for displaying a number,
> e.g. <span
> style="text-transform:number;">123,456,789.01</span>
> might be rendered as 123,456,789.01, 123 456 789,01,
> 123.456.789,01, or whatever.
>
> The objective, of course, is to be able to have times,
> dates, and numbers in content rendered in formats with
> which the user is most familiar, e.g. into the formats
> which in Windows are specified by Control Panel,
> Regional Settings.
Why the local format?

If I'm reading an English webpage in Holland, I expect
1000,000 to mean 1 million. If the local format would be
applied, 1000,000 means 1000 and zero thousandths.
(is that an English word?)

Same goes for the date, although maybe less problematic.
My local (Dutch) format for date is day-month-year.
But when I'm reading an American page, I expect 7-3-1999
to mean the 3rd of July, not the 7th of March.

As for the time, I don't know what the local format would
mean. The format I installed on my pc, or what is most
common in the country? We use both 3pm and 15.00. I prefer
the 24 hour system, but not everybody is the same.

How your local formats are determined will, of course, be
O/S dependent. With Windows I believe that the default
format is determined by your choice of keyboard (e.g.
Windows supports Dutch/Netherlands and Dutch/Belgium) but
with Control Panel / Regional Settings you can choose the
format you personally prefer. Indeed, I have done this for
my PC, by specifying a preferred date format of
year/month/day even though that it not the standard
notation for my country.

When I said 'local format' above, I mean your PC's default
format as customized by you. So if you prefer a 24-hour
clock, that is what you would see.

You say that when you go to a US site, you expect to see
information formatted according to the US conventions.

Yes.
Presumably this means that when you go to a Canadian site,
your would expect to see information formatted according to
Canadian conventions: but do know what the conventions are
for all countries?
I don't. But as for the date, that's why I put 30-apr-2004 on
my site, there is no way anybody can misunderstand that.
(Hint: Canada uses both month/day/year
and day/month/year.)
Not everybody will use the CSS text-transform properties,
which means I would still have to look in the source to see if
7/3/2004 means 7 March or 3 July. I prefer to be able to
recognise "Ah, another Canadian site, so it means July 7"
instead of "Ah, another Candian site, let's look in the source
if it's the Canadian format or my own PC's format".
My proposal would enable the designer
to use my proposed CSS3 additions to ensure that dates,
times, and numbers are formatted in YOUR preferred format.

My OS is in American keyboard mode. With the local format on
numbers, numbers on a Dutch site would be
a million: 1000,000.
Any Dutch person on a Dutch site expects 1000.000.

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -
Now playing: Daryl Hall and John Oates - Rich Girl

[C A Upsdell]

"Els" <el*********@tiscali.nl> wrote in message
news:Xn****************@130.133.1.4...

Presumably this means that when you go to a Canadian site,
your would expect to see information formatted according to
Canadian conventions: but do know what the conventions are
for all countries?

Not everybody will use the CSS text-transform properties,
which means I would still have to look in the source to see if
7/3/2004 means 7 March or 3 July. I prefer to be able to
recognise "Ah, another Canadian site, so it means July 7"
instead of "Ah, another Candian site, let's look in the source
if it's the Canadian format or my own PC's format".

I understand your concern, but I wonder about your ability to guess (a) the
site's country and (b) the country's convention(s). E.g., what country is
my site http://www.upsdell.com/BrowserNews/ ?

Another point is that, since the use of text-transform would tell the
browser what type of content the text is (i.e., number, date, or time), the
browser could (perhaps optionally) pass this information on to the user when
the cursor hovers over the content. E.g., hovering the cursor over '7/3/04'
might display the tooltip 'month/day/year'.

[George Lund]

In message
<pm*********************@twister01.bloor.is.net.ca ble.rogers.com>, C A
Upsdell <cupsdell0311XXX@-.?.invalid> writes

1. Add 'text-transform:time', which would transform text in the format
hours:minutes:seconds (24 hour clock) to the local format for displaying the
time, e.g. <span style="text-transform:time;">23:15</span> might be rendered
as 11:15PM or 23:15.

2. Add 'text-transform:date', which would transform text in the format
year-month-day to text in the local format for displaying the date, e.g.
<span style="text-transform:date;">2004-07-23</span> might be rendered
07/23/04, 23/07/04, 07/23/2004, 23/07/2004, or whatever.

3. Add 'text-transform:number', which would transform a number per the
local format for displaying a number, e.g. <span
style="text-transform:number;">123,456,789.01</span> might be rendered as
123,456,789.01, 123 456 789,01, 123.456.789,01, or whatever.

It's completely backwards. This stuff should be in the mark-up
language, not in the styling language.

E.g. <time>23:15</time> should be the HTML to include a time, and if the
user wants to configure their browser to render times in a specific way,
then that should be between them and their user agent.

As a page author, if you want the user to see 11:15PM, then just write
it that way (!).

Ditto for date.

The number one is a bit dangerous - if it isn't clear from the context
whether "." or "," is the decimal separator, then the consequences of a
style sheet not getting applied could cause an industrial accident!

--
George Lund

[Els]

C A Upsdell wrote:

"Els" <el*********@tiscali.nl> wrote in message
news:Xn****************@130.133.1.4...

> Presumably this means that when you go to a Canadian
> site, your would expect to see information formatted
> according to Canadian conventions: but do know what the
> conventions are for all countries?

Not everybody will use the CSS text-transform properties,
which means I would still have to look in the source to
see if 7/3/2004 means 7 March or 3 July. I prefer to be
able to recognise "Ah, another Canadian site, so it means
July 7" instead of "Ah, another Candian site, let's look
in the source if it's the Canadian format or my own PC's
format".

I understand your concern, but I wonder about your ability
to guess (a) the site's country and (b) the country's
convention(s). E.g., what country is my site
http://www.upsdell.com/BrowserNews/ ?

Without looking at it, my first guess would be American. It
could just as well be Dutch though. My own site is a .com
domain, hosted in the USA, written in (hopefully UK-) English,
but I'm Dutch.

Then, looking at it:
I still think USA, and see your date is of an internationally
readable format: July 17, 2004. No matter where in the world I
am, I'll understand that format.
But, to know what site I'm on, I'll click on the trolley ;-)
Yep, USA. Or at least, aimed at the USA. Otherwise you
wouldn't have a seperate flag for "Canadian shoppers" :-)

Of course, the best way would be to Americanize every site in
the whole wide world, that way everybody knows what to expect
everywhere. (Mind you, I'm against that! ;-) )
Another point is that, since the use of text-transform
would tell the browser what type of content the text is
(i.e., number, date, or time), the browser could (perhaps
optionally) pass this information on to the user when the
cursor hovers over the content. E.g., hovering the cursor
over '7/3/04' might display the tooltip 'month/day/year'.

Now, there is something useful. Would have to be in the
validator too, just like the alt attribute is now. And not
accepting empty values...

Still remains the formatting of numbers though... 1000,000 !=
1000.000. You want a tooltip saying "one million"?

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

[C A Upsdell]

"George Lund" <ge****@lund.co.uk> wrote in message
news:Sj**************@lund.co.uk...

In message
<pm*********************@twister01.bloor.is.net.ca ble.rogers.com>, C A
Upsdell <cupsdell0311XXX@-.?.invalid> writes

1. Add 'text-transform:time', which would transform text in the format
hours:minutes:seconds (24 hour clock) to the local format for displaying thetime, e.g. <span style="text-transform:time;">23:15</span> might be renderedas 11:15PM or 23:15.

2. Add 'text-transform:date', which would transform text in the format
year-month-day to text in the local format for displaying the date, e.g.
<span style="text-transform:date;">2004-07-23</span> might be rendered
07/23/04, 23/07/04, 07/23/2004, 23/07/2004, or whatever.

3. Add 'text-transform:number', which would transform a number per the
local format for displaying a number, e.g. <span
style="text-transform:number;">123,456,789.01</span> might be rendered as
123,456,789.01, 123 456 789,01, 123.456.789,01, or whatever.
It's completely backwards. This stuff should be in the mark-up
language, not in the styling language.

I had thought of HTML changes, but since the proposed new feature would
control presentation, I thought it better as CSS.
E.g. <time>23:15</time> should be the HTML to include a time, and if the
user wants to configure their browser to render times in a specific way,
then that should be between them and their user agent.

As a page author, if you want the user to see 11:15PM, then just write
it that way (!).

Ditto for date.
But this leaves the content open to confusion. E.g. is 7/03/04
month/day/year, or day/month/year, or year/month/day, or what? One can
choose to use unambiguous formats -- e.g. 2004/07/03 is pretty clearly
year/month/day -- but this will annoy a lot of people who are convinced that
their way is the right way.
The number one is a bit dangerous - if it isn't clear from the context
whether "." or "," is the decimal separator, then the consequences of a
style sheet not getting applied could cause an industrial accident!

But this problem exists today: what is, for example, '100,001'? To many it
means one hundred thousand and one; to many others who use metric notations
it means one hundred + one thousandths.

[Els]

C A Upsdell wrote:

"George Lund" <ge****@lund.co.uk> wrote in message
news:Sj**************@lund.co.uk...

In message
<pm*********************@twister01.bloor.is.net.ca ble.roger
s.com>, C A Upsdell <cupsdell0311XXX@-.?.invalid> writes

>1. Add 'text-transform:time', which would transform text
>in the format hours:minutes:seconds (24 hour clock) to
>the local format for displaying the >time, e.g. <span
>style="text-transform:time;">23:15</span> might be rendered >as 11:15PM or 23:15.
>
>2. Add 'text-transform:date', which would transform text
>in the format year-month-day to text in the local format
>for displaying the date, e.g. <span
>style="text-transform:date;">2004-07-23</span> might be
>rendered 07/23/04, 23/07/04, 07/23/2004, 23/07/2004, or
>whatever.
>
>3. Add 'text-transform:number', which would transform a
>number per the local format for displaying a number, e.g.
><span
>style="text-transform:number;">123,456,789.01</span>
>might be rendered as 123,456,789.01, 123 456 789,01,
>123.456.789,01, or whatever.

It's completely backwards. This stuff should be in the
mark-up language, not in the styling language.

I had thought of HTML changes, but since the proposed new
feature would control presentation, I thought it better as
CSS.

E.g. <time>23:15</time> should be the HTML to include a
time, and if the user wants to configure their browser to
render times in a specific way, then that should be
between them and their user agent.

As a page author, if you want the user to see 11:15PM,
then just write it that way (!).

Ditto for date.

But this leaves the content open to confusion. E.g. is
7/03/04 month/day/year, or day/month/year, or
year/month/day, or what? One can choose to use unambiguous
formats -- e.g. 2004/07/03 is pretty clearly year/month/day
-- but this will annoy a lot of people who are convinced
that their way is the right way.

The number one is a bit dangerous - if it isn't clear from
the context whether "." or "," is the decimal separator,
then the consequences of a style sheet not getting applied
could cause an industrial accident!

But this problem exists today: what is, for example,
'100,001'? To many it means one hundred thousand and one;
to many others who use metric notations it means one
hundred + one thousandths.

yes, but it would be consistent within one site or language.
Are there English speaking countries where 100,001 means one
hundred thousand and one?

Disabling the stylesheet could be bad indeed.
Anywhere, 100001 will mean one hundred thousand and one.
The unstyled format however would have to be with "." and/or
"," too, or else it's impossible to distinguish between
1000,01 and 100,001.

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

[C A Upsdell]

"Els" <el*********@tiscali.nl> wrote in message
news:Xn*****************@130.133.1.4...

C A Upsdell wrote:

"Els" <el*********@tiscali.nl> wrote in message
news:Xn****************@130.133.1.4...

> Presumably this means that when you go to a Canadian
> site, your would expect to see information formatted
> according to Canadian conventions: but do know what the
> conventions are for all countries?

Not everybody will use the CSS text-transform properties,
which means I would still have to look in the source to
see if 7/3/2004 means 7 March or 3 July. I prefer to be
able to recognise "Ah, another Canadian site, so it means
July 7" instead of "Ah, another Candian site, let's look
in the source if it's the Canadian format or my own PC's
format".

I understand your concern, but I wonder about your ability
to guess (a) the site's country and (b) the country's
convention(s). E.g., what country is my site
http://www.upsdell.com/BrowserNews/ ?

Without looking at it, my first guess would be American. It
could just as well be Dutch though. My own site is a .com
domain, hosted in the USA, written in (hopefully UK-) English,
but I'm Dutch.

As it happens, I am Canadian. And, as it happens, we use two date formats:
mainly month/day/year in English-speaking Canada, and day/month/year in
French-speaking Canada, but there are plenty of exceptions.
Then, looking at it:
I still think USA, and see your date is of an internationally
readable format: July 17, 2004. No matter where in the world I
am, I'll understand that format.
And that is why I choose to use an internationally unambiguous format. But
many others do not.
But, to know what site I'm on, I'll click on the trolley ;-)
Yep, USA. Or at least, aimed at the USA. Otherwise you
wouldn't have a seperate flag for "Canadian shoppers" :-)
USA because I know that a lot more users are American than Canadian.

Another point is that, since the use of text-transform
would tell the browser what type of content the text is
(i.e., number, date, or time), the browser could (perhaps
optionally) pass this information on to the user when the
cursor hovers over the content. E.g., hovering the cursor
over '7/3/04' might display the tooltip 'month/day/year'.

Now, there is something useful. Would have to be in the
validator too, just like the alt attribute is now. And not
accepting empty values...

I would not have to be in a validator: since the browser can understand the
semantics, it needs no further information to tell it what tooltip is
appropriate.
Still remains the formatting of numbers though... 1000,000 !=
1000.000. You want a tooltip saying "one million"?

No, but it could be something like 'nnn,nnn.nn', which clearly says it uses
a ',' as a thousands separator, and '.' as a decimal separator.

[C A Upsdell]

"Els" <el*********@tiscali.nl> wrote in message
news:Xn*****************@130.133.1.4...

The number one is a bit dangerous - if it isn't clear from
the context whether "." or "," is the decimal separator,
then the consequences of a style sheet not getting applied
could cause an industrial accident!
But this problem exists today: what is, for example,
'100,001'? To many it means one hundred thousand and one;
to many others who use metric notations it means one
hundred + one thousandths.

yes, but it would be consistent within one site or language.
Are there English speaking countries where 100,001 means one
hundred thousand and one?

Yes, in the USA, and among the majority of Canadians who don't use the
metric notation. (It can be so confusing sometimes to be a Canadian, since
things like 100,001 could either be 100001 or 100 1/1000.)
Disabling the stylesheet could be bad indeed.

Well, if the stylesheet is disabled, then (a) the tooltip should not be
displayed, and (b) the information will be in the canonical format, e.g.
'<span style="text-transform:date;">2004/07/03</span> would display
2004/07/03, which is pretty unambiguous.

[Els]

C A Upsdell wrote:

Then, looking at it:
I still think USA, and see your date is of an
internationally readable format: July 17, 2004. No matter
where in the world I am, I'll understand that format.

And that is why I choose to use an internationally
unambiguous format. But many others do not.

My guess is that those are the same ones who won't use the
CSS3 style 'text-transform:date;'.

But, to know what site I'm on, I'll click on the trolley
;-) Yep, USA. Or at least, aimed at the USA. Otherwise you
wouldn't have a seperate flag for "Canadian shoppers" :-)

USA because I know that a lot more users are American than
Canadian.

> Another point is that, since the use of text-transform
> would tell the browser what type of content the text is
> (i.e., number, date, or time), the browser could
> (perhaps optionally) pass this information on to the
> user when the cursor hovers over the content. E.g.,
> hovering the cursor over '7/3/04' might display the
> tooltip 'month/day/year'.

Now, there is something useful. Would have to be in the
validator too, just like the alt attribute is now. And not
accepting empty values...

I would not have to be in a validator: since the browser
can understand the semantics, it needs no further
information to tell it what tooltip is appropriate.

That would be the first time such a thing is done by a browser
I think.

Still remains the formatting of numbers though... 1000,000
!= 1000.000. You want a tooltip saying "one million"?

No, but it could be something like 'nnn,nnn.nn', which
clearly says it uses a ',' as a thousands separator, and
'.' as a decimal separator.

For you and me maybe, but I doubt "everybody" knows what it
means when they hover over a number and then see a tooltip
'nnn,nnn.nn'...

Of course we can discuss this forever, let me just conclude my
arguments with "Personally, I would never use it".

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

[Gertjan Klein]

On Fri, 23 Jul 2004 16:51:33 GMT, "C A Upsdell"
<cupsdell0311XXX@-@[e-mail]> wrote:

Comments re these three related, proposed CSS 3 additions? [...]The objective, of course, is to be able to have times, dates, and numbers in
content rendered in formats with which the user is most familiar, e.g. into
the formats which in Windows are specified by Control Panel, Regional
Settings.

These seem sensible additions to me. I wonder, though, what would happen
if these additions are applied to inputs? That is, for e.g. a date input
(<input type=text>), if it has a default value (specified with the value
attribute), the text-transform could be applied - but what happens if
the user changes the date and submits the form? In which format would
the date be transmitted? Ideally, it would be transformed "back", but
this requires browser support beyond CSS I presume. If, on the other
hand, the date is sent back in the user's preferred format, the server
has no way of knowing (AFAICS) what format that is (other than, perhaps,
using JavaScript).

If the additions are not sensibly usable on inputs, that would seriously
limit their usability, I presume, as "display-only" dates/times could
have a different format (the user's preferred format) from the expected
format in inputs.

Gertjan.

--
Gertjan Klein <gk****@xs4all.nl>

[Els]

C A Upsdell wrote:

"Els" <el*********@tiscali.nl> wrote in message
news:Xn*****************@130.133.1.4...

>> The number one is a bit dangerous - if it isn't clear
>> from the context whether "." or "," is the decimal
>> separator, then the consequences of a style sheet not
>> getting applied could cause an industrial accident!
>
> But this problem exists today: what is, for example,
> '100,001'? To many it means one hundred thousand and
> one; to many others who use metric notations it means
> one hundred + one thousandths.
yes, but it would be consistent within one site or
language. Are there English speaking countries where
100,001 means one hundred thousand and one?

Yes, in the USA,

Aargh.. I meant "doesn't mean" instead of "means" in my
question.
It's here in Holland where it should be written as 100.001, to
me, in English, (UK and US) it's 100,001. Didn't know part of
Canada would use 100.001 too. So, if it is then styled to the
local format on a Canadian PC... Would that be metric or not?
and among the majority of Canadians who
don't use the metric notation. (It can be so confusing
sometimes to be a Canadian, since things like 100,001 could
either be 100001 or 100 1/1000.)

Disabling the stylesheet could be bad indeed.

Well, if the stylesheet is disabled, then (a) the tooltip
should not be displayed, and (b) the information will be in
the canonical format, e.g. '<span
style="text-transform:date;">2004/07/03</span> would
display 2004/07/03, which is pretty unambiguous.

For the date, yes, but the number?

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

[Matt]

Els wrote:

C A Upsdell wrote:

"Els" <el*********@tiscali.nl> wrote in message
news:Xn*****************@130.133.1.4...

>> The number one is a bit dangerous - if it isn't clear
>> from the context whether "." or "," is the decimal
>> separator, then the consequences of a style sheet not
>> getting applied could cause an industrial accident!
>
> But this problem exists today: what is, for example,
> '100,001'? To many it means one hundred thousand and
> one; to many others who use metric notations it means
> one hundred + one thousandths.
Since when was this 'metric'? I've never understood either 1,000 or 1.000
to be 'metric'.
yes, but it would be consistent within one site or
language. Are there English speaking countries where
100,001 means one hundred thousand and one?

Yes, in the USA,

Aargh.. I meant "doesn't mean" instead of "means" in my
question.
It's here in Holland where it should be written as 100.001, to
me, in English, (UK and US) it's 100,001. Didn't know part of
Canada would use 100.001 too. So, if it is then styled to the
local format on a Canadian PC... Would that be metric or not?

I write:
100 001.23
to mean one hundres thousand and one plus 23 thousandths. With a
non-breaking space, of course. I /think/ this is completely unambiguous.

and among the majority of Canadians who
don't use the metric notation. (It can be so confusing
sometimes to be a Canadian, since things like 100,001 could
either be 100001 or 100 1/1000.)
Presumably, context helps?

Disabling the stylesheet could be bad indeed.

Well, if the stylesheet is disabled, then (a) the tooltip
should not be displayed, and (b) the information will be in
the canonical format, e.g. '<span
style="text-transform:date;">2004/07/03</span> would
display 2004/07/03, which is pretty unambiguous.

For the date, yes, but the number?

If the number starts as 1234567890.1234567890 then styled:

US/UK etc:
1,234,567,890.1234567890

holland, etc:
1.234.567.890,1234567890

My preferred way, quite common IME:
1 234 567 890.1234567890

--
Matt
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Els]

Matt wrote:

Els wrote:

C A Upsdell wrote:

> But this problem exists today: what is, for example,
> '100,001'? To many it means one hundred thousand and
> one; to many others who use metric notations it means
> one hundred + one thousandths.
Since when was this 'metric'? I've never understood either
1,000 or 1.000 to be 'metric'.
Sorry, just copied the word from the other post.
I write:
100 001.23
to mean one hundres thousand and one plus 23 thousandths.
With a non-breaking space, of course. I /think/ this is
completely unambiguous.
Well, if the stylesheet is disabled, then (a) the tooltip
should not be displayed, and (b) the information will be
in the canonical format, e.g. '<span
style="text-transform:date;">2004/07/03</span> would
display 2004/07/03, which is pretty unambiguous.

For the date, yes, but the number?

If the number starts as 1234567890.1234567890 then styled:

US/UK etc:
1,234,567,890.1234567890

holland, etc:
1.234.567.890,1234567890

My preferred way, quite common IME:
1 234 567 890.1234567890

That works for numbers like 1234567890.1234567890.
But not for 123.456. I mean, the styling works, but unstyled
noone would know what it meant.

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

[Matt]

Els wrote:

Matt wrote:

Els wrote:

C A Upsdell wrote:

> > But this problem exists today: what is, for example,
> > '100,001'? To many it means one hundred thousand and
> > one; to many others who use metric notations it means
> > one hundred + one thousandths.

Since when was this 'metric'? I've never understood either
1,000 or 1.000 to be 'metric'.

Sorry, just copied the word from the other post.

Yeah, I just jumped on the most recent post :)

My preferred way, quite common IME:
1 234 567 890.1234567890

That works for numbers like 1234567890.1234567890.
But not for 123.456. I mean, the styling works, but unstyled
noone would know what it meant.

I forgot the true UK way. Before computers forced using . as the decimal
seperator, we used · -- a middle dot. We still do use it, when something
is handwritten, but I doubt there's many people who've configured AltGr +
.. to be · like I have :)

1,234,567,890·1234567890

1 234 567 890·1234567890

123.456
123·456
123,456
123 456

Choices, choices!

I'm not sure it's that much of a problem, since usually the correct order
of magnitude can be found by context.

--
Matt
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Els]

Matt wrote:

I forgot the true UK way. Before computers forced using .
as the decimal seperator, we used · -- a middle dot. We
still do use it, when something is handwritten, but I doubt
there's many people who've configured AltGr + . to be ·
like I have :)

I would never have thought of it, but now that you mention it,
I've seen the middle dot on supermarket receipts sometimes. :-)

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

[George Lund]

In message
<tW**********************@news01.bloor.is.net.cabl e.rogers.com>, C A
Upsdell <cupsdell0311XXX@-.?.invalid> writes

I had thought of HTML changes, but since the proposed new feature would
control presentation, I thought it better as CSS.

But it doesn't control the presentation - it seems to be a hint to the
user agent that _it_ should control the presentation.

If for some reason you _really_ wanted it to display in 24 hour format
regardless of user settings, then maybe some 'CSS' would be useful:
<time style="time-format: twenty-four-hour;">23:14</time>
would suggest a particular presentation for that time. But I wouldn't
think the CSS part of that would actually be a very common requirement.

Ditto for date.

But this leaves the content open to confusion. E.g. is 7/03/04
month/day/year, or day/month/year, or year/month/day, or what? One can
choose to use unambiguous formats -- e.g. 2004/07/03 is pretty clearly
year/month/day -- but this will annoy a lot of people who are convinced that
their way is the right way.

Clearly part of the mark-up would have to be an indication of the format
of the date. This would be useful for automatically processing HTML
documents in various ways.

Logically we'd either need an attribute which specified the format used,
or we'd need sub elements, i.e.
either <date format="mm/dd/yyyy">07/03/2004</date>
or <date><d>03</d>/<m>07</m>/<y>2004</y></date>

I'm completely convinced that this doesn't belong in CSS! The mark-up
should say "what the content is" - viz "a time", "a date". The styling
should (if needed) say "how to present the content", e.g. "24 hour
format", "user's choice of long date format", "this specific weird date
format I want but didn't feel like typing out each time I write a date
in my document".

--
George

[C A Upsdell]

"Gertjan Klein" <gk****@xs4all.nl> wrote in message
news:h7********************************@4ax.com...

On Fri, 23 Jul 2004 16:51:33 GMT, "C A Upsdell"
<cupsdell0311XXX@-@[e-mail]> wrote:

Comments re these three related, proposed CSS 3 additions?

[...]

The objective, of course, is to be able to have times, dates, and numbers incontent rendered in formats with which the user is most familiar, e.g. intothe formats which in Windows are specified by Control Panel, Regional
Settings.

These seem sensible additions to me. I wonder, though, what would happen
if these additions are applied to inputs? That is, for e.g. a date input
(<input type=text>), if it has a default value (specified with the value
attribute), the text-transform could be applied - but what happens if
the user changes the date and submits the form? In which format would
the date be transmitted? Ideally, it would be transformed "back", but
this requires browser support beyond CSS I presume. If, on the other
hand, the date is sent back in the user's preferred format, the server
has no way of knowing (AFAICS) what format that is (other than, perhaps,
using JavaScript).

The date should be input in three separate fields, I think. Allows for
drop-down boxes for selecting values, for example.

[C A Upsdell]

"Els" <el*********@tiscali.nl> wrote in message
news:Xn*****************@130.133.1.4...

It's here in Holland where it should be written as 100.001, to
me, in English, (UK and US) it's 100,001. Didn't know part of
Canada would use 100.001 too. So, if it is then styled to the
local format on a Canadian PC... Would that be metric or not?
I don't know for sure, but I suspect that selecting a Canadian French
keyboard would set the default to metric.
For the date, yes, but the number?

Then there would be ambiguity.

[C A Upsdell]

"Matt" <no******@spam.matt.blissett.me.uk> wrote in message
news:pa****************************@spam.matt.blis sett.me.uk...

Els wrote:

C A Upsdell wrote:

"Els" <el*********@tiscali.nl> wrote in message
news:Xn*****************@130.133.1.4...
>> The number one is a bit dangerous - if it isn't clear
>> from the context whether "." or "," is the decimal
>> separator, then the consequences of a style sheet not
>> getting applied could cause an industrial accident!
>
> But this problem exists today: what is, for example,
> '100,001'? To many it means one hundred thousand and
> one; to many others who use metric notations it means
> one hundred + one thousandths.

Since when was this 'metric'? I've never understood either 1,000 or 1.000
to be 'metric'.

I'm not sure if the term 'metric' in relationship to numbers means the same
thing outside Canada as it does inside. A metric number here is a number
with a space as a thousands separator, and a comma as a decimal separator.

[Dr John Stockton]

JRS: In article <pm*********************@twister01.bloor.is.net.ca ble.r
ogers.com>, dated Fri, 23 Jul 2004 16:51:33, seen in news:comp.infosyste
ms.www.authoring.stylesheets, C A Upsdell <cupsdell0311XXX@-.?> posted :

Comments re these three related, proposed CSS 3 additions?

1. Add 'text-transform:time', which would transform text in the format
hours:minutes:seconds (24 hour clock) to the local format for displaying the
time, e.g. <span style="text-transform:time;">23:15</span> might be rendered
as 11:15PM or 23:15.

2. Add 'text-transform:date', which would transform text in the format
year-month-day to text in the local format for displaying the date, e.g.
<span style="text-transform:date;">2004-07-23</span> might be rendered
07/23/04, 23/07/04, 07/23/2004, 23/07/2004, or whatever.

3. Add 'text-transform:number', which would transform a number per the
local format for displaying a number, e.g. <span
style="text-transform:number;">123,456,789.01</span> might be rendered as
123,456,789.01, 123 456 789,01, 123.456.789,01, or whatever.

The objective, of course, is to be able to have times, dates, and numbers in
content rendered in formats with which the user is most familiar, e.g. into
the formats which in Windows are specified by Control Panel, Regional
Settings.

The Regional Settings of a computer are not necessarily the preferred
settings of the user. In my local Public Library, in England, the
Regional Setting is American (I have complained) and the majority of
users are Korean.

If this is implemented, the documentation should suggest that the author
includes, on the site, in the appropriate language, something like

<div>
Regionalisation ...
Example : the 25th of December 2004 will appear as
<span style="text-transform:date;">2004-12-25</span>.
</div>
If the content of the span is replaced, perhaps using javascript, with a
new ISO-8601 date, I presume that conversion will occur; that could be
useful.

What would occur for dates such as 2004-06-31 or 2005-13-15 ?

What if the content of the span is an unambiguous date in a different
form? or a date in an ambiguous form such as mm/dd/yy or mm/dd/yyyy?

In the third case, does it add thousands separators to, say, 123456.7 or
does it only substitute them?
IMHO, multinationalisation is not progress; it perpetuates confusion.
Instead, one should internationalise, which means using a single form
that everybody can come to understand. We have such for dates YYYY-MM-
DD and times hh:mm:ss; programmers have 123456.789 for numbers, but the
world is divided on number separators.

For that, ISTM that the impractical best is 123.456*789 where that *
represents a raised filled dot intermediate in size between '.' & '0';
comma is left for separating successive numbers in a list.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Christoph Paeper]

*Matt* <no******@spam.matt.blissett.me.uk>:

Els wrote:

Matt wrote:

Since when was this 'metric'? I've never understood either
1,000 or 1.000 to be 'metric'.

Well, until recently (2003) the SI only allowed the comma as decimal
separator and no thousand separators except space. That's probably why.
I forgot the true UK way. Before computers forced using . as the decimal
seperator, we used · -- a middle dot.
And you wrote noöne (at least I was told so).
We still do use it, when something is handwritten, but I doubt there's
many
people who've configured AltGr + . to be · like I have :)
I did so, too, but need it for a different purpose: multiplication. AltGr
+ # is × here. Actually my keyboard layout allows me to input all
characters of ISO-8859-1 and many, if not most, of the other Latin
variants and is compatible with German standard, except for ° and ~, which
became dead keys.

JFTR, in German numbers would be usually interpreted like this:
123.456
123456, traditionally, but should be limited to monetary values nowadays,
which usually have two decimal places anyway making them internationally
unambiguous AND easy to read.
123·456
56088, but spaces are preferred around calculation signs.
123,456
123 456/1000, but people to whom it concerns usually know about different
usage in the Anglo-Saxon world.
123 456

123456.

--
The Hitchhiker's Guide to the Galaxy:
"He was a dreamer, a thinker, a speculative philosopher,
or, as his wife would have it, an idiot."

[Christoph Paeper]

*George Lund* <ge****@lund.co.uk>:

In message
<pm*********************@twister01.bloor.is.net.ca ble.rogers.com>, C A
Upsdell <cupsdell0311XXX@-.?.invalid> writes

1. Add 'text-transform:time',
2. Add 'text-transform:date',
3. Add 'text-transform:number',
It's completely backwards. This stuff should be in the mark-up
language, not in the styling language.

I proposed a general element for numbers (I called it 'nr', but that's
just one option) to the HTML Working Group of the W3C; others added their
wish for a specialised one for date and time, but the latest XHTML2 draft
from this week doesn't have either of them mentioned anymore. (Previously
'nr' was noted to be under consideration.)

Anyhow, if there was such an element---there might as well be markup
languages which do include something like it---it would be nice to
implement its default presentation with CSS. If the OP stays with his
wish, he should send it to and discuss at ww*******@w3.org.
The number one is a bit dangerous - if it isn't clear from the context
whether "." or "," is the decimal separator, then the consequences of a
style sheet not getting applied could cause an industrial accident!

As long as only a decimal separator and none for 3-digit groups is used,
there's hardly any chance for ambiguities in real life.

P.S.: I can't believe anyone still *writes* AM/PM.

--
"Space may be the final frontier,
but it's made in a Hollywood basement."

Red Hot Chili Peppers - Californication

[Brian]

C A Upsdell wrote:

since the use of text-transform would tell the browser what type of
content the text is (i.e., number, date, or time),
CSS is not really meant to convey information; it is to suggest a
presentation. And what if CSS is off? Users shouldn't lose information
in such a situation. As such, I don't think your idea makes sense.
the browser could (perhaps optionally) pass this information on to
the user when the cursor hovers over the content. E.g., hovering
the cursor over '7/3/04' might display the tooltip
'month/day/year'.

<span title="month/day/year">7/3/04<span>

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Gertjan Klein]

On Fri, 23 Jul 2004 21:54:45 GMT, "C A Upsdell" wrote:

"Gertjan Klein" <gk****@xs4all.nl> wrote in message
news:h7********************************@4ax.com.. .

These seem sensible additions to me. I wonder, though, what would happen
if these additions are applied to inputs?

The date should be input in three separate fields, I think. Allows for
drop-down boxes for selecting values, for example.

I've seen that argued here before, but IMHO the only people that would
argue such a thing are those that don't need to input dates that way
(especially on a regular basis). I've made browser-based applications
[1], where users would have lynched me for making them input dates
through three dropdown boxes, or even three inputs (and understandably
so). (In those applications, users configured their preferred date and
time format, and it was applied to inputs as well as text.)

But even if dates were input that way, that still leaves the discrepancy
between how they are *input* and how they are presented in text. Again,
this limits, IMHO, the usability of the proposed additions.

I suppose the only proper way to solve that discrepancy is to add
specific markup for date and time inputs as well.

Gertjan.

[1] I know the topic of this newsgroup is authoring for the WWW, but CSS
itself knows no such limitation, so proposed additions should be viewed
in a broader perspective.

--
Gertjan Klein <gk****@xs4all.nl>

[Dr John Stockton]

JRS: In article <pa****************************@spam.matt.blissett .me.u
k>, dated Fri, 23 Jul 2004 21:55:52, seen in news:comp.infosystems.www.a
uthoring.stylesheets, Matt <no******@spam.matt.blissett.me.uk> posted :

I write:
100 001.23
to mean one hundres thousand and one plus 23 thousandths. With a
non-breaking space, of course. I /think/ this is completely unambiguous.

It is unambiguous only if the string is known to contain _a_ number. It
can otherwise be interpreted as the number one hundred followed by the
number one decimal two three. Some systems may attempt to read the
second part as octal.

A space is an unsatisfactory separator.

A non-breaking space is often better.

A thin non-breaking space is better still.

There is a problem if a document set is searched for a number which is
known to look like '123 456' and the characters are not 49 50 51 32 52
53 54, unless the search software is smart.
Re something written by CAU : I am a bad typist; but I can type
2004-07-24 considerably faster than I can select it with drop-downs.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> JL / RC : FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Dr John Stockton]

JRS: In article <op**************@crissov.heim4.tu-clausthal.de>, dated
Sat, 24 Jul 2004 02:36:40, seen in news:comp.infosystems.www.authoring.s
tylesheets, Christoph Paeper <ch**************@nurfuerspam.de> posted :

*Matt* <no******@spam.matt.blissett.me.uk>:

Els wrote:

Matt wrote:

Since when was this 'metric'? I've never understood either
1,000 or 1.000 to be 'metric'.

Well, until recently (2003) the SI only allowed the comma as decimal
separator and no thousand separators except space. That's probably why.

In German, maybe.

I have relevant authoritative (NPL/NBS 1977, IUPAP-SUNAMCO 1987)
booklets which use a decimal point indistinguishable from a sentence
terminator, and a thin space for a thousands separator. The second
actually discusses that.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk / ??*********@physics.org ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)

[Christoph Paeper]

*Dr John Stockton* <sp**@merlyn.demon.co.uk>:

Christoph Paeper <ch**************@nurfuerspam.de> posted :

Well, until recently (2003) the SI only allowed the comma as decimal
separator and no thousand separators except space. That's probably why.
In German, maybe.

Here it is still just ','.
I have relevant authoritative (NPL/NBS 1977, IUPAP-SUNAMCO 1987)
booklets which use a decimal point indistinguishable from a sentence
terminator, and a thin space for a thousands separator.

Okay, I was misguided by the Wikipedia article on CGPM, which summarizes
the 22nd one of 2003 as follows:

| both the comma and dot on a line are accepted as decimal marker symbols

In fact, the dot on a line seems to have been adopted as early as 1948:
<http://www1.bipm.org/jsp/en/ViewCGPMResolution.jsp?CGPM=22&RES=10>
(Resolution 10 of said conference). The change in fact was that the BIPM
now uses '.' as decimal separator for their own English language
publications, but keeps ',' for the French ones (obviously these are their
only official languages).
Other standards bodies still use the comma exclusively, though. I've no
copy of for instance ISO*31 or the ISO*80000 drafts at hand to check what
they say.

None of them uses a thousands separator except for spaces, of course,
although the Swiss usage of the apostrophe would be pretty much
unambiguous, too.

I think that's enough about that, here. If required, let's continue in
m.m-s.

F'up2 misc.metric-system

--
"Not all chemicals are bad. Without chemicals such as hydrogen and oxygen,
for example, there would be no way to make water, a vital ingredient in beer."
Dave Barry