Closed Crissov closed 3 years ago
I'm weakly against adding phi.
Most of the time, phi is used for its "golden ratio" design sensibilities. The exact value used isn't important here, just the fact that it's ~1.6, and rectangles with approximately those ratios tend to look good.
The exact value of phi is valuable in number theory, and some interesting geometric effects (spirals!), but I don't think it has a use-case that isn't solved equally well by just using 1.6.
(This critique doesn't apply to pi, because if you don't have a reasonably accurate value of pi, you'll sometimes get obvious near-misses when dealing with anything involving circles. I'm unsure if e falls to the critique, but it's already implicitly used in exp()
and log()
, so providing it explicitly seems reasonable.)
As I said in the Twitter thread you linked to, if someone can provide a use-case that isn't solved equally well by using 1.6, I could change my position. But right now I don't think it pulls its weight.
Golden rectangles would probably be a major use case. Since many graphic designers demand pixel-perfect layouts across devices and browsers, Iʼd say a reasonable approximation of φ would yield accurate results for all integer base edges up to, say, 2000px
, because larger values are very rarely useful. This would stay accurate, if one could correct initial errors by always rounding in the same way. Alas, with 8:5, a rectangle 100px wide would be 160px tall instead of 161px and rounding could not help at all.
The first approximation of φ by the ratio of two adjacent Fibonacci numbers that is …
sqrt(2)
(i.e. 100.17% and 99.83%) is f~8~/f~7~ = 21/13 ≈ 1,615385. pi
(i.e. 100.04%) is f~10~/f~9~ = 55/34 ≈ 1.617647. By the way, a static function to return the n-th Fibonacci number could have been a reasonable substitute to phi
as a constant, e. g.: fibonacci(3)
= 3
.The actual sequence could also have been up to a parameter, e. g.: seq(prime, 3)
= seq(fibonacci, 4)
= 5
with seq(prime, 0)
= seq(fibonacci, 0)
= seq(fibonacci, 1)
= 1
.
Note CSS is 1-based, so the 1st value in a sequence should be indexed with 1, not 0. And the 1st prime would be 2, not 1. And I don't see the need for the nth prime or fibonacci. Adding the fibonacci sequence as a replacement of phi seems overkill.
In the example, I only used index 0 for redundant or ambiguous cases: 1 appears twice in the Fibonacci sequence and may or may not be considered prime. Itʼs like accepting both 0 and 7 for Sunday in DOWs. Anyway, within the current technical environment, Iʼd prefer a simple single constant phi
.
Pixel perfection across devices doesn't depend on having phi; any number will do. Pixel perfection against a hypothetical golden-ratio rectangle does, but golden rectangles aren't real. People like rectangles that are a little wider than they are tall, that's it; using 1.6 as the ratio suffices just fine.
Even if phi
resolved to 1.6, Iʼd prefer the named constant just for code readability, especially if there was a way to specify box dimensions with fixed aspect ratios #4428 – and no, a custom property --phi
is not the same.
Someone can easily explicitly calculate ½(√5 +1) if they want to. Not worth complicating any spec to add this one.
Sure, everyone could calculate it themselves, as they could for pi
and e
as well. The point of adding it as a predefined constant is that many people would do it the same way (and some in a slightly wrong way). It would simplify everyoneʼs life if a reasonably exact value was available as phi
.
This is not a new page layout module, it is a single numeric constant with a well established name and a clearly defined value. It would not complicate the specification at all. Implementation and testing of φ can happen together with e and π, i. e. adding minutes to hours.
I may have proposed controversial, complicated, costly or crazy stuff in the past, but this is none of that.
using 1.6 as the ratio suffices just fine.
For you, it might. Without high-precision floating numbers, it might. Without named constants, it might. Without ratio or division expressions, it might. Without power or radix functions, it might.
With the current state of CSS however, it is not a reason against adding phi
.
There is no particular justification to add φ the solution to x² = x + 1 (or if you like the ratio of diagonal to side of a pentagon) that wouldn’t equally apply to the solution of a dozen similar algebraic equations.
To start you certainly want √2 the solution to x² = 2, before φ; the former is much more commonly used in particular since it is the basis of ISO paper sizes. Beyond that ...
You could just as well add the ratios between diagonals of a heptagon and other polygons http://archive.bridgesmathart.org/2000/bridges2000-35.pdf
Or you could add the the so-called “metallic means” https://en.wikipedia.org/wiki/Metallic_mean
Or you could add these generalized higher-dimensional analogs of φ http://extremelearning.com.au/unreasonable-effectiveness-of-quasirandom-sequences/
It’s all unnecessary. If designers care in practice about using a high-precision approximation to φ it is trivial for them to add for themselves. But for practical purposes in design a 3-digit approximation 1.62 is indistinguishable. Some artists’ insistence on the aesthetic value of φ per se is largely snake oil, and 1.6 or 1.55 or 1.65 ... would be perfectly fine.
You are right that CSS also doesn’t really need named constants for π or e.
One difference to many other irrational constants is that there is an established symbol and name. I discussed (and dismissed) other candidates in my initial post. If phi
isnʼt worth adding, nothing beyond pi
and e
is.
If the Golden Number could be expressed exactly as the square root of a rational number, like sqrt(2)
which ECMA-262 has a predefined constant for, or as a single rational argument to an existing function, like exp(1)
for e
, I would certainly not be pushing it as much.
PS: I really have said enough on this issue. I just hope the WG can spare three minutes in one of their next conference calls so we can get a resolution on whether the newly introduced set of predefined math constants is considered complete with its two current entries.
For you, it might.
No, my argument is that it suffices for everyone. I don't believe there are common use-cases where an exact value of phi is meaningfully distinguishable from 1.6. (Unlike pi, where a small difference can result in something not being a full circle, etc.)
As with many of your proposed suggestions, use-cases would be appreciated; some things I can come up with reasonable justifications for on my own, but for everything else I'm going to reject unless someone brings up a good use-case for it.
(If people want to generate maximally-dense spirals, for instance, an exact value of phi is worthwhile, and very noticeably different from 1.6. Evidence that this is useful in CSS would be appreciated.)
If phi isnʼt worth adding, nothing beyond pi and e is.
FWIW, I suspect this is the case.
The point is that with round()
inside CSS, authors are no longer forced to use rounded components in calculations to get nice numbers in the end, but can just round the result: round(f(φ, x)) instead of f(round(φ), x).
Authors already can use better approximations than 1.6 (which tends to lead to round but inaccurate results) or 1.618 (which leads to more accurate but odder results), e. g. calc(610/377)
, or they can limit themselves to integer values from the Fibonacci sequence, and Iʼm sure that some are doing either already, and likewise some will soon put accurate representations of φ into their code, i. e. calc((1+sqrt(5))/2)
or calc(0.5+sqrt(1.25))
. However, if a design system, like GRT, relies on an equality like φ – 1 = 1 / φ, things will misalign due to, for instance, 0.6 ≠ 0.625 (for Fibonacci numbers 5 and 8). Also, early rounding will yield inaccurate results if authors are not very careful with their math, e. g.: in a series of sizes where adjacent steps are a factor of φ apart, starting with a base of 10 and results being rounded to integers, a factor of 8/5 leads to 16, 26 and 41, whereas 13/8 has 43 in the last step, but 42 would be accurate and could be achieved by alternating the approximate factors or by multiplying by the rounded intermediate steps, i.e.
round(10 * 8/5 * 13/8 * 8/5, 1)
, round(10 * 13/8 * 8/5 * 13/8, 1)
orround(round(round(10 * 1.6), 1) * 1.6, 1) * 1.6, 1)
instead of round(10 * pow(phi, 3), 1)
. and no, a custom property
--phi
is not the same
@Crissov could you please elaborate a bit? At a first glance, storing any useful (for a particular use case) constant in a custom prop seems the most natural solution. Do you mean performance concerns or something else?
Firstly, var(--phi)
is more cumbersome to read and write than plain phi
, especially inside other parentheses. If they know what they are doing, authors could even rewrite many calculations to incorporate the rational and the irrational summand of φ or its divisor elsewhere, thereby obfuscating the use of the Golden Ratio, which degrades code readability and thus maintenance.
Secondly, due to its casdading nature, a custom property can be overwritten with a different value, but φ is a constant with a globally unique, unchallenged definition (even though its numeric precision is up to implementation constraints) and authors should be able to rely on that.
However, if a design system, like GRT, relies on an equality like φ – 1 = 1 / φ, things will misalign due to, for instance, 0.6 ≠ 0.625 (for Fibonacci numbers 5 and 8).
As far as I can tell, GRT doesn't actually rely on this; it happily rounds sizes for each step to the nearest whole px.
Are these just so the produced sizes don't scare people away from using them? Probably. But it's also an indication that, whatever benefit GRT claims to bring, using a vague approximation of phi is Good Enough™.
And in the worse case, if people actually do want to use a more precise value, GRT boils all the math down to just eighteen constants (three sets of six values), which authors would use by storing in custom properties. (They're certainly not going to inline a bunch of high-precision decimals all across their stylesheet.) It is completely reasonable to either inline a slightly more precise value here (1.618), or store a high-precision value for phi in a variable and use it in these eighteen boilerplate calculations; authors are not expected to be using phi on the fly in this system such that readability of the constant is important.
if someone can provide a use-case that isn't solved equally well by using 1.6, I could change my position.
I thought I did just that by pointing out the problem with unequal reciprocal values, e. g. a tall vs. a wide “Golden” rectangle. Authors can use approximations for sure, but they cannot rely on a single approximation to apply in all cases sufficiently.
It is completely reasonable to either inline a slightly more precise value here (1.618), or store a high-precision value for phi in a variable and use it in (…) calculations
How is this work to be done – possibly introducing mistakes – by every single author more reasonable than making a predefined constant available to all authors?
Your arguments against a predefined exact constant apparently are:
I think I have demonstrated that the first one is not true. The second one became true with recent additions to CSS, but it is counter to convenience, redundancy and error avoidance.
Please, just get a WG resolution on this.
How is this work to be done – possibly introducing mistakes – by every single author more reasonable than making a predefined constant available to all authors?
It's not, because very few authors try to use the golden ratio in their work. Because, of course, the "golden ratio is more harmonious/beautiful" is numerology nonsense, and it really is just "rectangles often look good when they have a roughly 3:2 ratio", and 1.6:1 is approximately that ratio.
I'm saying that, for the subset of authors that do want to use the golden ratio in their work and want a highly accurate value, just using 1.618
is sufficient (it has an error of approximately 0.2% from the true value). That subset is very small to begin with, and I'd be willing to bet a good amount that nearly all of those people don't need a highly accurate value anyway, as the GRT website, a design framework explicitly basically around the golden ratio, shows, since they round their values to the nearest pixel and in many cases are less accurate than 1.6.
Please, just get a WG resolution on this.
Fine?
I’m also strongly against adding φ/phi for the following reasons:
--phi
variable with that on :root
and use it wherever. We cannot add every conceivable math constant to CSS because var(--foo)
adds 7 extra characters.--phi
) or preprocessor variables ($phi
). I don't recall ever seeing this, not even once.I personally don't think this warrants telcon time, but based on this thread, it looks like there's WG consensus against adding it, so I suspect it's going to be a short discussion anyway, so eh. 🤷🏽♀️
The CSS Working Group just discussed [css-values] Math Constant phi for Golden Ratio
, and agreed to the following:
RESOLVED: Reject for now and if data shows up from http archive that it is fairly common we re-open and put it in
For what it’s worth, I’m actually satisfied with this resolution. The line has to be drawn somewhere. I believe φ – not least due to its long-standing prevalence in graphic arts teaching and design concepts – should be just atop of it but probably nothing else. If actual usage data and the collect expertise of the working group suggest it should be just below of the bar (and everything else even further down) then I accept that.
Hi @Crissov
Just stumbled onto this thread — interestingly, I am using phi as the output contrast scale factor in APCA and SAPC, to put contrast at easy to remember values ~(60, 80, 100, 120)~ (15,30,45,60,75,90). ~It's there with~ a simple JS:const scale = 1.618;
Trivial, and not like pi where 20 places can be important, such a when calculating LCh.
Edit: (APCA no longer uses Phi since 2021, now using square root of two, however DeltaPhiStar definitely uses Phi, it's even in the name...)
JS Math has pi as a property, but not phi. I happen to like phi as a number myself, but I don't see needing it as a standard value for JS much less CSS. Sure, you'll see pi often, but not phi. Why??
pi is difficult to calculate. In fact it's a pain in the ass. And having pi at your fingertips to the maximum precision of your environment is very useful.
phi is also useful, but it is also trivially easy to calculate:
(1 + sqrt(5)) / 2 = 1.6180339887498948482045868343656381177203091798
And secondly, phi is less likely to cause a rounding error. Let's compare to pi:
pi(48) vs phi
3.1415926535897932384626433832795028841971693993
1.6180339887498948482045868343656381177203091798
Notice anything? Rounding phi to 3, 4, or 5 places really changes nothing. But that is not true for pi at all.
It's easy to remember 1.618, harder to remember 3.14159, and much harder to remember is 3.14159265358979 but this last one is what you need for a lot of common math if you want to avoid noisy rounding errors.
:)
Andy Inventor of APCA and SAPC And guy obsessed with color... and also math apparently...
For no reason whatsoever, adding the formula for phi broken down in a way that will be hard to forget, ever.
const phi = Math.pow(5, 0.5) * 0.5 + 0.5;
For no reason whatsoever, adding the formula for phi broken down in a way that will be hard to forget, ever.
const phi = Math.pow(5, 0.5) * 0.5 + 0.5;
Or:
Ha, that's nice. I had to do a double take as it looked very different from the one I knew:
$$\frac{\sqrt{5} + 1}{2}$$
Which can be expressed in CSS as:
--phi: calc((sqrt(5) + 1) / 2);
Note: now that JS has the pow operator, this can be written as
const phi = 5 ** .5 * .5 + .5;
which looks much more cursed to me.
Firstly,
var(--phi)
is more cumbersome to read and write than plainphi
, especially inside other parentheses.
Addressed by https://drafts.csswg.org/css-variables-2/#variable-units, now it can be 1--phi
.
@property --phi {
syntax: "<number>";
initial: calc(sqrt(5)+1)/2);
inherits: true;
}
foo {bar: 2--phi;}
if #7379 gets specified.
Or even
@property --φ {
syntax: "<number>";
initial: calc(sqrt(5)+1)/2);
inherits: true;
}
foo {bar: 2--φ;}
😁
Since predefined constants inside
calc()
, starting withpi
for π ande
(natural logarithm base), are now a thing #4688, there should also bephi
for φ or ϕ which denotescalc((sqrt(5) + 1)/2)
= ½+√1¼ ≈ 1.618034, i. e. the Golden Number (also known as Golden Ratio or Golden Mean) which is used a lot in graphic design, although often approximated by more practical, rational values between 1.6 (8:5) and 1.625 (13:8), e. g. in aspect ratios.Itʼs such an obviously sensible addition that others have informally suggested it as well, of course, e. g. on Twitter.
It is not available in ECMA-262 yet, i.e. as a predefined constant in the Javascript
Math
object.Other constants that are not being proposed
I can think of no other irrational factor frequently used in design that is not easily expressed as
sqrt()
with a simple argument like 1.5, 2, 3 and 5 or their inverse values.The Silver Ratio is
1+sqrt(2)
, which is a little bit more complex, but is neither used very often nor does it have a commonly known symbol – δs would becomedelta-s
which is just one character shorter.The definition of the Platin Number (ρ or ϱ,
rho
, ca. 1.324717) is a lot more complex, but is neither well known nor often used.The other metallic means,
(p+sqrt(4*q+p*p))/2
with small integersp
andq
, are either simple numbers or not important at all. (p = q = 2 for platinum)tau
τ = 2π is too simple to deserve a designated constant of its own and itʼs already available as the angular unitturn
anyway.Uppercase Φ is usually just
1-phi
=-1/phi
, sometimes also defined asphi-1
=1/phi
, but since CSS is case-insensitive here, it couldnʼt be added anyway.theta
θ or ϑ is sometimes defined assqrt(pi)*phi
, which is both now simple to write if one needs it and too hardly known otherwise.There are, however, some standard angles, including the Golden Angle of c.
137.5deg
or c.2.4rad
, that might make sense to add, but they would deserve an issue of their own.