Proposed CSS 3 additions

"Els" <els.aNOSPAM (AT) tiscali (DOT) nl> wrote

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.

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 -

On Fri, 23 Jul 2004 16:51:33 GMT, "C A Upsdell"
<cupsdell0311XXX@-@- (AT) XXXrogers (DOT) com> 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 <gklein (AT) xs4all (DOT) nl>

C A Upsdell wrote:

"Els" <els.aNOSPAM (AT) tiscali (DOT) nl> wrote in message
news:Xns952FDF1E27459Els (AT) 130 (DOT) 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 -

Els wrote:

C A Upsdell wrote:

"Els" <els.aNOSPAM (AT) tiscali (DOT) nl> wrote in message
news:Xns952FDF1E27459Els (AT) 130 (DOT) 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! =-----

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 -

JRS: In article <pmbMc.1164468$Ar.540103 (AT) twister01 (DOT) bloor.is.net.cable.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.

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! =-----

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 -

In message
<tWdMc.276532$rCA1.166457 (AT) news01 (DOT) bloor.is.net.cable.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