# [css-values] Radians considered useless without π #309

Closed
opened this Issue Jul 11, 2016 · 35 comments

Projects
None yet
10 participants
Contributor

### Crissov commented Jul 11, 2016 • edited

 `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`).
Member

### tabatkins commented Jul 12, 2016

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

### tabatkins self-assigned this Jul 12, 2016

Contributor Author

### Crissov commented Jul 12, 2016

 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 commented Jul 12, 2016 • edited

 `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.
Contributor Author

### Crissov commented Jul 12, 2016

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

### tabatkins commented Jul 14, 2016

 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. ^_^
Contributor Author

### Crissov commented Jul 14, 2016

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

Open

### Crissov referenced this issue Aug 3, 2016

Open

#### [css-syntax][css-values] Awkward Decimal Fractions and Non-Finite Values #378

Contributor Author

### Crissov commented Dec 20, 2016

 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`.

Merged

Closed

Closed

Closed

Contributor

### grorg commented Sep 6, 2017

 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.

### astearns added the Agenda+ label Sep 7, 2017

Contributor Author

### Crissov commented Sep 7, 2017

 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.
Member

### tabatkins commented Sep 7, 2017

 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".)
Contributor Author

### Crissov commented Sep 8, 2017

 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.)
Member

### tabatkins commented Sep 11, 2017

 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.
Member

### css-meeting-bot commented Sep 13, 2017

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

### fantasai closed this Sep 13, 2017

Contributor Author

### Crissov commented Sep 13, 2017 • edited

 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.
Member

### tabatkins commented Sep 13, 2017

Contributor Author

### Crissov commented Sep 13, 2017

 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”.
Member

### tabatkins commented Sep 13, 2017 • edited

 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. ^_^

### tomhodgins referenced this issue Sep 14, 2017

Open

#### [css-values] A more reasonable unit for `letter-spacing` #1814

Contributor Author

### Crissov commented Sep 14, 2017

 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.
Contributor

### svgeesus commented Sep 14, 2017

 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 😵: #1814 (comment)
Collaborator

### Loirooriol commented Sep 16, 2017

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

### tabatkins commented Sep 19, 2017

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

### Crissov commented Sep 19, 2017

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

### Loirooriol commented Sep 19, 2017 • edited

 @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.
Contributor Author

### Crissov commented Sep 20, 2017

 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.
Member

### tabatkins commented Sep 21, 2017

 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.)
Contributor Author

### Crissov commented Sep 22, 2017

 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.
Member

### tabatkins commented Sep 22, 2017

 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.)
Contributor Author

### Crissov commented Sep 22, 2017

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

### tabatkins commented Sep 25, 2017

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

### AmeliaBR commented Sep 26, 2017

 Registering a vote for the `constant(pi)` notation, or `env(pi)` based on the resolution to #1693 (comment). 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.
Contributor Author

### Crissov commented Sep 26, 2017 • edited

 @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 `` on at least one side. ` * ` 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.
Contributor Author

### Crissov commented Sep 26, 2017 • edited

 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 commented Sep 26, 2017

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

### Crissov referenced this issue Feb 17, 2018

Closed

#### [css-values] Trigonometric functions #2331

Contributor Author

### Crissov commented Mar 1, 2019

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

### AmeliaBR commented Mar 1, 2019

 @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`.