W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2016

[csswg-drafts] [css-syntax][css-values] Awkward Decimal Fractions and Non-Finite Values

From: Christoph Päper via GitHub <sysbot+gh@w3.org>
Date: Wed, 03 Aug 2016 21:02:04 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-169233140-1470258122-sysbot+gh@w3.org>
Crissov has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [css-syntax][css-values] Awkward Decimal Fractions and Non-Finite 
Values ==
As noted in #315 by @dauwhe and @plinss and in #309 by me, some 
existing CSS units do not play well with decimal floating point 
numbers. These are **vulgar fractions** on the one hand, which can 
become rather **long but terminating**, like 1/16 = 0.0625, or 
**repeating**, like 1/12 = 0.08_3, and **irrational constants** on the
 other hand, e.g. π = 2·τ = 3.1415…, √2 = 1.4142… or φ = ½+√1¼ = 
1.6180…

The English typogaphical units (inch, pica and point) in particular 
are traditionally used either with vulgar fractions and a single unit 
(`in`) or with integer amounts of a mix of units (`pc` and `pt`, e.g. 
“1p2” for `14pt`). Both can be achieved by using `calc()`: 

    padding: calc(1in / 16);
    font-size: calc(1pc + 2pt);

Unless we add keywords for some common (quasi) constants to be used 
within `calc()`, the same approach doesn’t work for irrational 
numbers:

    color: hsl(calc(2 / 3 * pi), 50%, 100%);
    size: 8.5in calc(8.5in * sqrttwo);
    aspect-ratio: calc(phi); /* or 'golden' */

This is obviously not quite as convenient as handwritten or typeset 
values, which would look a bit like this if approximated with CSS 
syntax:

    padding: 1/16in;
    font-size: 1pc2;

I tried to show some possible solutions in #315 which I’ll repeat here
 for convenience and annotation. The example value was “3p4½” or “9/16
 inch” in classic notation. This can be expressed with `calc()` in 
several ways:

    calc(3pc + 4.5pt)        calc(3pc + 9pt / 2)        calc(3pc + 3pc
 / 8)        calc(9in / 16)

A natural adoption of the “p notation” would be function syntax:

    p(3, 4.5)     p(3 4.5)      p(3 p 4.5)    p(3pc 4.5pt)  p(40.5)

Parentheses or brackets might provide a way to escape restrictions by 
the core grammar:

    (3 p 4.5)     [3p4.5]

If the core grammar needed to be changed, there would be several ways 
it could be done that still mimic the traditional notation. The value 
for the secondary unit could be added either between the primary value
 and unit or after them, in both cases with a punctuation character 
used as separator. The third option would be similar to exponent `e` 
syntax with `p` and would be specific to the pica-point case.

    3-4.5pc       3+4.5pc       3:4.5pc       3,4.5pc       3/4.5pc
       3&4.5pc       3..4.5pc
    3pc-4.5       3pc+4.5       3pc:4.5       3pc,4.5       3pc/4.5
       3pc&4.5       3pc..4.5
    3p4.5pc       3p4.5pt

If it was possible to put two values around a base unit symbol like 
`pc` to specify the fractional value in the “sub-unit”, this would 
apply to other units as well and there needed to be agreement which 
units combine (e.g. `mm` and `q`):

    3pc4.5        40pt10        0in3.375      14mm1.15      57q37.5
       3cc2.1

Conversion to different units may bring nicer values, but does not fit
 the work flow. In some cases, integer values or nice fractions could 
be achieved only with additional units

    3.375pc       40.5pt        0.5625in      14.2875mm     57.15q
    810twip       38.1dd        14287.5um

Unicode characters beyond Basic Latin would cover several use cases 
(including constants), but probably not all of them. (Note the 
fraction slash U+2044.)

    3⅜pc          40½pt
    9⅟16in        9⁄16in        9÷16in

It would be *nice to have* a common solution to these related 
problems. I’m in no way claiming that I’ve already found it. I’m also 
not preferring one particular option out of the presented ones.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/378 using your GitHub 
account
Received on Wednesday, 3 August 2016 21:02:25 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:30:22 UTC