W3C home > Mailing lists > Public > www-html@w3.org > November 2002

Re: Element for Numbers

From: Mikko Rantalainen <mira@st.jyu.fi>
Date: Tue, 19 Nov 2002 22:54:39 +0200
Message-ID: <3DDAA50F.7000304@st.jyu.fi>
To: www-html@w3.org
CC: Christoph Päper <christoph@paeper.de>

Christoph Päper wrote:
> Mikko Rantalainen <mira@st.jyu.fi>:
>><date time="2002-11-19T13:24:38+02:00" lang="fi">13:25 19.11.2002</date>
> 
>>Default rendering would be to replace content
>>with localized date and time.
> 
> I'm not so sure about that. The document language is IMHO more important,
> but if for instance the document has Content-Language: de and/or <html
> xml:lang="de" ...> then somewhere in the text appears <nr value="1234.5"
> dim="m">1'234,5m</nr>, which appears to be the de-CH form, but the UA is
> de-DE, it should replace the content with "1.234,5 m". Make your own example
> for en-UK/en-US and a date.

I agree that in some cases it's important that numbers aren't localized 
to the area the reader is located to but for things like distances and 
time I'd really love to always see localized value. For example, when 
visiting news servers (as in news web portals, not as in newsgroup feed) 
I'm constantly speding my time to decide when a given piece of news was 
released. Seeing something like "01/04/03 01:52 a.m. CET" really doesn't 
help much. My browser does already know the timezone I'm using and I 
normally do measure time in local time instead of UTC or something else. 
It's not like the meaning would change if the date and time would be 
localized. The same thing applies to distances and other stuff we 
normally use. Writing stuff like "This boat can do 25 nautical miles per 
hour" doesn't tell me much about its speed (well, I can make an educated 
guess...) but if that is replaced with "This boat can do 46.3 km/h" 
tells me immediatly how fast that is.

But really, I don't care if default rendering is inline display with si 
units in the tooltip. I'm just hoping that page authors would support 
this and if the difference doesn't show up by default not that many 
authors are going to support this.


>>As for numbers, I'd just use nr element with only a few types:
>><nr type="integer" value="32847983265981263589632">3.3e22</nr>
> 
> I don't like 'type' to be used as an attribute name, if its value isn't a
> MIME type.

I really don't consider that as an issue--I'm pretty sure that using 
"type" wouldn't cause any problems in this case. What else you could 
call the difference between integer, real and literal values?


>><nr type="real" value="3.14159265359">PI</nr> -- a real number
> 
> So, should 'value' be allowed to have symbols like &pi;, e (Euler) or even
> whole equations in it?

I was thinking about that too, but I think it'll make things too 
complicated and no browser will support that. I'll rather take a lesser 
spec that's supported than an uber spec that no-one can implement.

>>nr element could also have attribute called "unit" and
> 
> 'Unit', 'dim' -- whatever.

English isn't my native language but "unit" seems clear to me whereas 
"dim" makes me think "dimension". It really doesn't sound right when all 
the stuff only has one dimension so why to define it for every element?

>>possible values for it would be si units plus 3 letter currency acronyms.
> 
> These are the most important, but imagine
> 
>   "I paid 7 camels for my second wife."
> 
> One of the reasons for my proposal was to have an element that enclosed the
> number and its 'unit', in this case  <nr>7 camels</nr>, thus having the
> possibility to avoid linebreaking between them. What should the attribute
> for this example look like?

I think "I paid <nr>7 camels</nr>..." would be the best way. This is a 
fine example for stuff that the browser shouldn't try to localize. And 
because default numberic type would be "literal" you don't need to put 
that in explicit attribute.

>>unit should probably allow things like "mm^2" and "m/s" too.
> 
> It really should, but it doesn't make implementation easier.

All(?) SI units only contain exponents, divisions and multiplications. 
Browsers only need intelligence to convert "^$X" to "<sup>$x</sup>" and 
rest should be ok as is. Much easier than supporting a set of constants 
for the value.

>>That stick is <nr value="0.6" unit="m">2 feet</nr> long.
> That's only approximately used correctly.

What do you mean "approximately"? Do you mean that 0.6000 m != 2.000 ft 
or something else? Context seems to hint that 2 feet isn't exact value 
so I think it's fine to do not that exact conversion. Partly for this 
reason I suggested the "precision" attribute.

>>Just my <nr value="0.02" type="real" unit="EUR">2 cents</nr>.
>>Just my 2 cents (0.02 EUR).
> 
> This is a bad example, IMO. It's an example for when the attributes should
> be omitted.

"2 cents" refers here to 0.02 euros instead of 0.02 dollars like 
usually, or have I misunderstood something? Granted, that wasn't very 
good example.

-- 
Mikko
Received on Tuesday, 19 November 2002 15:55:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:53 GMT