You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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
The text was updated successfully, but these errors were encountered:
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 pxmight 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.
<length>
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 likeround()
ormod()
#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).auto
(ormedium
):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.)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
<length>
:all computed lengths should be rounded to an integer multiple of the length specified,
e.g.
1px
um
,mu
,micro
,micron
ormicrometer
:same as
0.001mm
, a micrometer(The SI prefix symbol
µ
, i.e. a Greek small mu or my, can be substituted byu
if the former is not available in the character set.)twip
:same as
0.05pt
, a twentieth of a pointemu
: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
orint
: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
and1.5px
to2px
for a step value of1px
.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
and1.5px
to1px
for a step value of1px
.nearest
:The value is either increased (as for
up
) or decreased (as fordown
) – whichever results in the smallest absolute change,e.g.
-1.3px
to-1px
and1.3px
to1px
for a step value of1px
.If both options would result in the same amount of change, the size is increased,
e.g.
1.5px
to2px
for a step value of1px
.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
and1.5px
to1px
for a step value of1px
.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
and2.5px
to2px
for a step value of1px
.to-zero
orzero
orcenter
orin
orinwards
:same as
down
for positive values, same asup
for negative values,e.g.
-1.5px
to-1px
,1.5px
to1px
for a step value of1px
.0
is left unchanged.from-zero
orto-infinity
orinfinity
oraway
orout
oroutwards
:same as
up
for positive values, same asdown
for negative values,e.g.
-1.5px
to-2px
,1.5px
to2px
for a step value of1px
.0
is left unchanged.ceil
orceiling
:same as
up
, but if the step unit isauto
, it is treated like1px
floor
:same as
down
, but if the step unit isauto
, it is treated like1px
normal
:same as
nearest
, but with increase as forceil
and decrease as forfloor
The text was updated successfully, but these errors were encountered: