Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Crissov opened this Issue Jul 11, 2016 · 35 comments

Comments

Projects
None yet
10 participants
@Crissov
Copy link
Contributor

commented Jul 11, 2016

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

This comment has been minimized.

Copy link
Member

commented Jul 12, 2016

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

@tabatkins tabatkins self-assigned this Jul 12, 2016

@Crissov

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link

commented Jul 12, 2016

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

This comment has been minimized.

Copy link
Contributor Author

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.

@tabatkins

This comment has been minimized.

Copy link
Member

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

@Crissov

This comment has been minimized.

Copy link
Contributor Author

commented Jul 14, 2016

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

@Crissov

This comment has been minimized.

Copy link
Contributor Author

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.5turn3.141rad, just like 1° = 1deg.
@grorg

This comment has been minimized.

Copy link
Contributor

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 astearns added the Agenda+ label Sep 7, 2017

@Crissov

This comment has been minimized.

Copy link
Contributor Author

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.

@tabatkins

This comment has been minimized.

Copy link
Member

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

@Crissov

This comment has been minimized.

Copy link
Contributor Author

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

@tabatkins

This comment has been minimized.

Copy link
Member

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.

@css-meeting-bot

This comment has been minimized.

Copy link
Member

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 <dael> topic: Radians considered useless without π
<dael> github: https://github.com//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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 13, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 13, 2017

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

@Crissov

This comment has been minimized.

Copy link
Contributor Author

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

@tabatkins

This comment has been minimized.

Copy link
Member

commented Sep 13, 2017

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

This comment has been minimized.

Copy link
Contributor Author

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.

@svgeesus

This comment has been minimized.

Copy link
Contributor

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)

@Loirooriol

This comment has been minimized.

Copy link
Collaborator

commented Sep 16, 2017

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

This comment has been minimized.

Copy link
Member

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

@Crissov

This comment has been minimized.

Copy link
Contributor Author

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?

🤦

@Loirooriol

This comment has been minimized.

Copy link
Collaborator

commented Sep 19, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

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.

@tabatkins

This comment has been minimized.

Copy link
Member

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

@Crissov

This comment has been minimized.

Copy link
Contributor Author

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.

@tabatkins

This comment has been minimized.

Copy link
Member

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

@Crissov

This comment has been minimized.

Copy link
Contributor Author

commented Sep 22, 2017

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

@tabatkins

This comment has been minimized.

Copy link
Member

commented Sep 25, 2017

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

This comment has been minimized.

Copy link
Contributor

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.

@Crissov

This comment has been minimized.

Copy link
Contributor Author

commented Sep 26, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 26, 2017

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

This comment has been minimized.

Copy link

commented Sep 26, 2017

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

@Crissov

This comment has been minimized.

Copy link
Contributor Author

commented Mar 1, 2019

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

@AmeliaBR

This comment has been minimized.

Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.