[css-rhythm][css-values][css-cascade] length-precision for Actual Values

[Crissov]

• CSS Rhythmic Sizing only deals with box and line heights for now
• actual value
• <length>
• affects: [css-borders] Add a 'hairline' border-width value #3720

Browsers may need to round the used value to a different actual value in order to match the capabilities of the output device, e.g. integer values of device pixels. Authors may be fine with or even benefit from a less precise actual value, e.g. when they are designing every length with a step value of 1px (CSS pixels) anyway. In addition to introducing a per-case math function like round() or mod() #2513, I would like to propose a cascading property to specify the desired accuracy of transforming any calculated value into a used value (which the browser may still need to change for the actual value).

length-precision: [auto | high | low | <length> | <step-unit> | <storage-unit> | integer] 
               || [<round>]
<step-unit>: pixel | dot | twip | emu | um
/* <storage-unit>: [<positive-integer> bit] 
                 | [signed? [crumb | nibble | byte | char
                   | [half | short | long | double | quad] [float? | int]]] */
<round>: up | down | nearest 
       | to-zero | from-zero | floor | ceil

• auto (or medium):
  default, depends solely on the capabilities of the user agent and hardware setup, should be smaller than 1px (It's apparently 1/60, 1/64 and 1/100 of a pixel in current major implementations.)
• relative:
  • higher:
    if possible, a higher precision than used by default, e.g. by storing more bits per value, thus probably increasing display quality and decreasing rendering speed
  • lower:
    a lower precision than used by default, e.g. by storing less bits per value, thus probably decreasing display quality and increasing rendering speed
• absolute value:
  • <length>:
    all computed lengths should be rounded to an integer multiple of the length specified,
    e.g. 1px
• absolute unity keyword:
  • um, mu, micro, micron or micrometer:
    same as 0.001mm, a micrometer
    (The SI prefix symbol µ, i.e. a Greek small mu or my, can be substituted by u if the former is not available in the character set.)
  • twip:
    same as 0.05pt, a twentieth of a point
  • emu:
    all computed lengths should be rounded to an integer multiple of the English-Metric Unit defined for OpenXML, where 36 emu = 1 micrometer
  • pixel:
    all computed lengths should be rounded to an integer multiple of device pixels, where each pixel consists of the same number of (colored) sub-pixels; smaller or equal to 1px
  • dot:
    all computed lengths should be rounded to an integer multiple of the smallest graphic element the output device can address, e.g. sub-pixels for screens; smaller or equal to pixel
  • integer or int:
    all specified lengths should be rounded to an integer multiple of the unit specified, before being converted to the canonical unit px for the computed value
  • <storage-unit>:
    absolute and relative lengths in computed, used and actual values should be treated as if they were limited to n bits or, if signed is specified, n−1 bits, with n = {
    1: bool/bit, 2: crumb, 4: nibble/quartet, 8: byte/octet,
    16: half, 21: char, 24: short,
    32: single/medium/float/int,
    40: extended, 48: long, 64: double, 128: quad}.

The rounding behavior is based on an extended set of keywords taken from css-rhythm.

• up:
  If the absolute value is not an integer multiple of the step value, it is increased to the next one,
  e.g. -1.5px to -1px and 1.5px to 2px for a step value of 1px.
• down:
  If the absolute value is not an integer multiple of the step value, it is decreased to the previous one,
  e.g. -1.5px to -2px and 1.5px to 1px for a step value of 1px.
• nearest:
  The value is either increased (as for up) or decreased (as for down) – whichever results in the smallest absolute change,
  e.g. -1.3px to -1px and 1.3px to 1px for a step value of 1px.
  If both options would result in the same amount of change, the size is increased,
  e.g. 1.5px to 2px for a step value of 1px.
  • odd:
    same as nearest except when both options would result in the same amount of change,
    the size is rounded to the odd multiple of the step value,
    e.g. -0.5px and -1.5px to -1px, 0.5px and 1.5px to 1px for a step value of 1px.
  • even:
    same as nearest except when both options would result in the same amount of change,
    the size is rounded to the even multiple of the step value,
    e.g. -1.5px and -2.5px to -2px, 1.5px and 2.5px to 2px for a step value of 1px.
• to-zero or zero or center or in or inwards:
  same as down for positive values, same as up for negative values,
  e.g. -1.5px to -1px, 1.5px to 1px for a step value of 1px.
  0 is left unchanged.
• from-zero or to-infinity or infinity or away or out or outwards:
  same as up for positive values, same as down for negative values,
  e.g. -1.5px to -2px, 1.5px to 2px for a step value of 1px.
  0 is left unchanged.
• ceil or ceiling:
  same as up, but if the step unit is auto, it is treated like 1px
• floor:
  same as down, but if the step unit is auto, it is treated like 1px
• normal:
  same as nearest, but with increase as for ceil and decrease as for floor

[tabatkins]

I'm very sorry, @Crissov, but as usual I'm going to have to ask for at least a hint of actual use-cases here - some sort of problem we could actually examine that might be helped by this suggestion. Without that, none of this design work does anything for us, as we have no way to tell what parts are necessary and what parts are overdesigned or not the right solution.

For example, without use-cases, I could imagine that snapping lengths to whole px might be useful, but I can't tell whether it actually is or not, or whether the central premise of doing this on a global level for an element vs on individual lengths via a math function is better. The entire rest of the proposal, lacking any use-cases to the contrary, look like complete over-engineering to my initial review. Many of the suggestions here would also require significant engineering work thru the entire style system, such as setting particular sub-pixel precisions or bit-widths that don't accord with the current (purposely unspecified) values used by actual implementations; without very strong use-cases, we can probably reject those offhand.

I'm going to close this issue. If you can provide use-cases for these suggestions, we can reopen and discuss at that time.