[css-values] Math Constant phi for Golden Ratio

[Crissov]

Since predefined constants inside calc(), starting with pi for π and e (natural logarithm base), are now a thing #4688, there should also be phi for φ or ϕ which denotes calc((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 become delta-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 integers p and q, 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 unit turn anyway.

Uppercase Φ is usually just 1-phi = -1/phi, sometimes also defined as phi-1 = 1/phi, but since CSS is case-insensitive here, it couldnʼt be added anyway.

theta θ or ϑ is sometimes defined as sqrt(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.

[tabatkins]

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.

[Crissov]

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 …

• … better than 17/12 and 24/17 for √2 or sqrt(2) (i.e. 100.17% and 99.83%) is f8/f7 = 21/13 ≈ 1,615385.
• … better than 22/7 for π or pi (i.e. 100.04%) is f10/f9 = 55/34 ≈ 1.617647.
• … correct to 3 decimal places (with truncation, no rounding) is f11/f10 = 89/55 = 1.6(18).
• … correct to 4 decimal places is f13/f12 = 233/144 = 1.6180(5).
• … correct to 5 decimal places is f15/f14 = 610/377 ≈ 1,618037.
• … correct to 6 decimal places is f18/f17 = 2584/1597 ≈ 1,6180338.

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.

[Loirooriol]

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.

[Crissov]

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.

[tabatkins]

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.

[Crissov]

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.

[jrus]

Someone can easily explicitly calculate ½(√5 +1) if they want to. Not worth complicating any spec to add this one.

[Crissov]

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.

[Crissov]

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.

[jrus]

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.

[Crissov]

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.

[tabatkins]

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.

[Crissov]

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) or
• round(round(round(10 * 1.6), 1) * 1.6, 1) * 1.6, 1) instead of
• round(10 * pow(phi, 3), 1).

[SelenIT]

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?

[Crissov]

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.

[tabatkins]

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.

[Crissov]

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:

• Approximations are always good enough.
• Everyone can calculate it to arbitrary precision themselves.

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.

[tabatkins]

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?

[LeaVerou]

I’m also strongly against adding φ/phi for the following reasons:

1. It has been thoroughly debunked that the golden ratio actually makes visual design more aesthetic. A quick google search reveals numerous articles on the subject. Asymmetry is visually aesthetic, and phi is just one way to reach a good ratio, but actually human experiments show that humans gravitate towards ratios slightly different than phi when asked to evaluate designs.
2. As has been pointed out even by OP himself, it can easily calculated with the current math functions we have. You can set a --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.
3. We add things based on use cases. In this case, if phi was a good candidate for addition, we would be seeing lots of stylesheets using variables for it, either native CSS variables (--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. 🤷🏽‍♀️

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: [css-values] Math Constant phi for Golden Ratio
<tantek> whether or not WebKit implements it
<dael> github: https://github.com//issues/4702#issuecomment-660684501
<dael> TabAtkins: I expect this to be short. Christoph has been asking for phi to list of constants
<dael> TabAtkins: I'm against. phi is largely numerology. In cases where it's used, 1.6 is very close to phi. There's virtually no instance where you need precise. Exact spirals maybe but I haven't seen that in CSS
<hober> q+
<dael> TabAtkins: I suggest resolve not to add phi. Unofficially I doubt any other constant will rise to importance of add to CSS
<astearns> ack hober
<dael> hober: Prefice by saying I'm not dying on this hill. Fine to not add. There is a reasonable argument that CSS is used to create compelling visual designs. Having htis built in would allow people to do that.
<dael> hober: Agree with TabAtkins phi isn't interesting mathematically. But CSS isn't matLab. We're trying to provide practical tools for designers. THere's a long tradition of golden ratio in design
<gsnedders_web> q?
<gsnedders_web> q+
<dael> TabAtkins: INteresting that's the exact reason I think we shouldn't. Math reason is good, but design with golden ratio in practice you can use 1.6. Anything that specifically wants an exact value where I've seen examples they're happy to round to whole pixels so they're looking for something around there. THey're not looking for mathematical properties, they don't factor in
<dael> TabAtkins: It's unlike pi where inprecise shows up when you're doing circular.
<leaverou> q+
<astearns> ack gsnedders_web
<jensimmons> q+
<dael> gsnedders_web: I agree with TabAtkins that precise doesn't matter. BUt we have enough people that want to use phi where sake of clarifying what people want to do the constant is useful
<astearns> ack leaverou
<dael> leaverou: There have been studies on this and people gravitate to different ratios than phi. It's been experimentally proven. If I remember people gravitate to 1.4 or 1.7.
<dael> leaverou: Also unlike pi and e phi can be computed relatively easily. pi for example we can't do that easily. phi anyone can define their own variable and compute it to use in stylesheet
<dael> leaverou: Also, I've never seen a phi variable in a stylesheet. If needed wouldn't we see in wild? I haven't seen in Sass or CS variables
<astearns> ack jensimmons
<dael> TabAtkins: Right, where I have seen pi
<dael> jensimmons: I agree with TabAtkins that it's okay if people use 1.6 and don't need precise. I agree with leaverou that this fetishization of golden ratio is rediculous. But I think it's interesting to add. It is humans writing this. It's not that it's not possible to calculate. BUt it's giving people a tool and saying here it is. If it's hard to impl whatever. BUt it's simple. It's a human question, is there a nudge to say to humans you should think abo[CUT]
<dael> jensimmons: I have not seen people put golden ratio specifically. But I have seen complicated sass frameworks deeply based on ratios. This is age of floats. But there is interest in this kind of space
<dael> TabAtkins: If I recall Bolton work was exponential work. Asending series, not just golden
<dael> jensimmons: Both. Golden and a bunch of others
<astearns> s/Bolton/Boulton/
<dael> TabAtkins: You brought up it's not difficult to impl. You're completely right. None of the constants are hard to add. Impl effort is more or less nill. Because of that I want to be more principled to make sure there is a need i nthe design community.
<dael> TabAtkins: I don't think we'll get much value from many constants so we want to have a bar
<dael> plinss: Maybe similar to how we handle additional names colors
<dael> plinss: It's morally eq to adding a named color. We're giving names to colors.
<plinss> s/names to colors/names to numbers/
<dael> TabAtkins: Yeah, they're not hard to put together. Yeah. We have extra hard line against named color because that's horrible. Named constants isn't as bad, but I agree it's pretty similar
<dael> plinss: There are useful named colors, black white red. But we don't want to add every named color
<dael> jensimmons: Agree we shouldn't go nuts with this. but I think reason behind this is golden ratio is taught in art schools. I could see a lot of discssion on this once it ships. I don't feel that way about any other mathematical number
<gregwhitworth> q+
<dael> astearns: I agree us doing it could push more use of phi. I'm not sure that's our place. I think we should be responding to more use. More interest in having it if people noticed it showing up in a lot of sass variables or custom properties.
<dael> astearns: Wary of let's put it out there and let people use it.
<astearns> ack gregwhitworth
<dael> gregwhitworth: Doing a quick scan ir doesn't look like it's in JS, phi. I think this is a great candidate for what leaverou brought up of finding stuff up based on data. We should find out if there's common math eq in calcs.
<dael> gregwhitworth: If it's not in JS I question strong case of adding it
<dael> TabAtkins: I don't take is it in JS too strongly. We do more than JS does with math. It's used in design less computing so not surprising. THe database approach is right. leaverou casual investigation hasn't shown it, but we could look in http archive. If you see 1.618 show up a bunch it indicates people are using golden ratio
<dael> TabAtkins: A lot of cases it would shwo it it will have fairly simple patterns
<dael> TabAtkins: Prop: reject for now and leaverou would you take this on for http archive data?
<dael> leaverou: Sure. I was planning on popular variables already
<dael> TabAtkins: Prop: Reject for now and if data shows up from http archive that it is fairly common we re-open and put it in.
<dael> astearns: Objections?
<dael> RESOLVED: Reject for now and if data shows up from http archive that it is fairly common we re-open and put it in

[Crissov]

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.

[Myndex]

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??

Here's 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.

SO YAY for phi φ — the magical golden number that's also easy to remember...

:)

Andy
Inventor of APCA and SAPC
And guy obsessed with color... and also math apparently...

[Myndex]

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: $$\phi = 5^{0.5} \times 0.5 + 0.5 $$

[LeaVerou]

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);

[tabatkins]

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.

[Loirooriol]

Firstly, var(--phi) is more cumbersome to read and write than plain phi, especially inside other parentheses.

Addressed by https://drafts.csswg.org/css-variables-2/#variable-units, now it can be 1--phi.

[Crissov]

@property --phi {
  syntax: "<number>";
  initial: calc(sqrt(5)+1)/2);
  inherits: true;
}

foo {bar: 2--phi;}

if #7379 gets specified.

[LeaVerou]

Or even

@property --φ {
  syntax: "<number>";
  initial: calc(sqrt(5)+1)/2);
  inherits: true;
}

foo {bar: 2--φ;}

😁