[css-values] Radians considered useless without π

[Crissov]

rad has been a valid angular unit since they have existed in CSS, but it never has been useful or widely used. A major reason for this, despite popular familiarity with degrees, is most probably that values in radians tend to be long floats with a single digit before the decimal marker and hence make authors feel unable to express definite values that won’t be rounded in an unexpected way. (Many intuitively expect decimal rounding, although it’s usually hexadecimal/binary.) This is due to a lack of the constant π in CSS.

Although a turn unit has already been defined, which equals 2π, I’d like to suggest another unit for radians muliplied by π: either pirad or just pi. It’s okay to defer it to the next level, although I believe it should already have been included in Level 2.

Length units may benefit from other irrational multipliers, e.g. √2, but there’s no obvious identifier comprised of only ASCII letters for them (unless you wanted 1sqrttwomm). We do have precedents for unit prefixes with dp…, ms and kHz (and if there was m, also mm and cm).

[tabatkins]

2pirad is just 1turn, right? I'm not sure that's worth including.

[Crissov]

Yes, like I said 1turn equals 2π and hence 1pirad = 0.5turn = 180deg = 200grad. Although halving or doubling may seem like really simple steps, they’re really about as complex as multiplication or division by 180 or 200 conceptually.

The idea and benefit of pirad is to be mixed with rad transparently, although it’s rare having to deal with an even radian value without π or 0 being a factor. It’s also simpler to relate to sources external to stylesheets where you may use the π symbol.

[prlbr]

2pirad is just 1turn, right? I'm not sure that's worth including.

Seems like τ-rebels can celebrate a victory then. :) Given that schools all over the world still teach that a unit circle’s circumference is 2π, including pirad would actually seem sensible though, if the idea in CSS was to start from where the people are. I bet something times π rad is used by magnitudes more often than, say, grad.

Personally, I’m fine with turn though. τ for the win.

[Crissov]

Yeah, if the proposal was to add an alias taurad or tau for turn I’d probably agree that it was overkill.

[tabatkins]

No, multiplication by 2 is substantially different than by 180 or 200. The size of numbers matters when doing mental math.

turn is already something we probably wouldn't add today; it's only in because somebody slid it in years ago and we all sorta implemented it. Just use tau radians (or pi diams) like math should have been. ^_^

[Crissov]

Do you have data for usage of rad (and turn), including frequent values?

[Crissov]

• In an ideal world,
  • all math would be using τ and hence CSS would be using tau (instead of turn and rad).
• In the real world,
  • professional math is using π together with (often implied) ‘rad’, while CSS is using explicit rad without π and, rarely, turn instead of tau, τ or 2π,
  • colloquial math is using ° and hence CSS is using deg (in addition to turn and rad).
• In @tabatkins’ conclusion, actual people should assume ideal math and apply it to actual CSS,
  i.e. τ = 1turn = 2π ≈ 6.283rad.
• In my conclusion, actual people should assume actual math and be able to apply it to actual CSS,
  i.e. π = 1pi (or 1pirad) = ½τ = 0.5turn ≈ 3.141rad, just like 1° = 1deg.

[grorg]

Sorry to be the only negative voice here, but I don't really see the point of adding this. It's not a new feature, it only helps in some mental models. It's just another thing to implement without much benefit.

[Crissov]

The new “feature” is that people would have fewer irrational numbers in their code. This could help to avoid some rounding errors and it would definitely improve user experience for dealing with angles in CSS.

[tabatkins]

