- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Apr 2025 15:13:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-borders-4] Resolve on range for `superellipse` parameters``, and agreed to the following: * `RESOLVED: Use the log2 range for the superellipse parameter` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> noamr: this and the next issue will resolve togheter<br> <TabAtkins> noamr: smfr and i have been working hard on the details for corner-shape. several questions to resolve<br> <TabAtkins> noamr: one is about the superellipse paramter<br> <TabAtkins> noamr: as you might recall, we have corner-shape keywords, but can also give it a number via a super-ellipse function<br> <TabAtkins> noamr: in the spec righ tnow, the number gives the exponent of the curvature<br> <TabAtkins> noamr: there was a proposal to use the log2 of that<br> <TabAtkins> noamr: if i go all the way to concave, k=0, log2=-inf<br> <TabAtkins> noamr: middle, bevel, k=1, log2=0<br> <TabAtkins> noamr: full sharp convex, k=inf, log=inf<br> <TabAtkins> noamr: round, k=2, log2=1<br> <TabAtkins> noamr: squircle, k=4, log2=2<br> <TabAtkins> noamr: there's a table in the issue<br> <TabAtkins> noamr: so the log2 version goes from -inf to inf, and maybe a bit more friendly<br> <TabAtkins> noamr: k version goes 0-inf<br> <astearns> https://noamr.github.io/squircle-testbed/corner-visualizer/corner-animation.html<br> <TabAtkins> noamr: advantage of k version, when people talk about super-ellipses in other contexts they're usually talking just about the k version<br> <TabAtkins> noamr: but i don't feel strongly about either<br> <TabAtkins> q+<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: I do feel strongly that the log2 version is better here, because the shapes are symmetrical across the bevel<br> <fantasai> TabAtkins: It also makes the range of useful values more reasonable. Going out to log2=10 makes it effectively a sharp corner, and the range past there is infinite<br> <fantasai> TabAtkins: Same thing applies in negative direction.<br> <fantasai> TabAtkins: This is easy to work with.<br> <fantasai> TabAtkins: in the straight K version, sharp corner is a non-obvious fraction slightly above zero...<br> <fantasai> TabAtkins: Symmetry really helps out with usability. Can put a note in the spec that k in academic papers is usually different, but for authors they won't care. We should prioritize usability for authors, and log2 variant gets us there<br> <TabAtkins> fantasai: +1<br> <bramus> +1<br> <TabAtkins> noamr: literature could be Figma, for example<br> <TabAtkins> noamr: author tooling can expose it too<br> <Kurt> q+<br> <astearns> ack Kurt<br> <TabAtkins> Kurt: does this mean specifcying infinity you need to use calc()?<br> <TabAtkins> noamr: no, can just have an infinity keyword<br> <TabAtkins> noamr: that's in the spec right now for positive infinity<br> <TabAtkins> noamr: i think people are okay with this not aligning with other tools i'm okay with going with log2<br> <TabAtkins> s/think people/think if people/<br> <TabAtkins> astearns: so it sounds like proposed is to use log2 range?<br> <TabAtkins> jensimmons: would like to know what smfr thinks?<br> <TabAtkins> noamr: he's commented on the issues, he doesn't have a strong opinion<br> <TabAtkins> q+<br> <fantasai> TabAtkins: There's an interpolation issue later on...<br> <lea> weak agree for the log2 version from me too<br> <fantasai> TabAtkins: Other reason I really like log2, when we do interpolation, making sure that works symmetrically requires doing log2 anyway<br> <fantasai> TabAtkins: so exposing more directly to authors is a good thing<br> <TabAtkins> noamr: yeah, the interpolation function si clsoe to log2<br> <TabAtkins> astearns: so it sounds like people are moderate to weakly in favor of log2<br> <TabAtkins> fantasai: i think tab's arguments are convincing to me<br> <TabAtkins> astearns: so proposed reoslution is to use the log2 range<br> <TabAtkins> RESOLVED: Use the log2 range for the superellipse parameter<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11609#issuecomment-2769712709 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 April 2025 15:13:59 UTC