- From: Christoph Päper via GitHub <sysbot+gh@w3.org>
- Date: Wed, 31 Jan 2024 12:44:45 +0000
- To: public-css-archive@w3.org
It’s mostly the same use cases but limited to what is actually in scope of `text-transform`, i.e. digits and not numbers. I’m no i18n expert, but my understanding is that at least in some locales European digits are preferred in forms, formulas and tables, but native digits are preferred in prose – the data source may be the same. Several system APIs provide similar functions, e.g. [Win32](https://learn.microsoft.com/en-us/windows/win32/intl/digit-shapes) calls it _native digit shapes_ and provides unidirectional conversion towards local forms only. Background and plans ---------------------- I’m trying to explore how numeric data is presented: How much of it is styling and which part of CSS is best suited to deal with it, if any. Ultimately, I want CSS to be able to express various number and value formatting to support things like https://github.com/openui/open-ui/issues/499 declaratively without the need for scripting. If this proposal is seen as valid by the WG, it should be followed by others to style more parts of an actual number: * #4875 is about _adding_ grouping characters to numbers, but probably also to arbitrary (alphanumeric) strings. * Authors should also be able to _replace_ grouping characters (including to remove them), regardless whether they existed in content or were added by CSS. This should be in scope of `text-transform`. * … and decimal separators in numbers, i.e. comma vs. dot (but not remove them). * Zero-padding and truncating numbers may be considered styling, so although it’s out of scope for `text-transform` it’s in scope of CSS. * I’d then also consider to propose deprecating the never-implemented [`text-align: <string>` in table cells](https://www.w3.org/TR/css-text-4/#character-alignment) in favor of leading (or trailing) invisible zeros. * Applications may select shorter representations of the same data with possibly reduced precision, especially in tables, e.g. for dates (`JAN31` vs. `2024-01-31` vs. `Wednesday, 31st January of 2024 AD`) or file sizes (`1,234,567 B` vs. `1,235 kB` vs. `1.2 MB`) – perhaps in scope of [`text-overflow`](https://drafts.csswg.org/css-overflow-4/#propdef-text-overflow). * Grouping and separating is similar to splitting up a number into separate parts which can be formatted individually, but this is a slippery slope towards full unit conversion: `123.456789°` ≈ `123°27′24.44″`, `123456.789 s` = `1 d 10 h 17 m 36.789 s` = `34:17:36.789` ≈ `1.429 d`, `12.345 m` = `12,345 mm` ≈ `486 in` = `40.5 yd` = `40′ 6″` … -- GitHub Notification of comment by Crissov Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9877#issuecomment-1919036223 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 31 January 2024 12:44:48 UTC