We already have such a unit, the tau-radian, spelled "turn". (Short for TaURadiaN, obviously; @fantasai plz don't get mad at me for stealing your joke ^_^)

Adding pi-radians just to eliminate a factor of two is the hard sell here. (Particularly when the tauradian has additional benefits going for it, namely that it's easy to explain as "one turn around the circle".)

[Crissov]

I feel like we are repeating ourselves, so just this one more time.

The proposed benefit is getting rid of the irrational factor of π in rad, not the integer factor 2 in turn.

I completely agree that tau-based math would be simpler than pi, but that is not what real authors are used to nor what calculators or trigonometric lookup tables are designed to. Nobody will (want to) change their mental model of angles for CSS. (turn is already perfect for rotations, however.)

[tabatkins]

There's no reason to focus on rad here. We have turn, it eliminates the irrational factor, it just uses tau (aka a factor of 2) instead of pi. Adding pirad would just be adding a half-turn, which isn't worthwhile since we already have turn.

The usefulness of rad is in allowing JS to output values directly into CSS without having to go thru extra conversions; whether they use degrees or radians, they're covered, they just have to append the right unit to the number they've obtained from their trig operations.

If you're a human, you probably shouldn't be writing rad values at all, for the reasons you already mentioned. You should be using deg or turn, as both are human-friendly in different ways. Adding a pi-rad or half-turn for additional human friendliness doesn't give enough benefit for the cost here.

[css-meeting-bot]

The Working Group just discussed Radians considered useless without π, and agreed to the following resolutions:

• RESOLVED: Close iss #309 no change

The full IRC log of that discussion

<dael> topic: Radians considered useless without π
<dael> github: https://github.com/w3c/csswg-drafts/issues/309
<dael> astearns: Looks like we want approval to close no change.
<dael> fantasai: Basically the argument is you need pi to use radians, but we have turns to you can divide by 2 and use turns.
<fantasai> turns = TaURadiaNS
<bkardell_> :)
<dael> Chris: +1 for closing. I think it's very clear.
<dael> Chris: The reason we have radians is people can spit it straight out without converting to degrees first.
<dael> astearns: And that there is no impl that wants to add makes me think we should close.
<florian> +1
<dael> astearns: Obj to closing no change?
<dael> RESOLVED: Close iss #309 no change

[Crissov]

Okay, fine, so lazy JavaScript authors make a use case, but people with normal math education do not. Got it, author experience does not matter.

[tabatkins]

That's a completely inaccurate and dishonest read of every comment we've made on this thread.

[Crissov]

The use case was being able to write angles in CSS almost verbatim like everyone does in mathematics. The WG’s resolution is to make authors accept an unfamiliar factor of 2 every time, because that saves each implementor one man-hour or so once.

I just wish the CSS WG would adopt HTML’s Priority of Constituencies, because with proposals like this I want the language to become more author-friendly. All I’m ever getting as an answer is a polite variant of “fuck you”.

[tabatkins]

As I've explained here and elsewhere, it's not "one man-hour or so" of time. It's that, plus testing, plus more things to support in other spots (like Houdini), plus more things for authors to learn (and spend time encountering for the first time and having trouble googling because it's just a few letters), plus the speccing and testing work for us spec writers.

And it's not this one thing. If the bar is "this might be convenient", then you can multiply this amount of time by a relatively large number, as we add lots more "might be convenient" things with the same level of justification. Your own proposals show this immediately - with the same justification given here, we'd have to accept 20+ more units and page-size keywords. Each one individually isn't a large amount of work (but more than "an hour or so"), but combined they become quite significant.

Yes, the web ecosystem is path-dependent; things that already exist don't need to self-justify themselves nearly as hard as proposed new things do. This is because new things are expensive, and the frontier of "new things we might want to add" is much larger than the existing territory of "things we've already added". Browsers are already very large; we need to jealously guard it against gratuitous growth, and require things to self-justify more and more as time goes on, or else we'll drown in the weight. Thus, for example, the strong push for better primitives that let authors develop their own "conveniences", so we can write one more complicated feature instead of a thousand simpler ones.

In this case, the existing units cover pretty much everything you might want to do with reasonably good efficiency. If you're writing JS, you just have plain numbers already (the pi is already baked in), so you can just use the existing rad unit. If you're writing by hand, you can use degrees or turns, and if you for some reason really like doing angle math by hand in radians, we have tau-radians for you, a mere factor of two off of the requested pi-radians. (Factors of two are well-established as being the easiest possible non-trivial factor to deal with in mental math.)

We do follow the PoC, but that doesn't mean slavishly going "oh, this helps authors, that means we have to do it". It's still about balancing interests, just with particular weightings given such that users are valued over authors, etc. In this case, the value to authors seems to be extremely minimal; we're not seeing much demand for pi-radians in the first place, and even if there is, tau-radians (turns) are almost as good and already exist, so the "user" side of the equation is almost nil. Compare that with the cost of implementing/testing/etc, which is also small but not nil, and put another thumb on the scale to accommodate the larger ecosystem concerns (that I outlined earlier in this message, which go beyond just the cost of any one individual feature), and our conclusion - to not add this unit - becomes more obvious.

We deeply appreciate your love of the language and the time you've spent trying to improve it. As someone who was also once just a web author trying to interact with a standards body, I also totally understand that this is the sort of thing that looks like easy, low-hanging fruit - it's so easy to define! It's quite a surprise to learn of the significant costs that underlie every feature, no matter how trivial, and to deal with the balancing act that the WGs have to make between convenience and maintaining a reasonably small feature set.

I hope you'll continue to donate your passion to helping CSS grow, and that we can find something together that will make it thru the gauntlet. ^_^

[Crissov]

