[css-values] Trigonometric functions

[LeaVerou]

I keep stumbling on use cases that need trigonometric functions to be solved, and I always have to resort to JS or a preprocessor for them, which is a pain. Basically almost any time you need to match two things and angles are involved.

Sadly I couldn't find most of my use cases, but here are two:

• https://codepen.io/leaverou/pen/JpyZMO - cos, atan (via JS)
• play.csssecrets.io/folded-corner-realistic — sin, cos (precomputed)

Also the following use sqrt (precomputed), but would need trigonometry in the general case :

• play.csssecrets.io/inner-rounding
• play.csssecrets.io/diamond-images
• play.csssecrets.io/bevel-corners
• play.csssecrets.io/folded-corner

(credits: @MeFoDy for collecting these from my book)

What do you think? Can we make it happen?

My primary use case is for syncing rotation angles and scale factors or translation distances when I animate multiple elements such that corners/ edges match throughout the animation.

In this demo, I need to sync the rotation angle of the bright yellow squares and the post-skew scale factor of the orange squares. This is achieved by doing the trigonometric computations in the JS and then setting the values to the custom properties used in the transform.

A way to do it all from the CSS would be immensely useful.

I can try to fake it with different timing functions for rotation angles and scale factors or translation distances as I did in this demo, but that's just hardcoding the cubic-bezier() for every case.

[Crissov]

Adding these would require a solution to enter π other than 0.5turn etc. #309

[LeaVerou]

Adding these would require a solution to enter π other than 0.5turn etc. #309

Um, why? (Yes, I did read the issue you linked to)

[MeFoDy]

Some awesome use cases in presentation by @askd:

Triangle

/* http://askd.rocks/pres/css/#triangle */
.triangle {
  position: relative;
  width: var(--w);
  height: var(--h);
  overflow: hidden;
}
.triangle::before {
  --a: arctan(calc(var(--w) / var(--h)));
  content: '';
  position: absolute;
  left: 100%;
  width: 100%;
  height: calc(100% / cos(var(--a)));
  background: #000;
  transform-origin: 0 0;
  transform: rotate(var(--a));
}

Parallelogram

/* http://askd.rocks/pres/css/#parallelogram1 */
.parallelogram {
  --w: 400;
  --h: 200;
  position: relative;
  width: calc(1px * var(--w));
  height: calc(1px * var(--h));;
}
.parallelogram::before {
  --angle: arcsin(calc(var(--h) / var(--w)));
  content: '';
  position: absolute;
  width: calc(100% - 100% * var(--h) / var(--w) * tan(var(--angle)));
  height: 100%;
  transform-origin: 0 100%;
  transform: skew(calc(0 - var(--angle)));
  background: #000;
}

Diagonal background animation inside the button

/* http://askd.rocks/pres/css/#example1 */
.button {
  --h: 4em;
  height: var(--h);
  padding: 0 calc(var(--h) * tan(32deg));
  font-size: 40px;
  line-height: var(--h);
  overflow: hidden;
  text-align: left;
}

[Crissov]

@LeaVerou Because @tabatkins said so in #309 (comment)

[liamquin]

On Sat, 2018-02-17 at 13:45 -0800, Christoph Päper wrote: @LeaVerou Because @tabatkins said so in https://github.com/w3c/csswg- drafts/issues/309#issuecomment-330652717

Tab made a compelling case for wanting pi as a constant; others felt a unit would be better. But even Tab admits it's not strictly _necessary_. That is, you could add sin, cos, tan, atan, sqrt, pow, exp, without adding numeric constants. And maybe --pi works for now.

…

-- Liam Quin, W3C, http://www.w3.org/People/Quin/ Staff contact for Verifiable Claims WG, SVG WG, XQuery WG Improving Web Advertising: https://www.w3.org/community/web-adv/ Personal: awesome vintage art: http://www.fromoldbooks.org/

[AmeliaBR]

I also periodically come across situations in CSS -- and very often in SVG -- where trig functions would be very helpful for converting between angles and x/y dimensions.

In static markup, the solution is to hard-code approximate values, but that often leaves pixel gaps or discontinuities from rounding errors. In dynamic situations, as others have mentioned, the only solution is JavaScript (with lots of converting back and forth between radians for the JS functions and degrees or turns for my design and for SVG properties, which is the only time I usually need Math.PI!).

I would argue for adding the trig functions and then wait and see how much demand there is for pi constant, or a root-2 constant. As Liam notes, an author could always define an arbitrary-precision constant as a custom property.

And most importantly, separating out the two features means that we could move ahead with functions without having to first decide the best syntax for constants.

[Crissov]

Which exact functions are proposed here? sin(), cos(), arctan() – tan(), arcsin(), arccos(), …?

Several programming languages distinguish two arcus tangens functions: atan() with a single parameter and atan2() with two parameters.

(A generic (square) root sqrt() or exponent exp() or power pow() function or a specific square root of two constant deserves its own issue.)

[ewilligers]

I use sqrt(3) for 30/60 degree angles just as much as sqrt(2) for 45 degree angles.

The MVP might be sin() cos() tan() arcsin() arccos() arctan() arctan2() sqrt().

Authors and libraries can use these to define --pi, the golden ratio and --degreesPerRadian.

[Crissov]

Why would anyone ever need to manually specify --degreesPerRadian when CSS has angular units? @ewilligers

[tabatkins]

@ewilligers Yeah, that set looks useful as a first pass. More general roots and powers might be useful in the future, but we should wait and see what the uptake is on these; they cover the vast majority of what you want to do in trig.

(I'd prefer the asin/etc wording, to match JS.)

As @AmeliaBR suggests, we can leave off constants for now. I think it's probably best to address them thru the env() function, as that nicely namespaces them for use everywhere.

[Nadya678]

Moz has defined: sin, sinh, cos, cosh, tan, tanh, atan, atan2, atanh... Cr also. In JS. I think names for CSS can be the same. Easier to remember.

[fuchsia]

hypot would be nice, too - even if it's restricted to two args, My javascript uses hypot three times more often than sqrt; it's also fewer characters to type than sqrt( x * x + y * y ), more clearly expresses the intent, and can be more accurate than the naive implementation.