I have already scaled back heavily on my W3C activities, for a large part due to frustrating experiences like this. I basically only do small proposals such as this one any more. I haven’t thoroughly reviewed a spec in years because the discouraging feedback I often got (if any). I have seen issues being revisited more than a decade after I (or others who have moved on long ago) suggested to fix them, and been brushed off. The web is full of rants by authors about other annoyances, big and small, that had also been identified early on, and ignored. Many of those cannot be fixed any more; this one can.

I really don’t buy your argument and I tried to explain why. The few minutes or hours this would take once to implement in dozens of places by a handful of people do accumulate. I get that. But the seconds saved in writing and reading code by thousands of people in millions of places also accumulate. I’m not claiming that I could estimate the benefits and costs any more accurate than that, but, while CSSWG members probably have better insight in the latter, I strongly feel this imparts their judgment of the former, which is hardly better informed than mine.

When in doubt, the Priority of Constituencies would demand that the author-friendly feature be added, but you are convincing yourselves that you were not in doubt in the first place so you can still feel like following that noble principle even when you are really not.

I understand that a feature that might be convenient needs additional justification, but I do not understand why a feature that would be convenient also does. Nobody challenged the fact that pi or pirad would be a useful unit to have in CSS. The only counter argument is cost of implementation.

[svgeesus]

P.S. I want to say the same thing to the 'Pi Radians' person in this thread, but I'm a too scared to suggest a solution like this over there 😵: https://github.com/w3c/csswg-drafts/issues/1814#issuecomment-329350296

[Loirooriol]

There is a constants proposal in #1693, so maybe calc(constant(pi) * 1rad)? Or adding pi to <calc-value>, allowing calc(pi * 1rad). I think these would make more sense than a pirad unit.

[tabatkins]

If/when we get trig functions, adding pi is definitely going to be necessary. I wouldn't invest much effort in it until then. ^_^

[Crissov]

Why would π be any more necessary if CSS had sin(), cos(), tan() etc. than it is now? Couldn't authors just use turn instead?

🤦

[Loirooriol]

@Crissov These functions don't work on angles, their parameter is just a real (or complex) number. Using a turn, rad or pirad unit would be an abuse of notation which might be tolerated, but the right way would be numbers without units. That's why pi (or tau) is definitely going to be necessary.

[Crissov]

What now? Trigonometric functions always operate on angles! You are just used to implicit rad because that is all most programming languages support (and the unit is hardly used explicitly in math either because its dimension is unity indeed).

In hsl(), on the other hand, deg (or ° elsewhere) is often omitted. Nothing good ever comes from omitting unit symbols.

[tabatkins]

Whether trig functions take numbers or angles is a matter of convention. While they arise from circles and angles, their standard definitions (as Taylor series) definitely treat their argument as a plain number, and trig is used in many contexts where angles aren't what's being talked about. (For example, one way to calculate e^(i*N), a plain number, is cos(N) + i*sin(N).) I'd probably define them in CSS to take either, actually. (Outside of CSS, yes, "angles" are actually unitless numbers, dimensional-analysis-wise.)

Anyway, the reason pi is more important there is that so many trig formulas are expressed in terms of it. Requiring the author to convert to tau (using turn) makes it more error-prone and harder to read. Pi is also written explicitly in these formulas, so switching over to a unit-ed value means your formula drifts even further from the original - instead of writing, say, sin(5 * pi / 2), you have to convert to sin(5turn / 4) or something like that. I think that kicks it over the point where "just use turn" makes sense. (The latter objection also means that pirad as a unit isn't great, tho it's less bad than turn in this instance.)

[Crissov]

For what it’s worth, I agree that this means that pi would be a better choice than pirad. It feels like numeric constants, if deemed necessary, are best realized as “units” in CSS and not within constant() from #1693 as mentioned by @Loirooriol.

[tabatkins]

I wouldn't want pi as a unit - while it means you get the clever 2pi, etc wording, it makes it less obvious how you get a plain pi on its own (1pi). I'd just make it a keyword usable within math expressions.

(While keywords-in-calc() in general is a difficult topic we haven't solved yet, adding specific keywords is totally fine.)

[Crissov]

As a unit, it could be used wherever <angle> is valid, without further changes. That means, 1pi is still better than calc(pi).

[tabatkins]

That's weird, then, because pi isn't an angle, it's a number. CSS distinguishes between <angle> and <number>, and it's important for calc() to be able to do so -- is calc(1pi * 1rad) an <angle>? Or an <angle>²? The latter is invalid to actually use anywhere.

[AmeliaBR]

Registering a vote for the constant(pi) notation, or env(pi) based on the resolution to https://github.com/w3c/csswg-drafts/issues/1693#issuecomment-330909067.

Pi isn't an angle unit, it's a numerical constant. The angle unit is rad. Yes, serious mathematics doesn't use a unit for radians at all (in dimensional analysis, a radian is an angle measured as the ratio between the length of the arc and the length of the radius, so the units cancel out and you're left with a pure number). But CSS has a rad unit, and distinguishes between angles and numbers everywhere. So let's stick with that.

I don't mind the idea of a simple constant pi keyword within calc(). But since (I think) there is now agreement on having a function for accessing system constants, might as well use it.

PS, I'd love to have other math constants, like e or especially √2 available in CSS for Shapes and Transforms and so on. All the JavaScript Math constants.

[Crissov]

@AmeliaBR I mentioned √2 in my initial message, not too sure about the logarithm bases. Designers would more likely need Golden Ratio phi = ½+√1¼ or maybe also Silver Ratio deltaS = 1+√2. (The Plastic Number rho probably does not have convincing use cases in design and layout.) If one wants to see it that way, rad is a numerical constant with a value of 1, while turn is 2π, deg is π/180, gon is π/200 and pi would be π.

@tabatkins Multiplication inside calc() currently always requires <number> on at least one side. <angle> * <angle> is one of several combinations that could make sense to allow (for instance, 1in * 1dpi could result in 1). As it stands, however, calc(1pi * 1rad) would be as invalid as unnecessary.

[Crissov]

PS: Just to be clear, having a keyword pi would still be better than having to type out this irrational constant as a long but approximate number everywhere.

[prlbr]

@Crissov The golden ratio is ½ + √(1+¼).

[Crissov]

Should this issue be reopened now that trigonometric functions are coming? #2331

[AmeliaBR]

@Crissov Maybe? Once we actually get implementations of the trig functions & feedback from people trying to use them, we will see if this is still a sticking point.

For myself, even with a pi constant, I suspect I would only use radian units in CSS if I had calculated an exact numeric value in other code. 0.25turn is so much easier than pi*0.5rad.

[tabatkins]

All the trig functions take both raw numbers and angles (turning those angles into numbers equal to their size in radians), so you can still just use turn as a 2*pi constant. (When I wrote my earlier comment about revisiting once trig functions are in, for some reasons I didn't expect us to allow angle units.) As @AmeliaBR says, if people end up using pi-ish numeric constants for other things often, we can definitely re-evaluate, but until we see some evidence of that, turn still suffices.

[Crissov]

For what itʼs worth, basically every CSS preprocessor (extension) that supports trigonometric functions also has a π constant (usually $pi) or parameter-less function (pi()), e.g.:

• Compass Sass extension
• Unintended: Trigonometry in Sass
• SCSS hack
• The Sass Way
• Team Sass: Sassy math
• Less out of the box

That is, admittedly, mostly because they need π for calculations themselves. Making it available to users is just a cheap extra, but I think we can assume that at least some authors do use it.

While I also saw e and φ in some of the above, I did not see τ, by the way.

[tabatkins]

All of those are doing math in raw numbers, where you do indeed need an actual 3.14 (or 6.28 if you want...) to do the math with. Thus, having a $pi or pi() makes perfect sense for them.

The CSS functions don't need that, since they have a unitted value and so you can just do your math in tauradians. Piradians would make the formulas accord to what you see in math textbooks slightly better, sure, but until we see people using these functions and complaining about it, we won't worry about adding a new "half-turn" unit.

[Crissov]

Indeed and I already acknowledged that those preprocessors inherently need a respective constant just as much as Javascript needs Math.PI (and perhaps Math.RAD_PER_DEG), while CSS has the conversion baked into units. My point was, that existing author experience with them could inform the design of future CSS features, even if common experience with math did not.

In the end, however, it still and as always comes down to whether browser vendors, who staff the CSSWG, consider the author benefits worth the implementation costs. Obviously, I am much in favor of additional convenience features like this. I reckon that there is overall agreement with the topic of this issue: rad as is can only reasonably be used by scripts, not by humans directly. We simply disagree whether this constitutes sufficient reason to add either another angular unit (which is a long established concept) or a numeric constant (which was proposed rather recently).

Btw., rad is of course [1] dimensionally, and someone could be inclined to argue that angles in CSS therefore should always be able to be expressed as plain numbers equaling radians, but we do have the precedent of hues in colors, which are interpreted as degrees when they are stated without a unit. Likewise, percentages are sometimes equivalent to floats, e. g. in alpha opacity values and almost in line-height, but not in general, because floats cannot be distinguished from integers which may have different interpretations, e. g. in RGB color notation.

[svgeesus]

Noting that the rest of the JS Math functions:

RESOLVED: add these 5 - abs, log, exp, and the two constants e and pi