- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 17:56:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-shapes-2][css-borders-4] corner-shape support for superellipsis`. <details><summary>The full IRC log of that discussion</summary> <emilio> smfr: there's a proposal to add a squircle function / different types of corner treatments<br> <emilio> ... there's also bevels / etc<br> <emilio> ... but more recently there's been a proposal of `superellipse` function<br> <emilio> ... which would allow those and also things in between<br> <emilio> ... including squircle<br> <emilio> ... wanted to give some background and some reservations I have about it<br> <emilio> ... this demo is using border-radius<br> <emilio> ... this is existing border-radius<br> <noamr> https://noamr.github.io/squircle-testbed/<br> <emilio> ... the "Apple rounded rect" is also a regular bezier point but with more control points<br> <emilio> ... There's some tricky cases with overlapping corners<br> <emilio> ... superellipse is this function that for a k=0 gets you bevel, with different ks you can get different joins<br> <emilio> ... with different ks you can get something like the squircle<br> <emilio> ... but now you got multiple parameters to change<br> <emilio> ... border-radius and the k<br> <emilio> ... it's not clear for authors which combination they'd choose<br> <TabAtkins> q+<br> <emilio> ... The other thing is that it's generated iteratively<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <TabAtkins> q+<br> <noamr> q+<br> <emilio> ... not using bezier curves, so not very efficient to render unless you approximate it using bezier curves<br> <astearns> ack noamr<br> <emilio> noamr: The proposal was also to add a squircle keyboard<br> <emilio> ... agreed with the perf concern<br> <emilio> ... specially stroking, filing should be fine with shaders<br> <emilio> ... for that reason I'm more inclined towards the apple-style continuous rect rather than superellipse<br> <astearns> ack TabAtkins<br> <emilio> ... on the other side I'd like more expresiveness for authors if we can solve the efficiency problem<br> <emilio> TabAtkins: in your later comments you said that to do a squircle you'd need both k and border-radius<br> <emilio> ... how does that work with just a squircle corner shape<br> <emilio> ... presumably the flat segment is specified by border radius<br> <emilio> smfr: yeah we apply the squircle only to the rounded corner area<br> <emilio> TabAtkins: ok so this is a different curve than superellipse<br> <weinig> q+<br> <emilio> TabAtkins: so in your preferred solution you have a small border radius with a separate knob<br> <emilio> smfr: right<br> <florian> q+<br> <emilio> TabAtkins: so this seems to be two parameters as well right?<br> <emilio> smfr: Only one parameter, which is border-radius<br> <emilio> TabAtkins: is it just because the squircle is a fixed pos?<br> <emilio> smfr: pretty much<br> <emilio> TabAtkins: it seems for fserb's proposal the squircle thing would just be a fixed k=4 right? So seems similar?<br> <emilio> ... so if you're using the fixed squircle shape you have only one free parameter<br> <emilio> ... the computational issues are a thing, but the parameterization seems fine to me?<br> <emilio> smfr: depends on how we want to expose this to CSS<br> <emilio> ... so adding squircle / bevel with keywords or something more flexible<br> <emilio> TabAtkins: I think fserb's proposal was to add keywords that computed to the superellipse parameters<br> <emilio> ... but I don't understand the calculus of the different params here<br> <emilio> ... so that might trump it<br> <astearns> ack weinig<br> <emilio> weinig: Is there any standardization in the design community outside apple / google that we could use here?<br> <emilio> smfr: I think there's a figma thing where they were looking at the apple one, but depends on which camp we're on<br> <emilio> weinig: Is there a built-in superellipse in illustrator on something?<br> <emilio> s/on/or<br> <emilio> smfr: not sure illustrator but figma and so do<br> <emilio> ... there's also the question of what authors want, just apple/google squircle or something else<br> <emilio> weinig: I don't think we want to hardcode the apple one, it could change in the future or what not<br> <emilio> smfr: I agree we don't want a single keyword that just gives you exactly the apple one<br> <emilio> ... we're fine with authors having to tweak border-radius or what not<br> <schenney> q+<br> <emilio> smfr: For IP reasons we don't want a single keyword that gives you the apple shape, but we're fine giving the corner treatment<br> <emilio> weinig: that makes sense, was trying to see what the non-app-icon use from authors would be generally useful<br> <noamr> q+<br> <emilio> smfr: And agree on let's not lock in on the current rounded icon format<br> <astearns> ack florian<br> <emilio> florian: what I like about fserb's proposal is that it gives keywords for things authors really want, and an underlying system<br> <emilio> ... to explore other bits<br> <emilio> ... not in a position to talk about performance, but I hope it can be fixed<br> <emilio> ... there are more knobs that your demo doesn't show (like each corner separately)<br> <astearns> ack schenney<br> <emilio> schenney: wanted to point out that animation is not being discussed yet, but an animation would lean towards a functional notation<br> <florian> s/like each corner separately/like each corner separately, or each side of each corner…<br> <emilio> smfr: agree, I think it's going to be possible to approximate superellipses with beziers<br> <kizu> q+<br> <emilio> ... I think it's tractable. Certainly more convenient with the k param<br> <astearns> ack noamr<br> <TabAtkins> q+<br> <emilio> noamr: From the perspective of how to bring this to the masses, I'd suggest to start with the continuous one and then build on top<br> <emilio> ... then try to figure out approximation of superellipse or what not<br> <emilio> ... thoughts?<br> <emilio> smfr: I agree we could do keywords first<br> <emilio> ... we'd have to think about animations<br> <emilio> ... maybe just discrete for now<br> <emilio> kizu: +1 to florian<br> <astearns> ack kizu<br> <kizu> https://github.com/w3c/csswg-drafts/issues/6980<br> <emilio> ... both the superellipsis and a set of keywords<br> <weinig> (likely the blog post from Figma smfr mentioned -> https://www.figma.com/blog/desperately-seeking-squircles/ )<br> <emilio> ... issue above has lots of comments about that<br> <florian> q+ to ask how bad is the performance problem<br> <astearns> ack TabAtkins<br> <emilio> ... so yeah would be good to have the functional version to create something more interesting<br> <emilio> TabAtkins: if the idea is that a superellipse does get decent results but is computationally intractable<br> <emilio> ... can we allow a degree of approximation in the spec so that you're allowed to approximate<br> <emilio> ... I think that is not very controversial<br> <emilio> ... so if beziers are tractable then we can just allow that<br> <emilio> smfr: I think that's fine, I just haven't done the math to approximate the conversion yet<br> <emilio> weinig: at the lower level most graphics libs are already doing approximations of these things<br> <emilio> ... I think there's unlikely to be a sever penalty<br> <emilio> TabAtkins: anything more rounded than a bevel needs an extra check for overlapping curves<br> <emilio> smfr: Right, we already have some constraints on rounded rects<br> <emilio> TabAtkins: right, but the border-radius overlap is trivial<br> <schenney> q+<br> <emilio> smfr: Yeah for the simple case we can probably check the rects<br> <emilio> ... maybe too restrictive<br> <emilio> smfr: [draws something]<br> <emilio> smfr: people want to do [that]<br> <astearns> ack florian<br> <Zakim> florian, you wanted to ask how bad is the performance problem<br> <TabAtkins> example is: border-radius of 0 100% 0 100%<br> <emilio> florian: unfortunate that fserb isn't here<br> <noamr> q+<br> <emilio> ... curious, were you talking about approximating any k with bezier?<br> <emilio> ... or just some k values?<br> <emilio> ... if the former that's great<br> <emilio> ... I think for superellipse() fserb had a reasonable implementation<br> <astearns> ack schenney<br> <emilio> smfr: Haven't tried generic k -> bezier conversion<br> <emilio> schenney: it's not so much whether you can but how expensive the approximation is<br> <emilio> ... even now with the existing rounded corners I'm 99% sure that there are still issues in browsers with border-width<br> <emilio> ... so the interaction with border-width makes this trickier<br> <emilio> ... certain border widths + radius cause this to be tricky, so would be good to consider it<br> <emilio> smfr: agreed<br> <astearns> ack noamr<br> <emilio> noamr: we're not going to solve the computational issue in this meeting. Perhaps we should limit this to determine that we want the parametric superellipse() if achievable<br> <emilio> ... have a rough CSS syntax for it and we can adjust based on implementability<br> <emilio> astearns: was thinking of an even smaller step of starting with keywords, described in terms of superellipse<br> <emilio> TabAtkins: that doesn't allow for smooth transitions in the future<br> <smfr> q+<br> <emilio> astearns: if we're defining keywords in base of the superellipse, don't you get that?<br> <emilio> TabAtkins: but the interpolation wouldn't be expressable until we get the function version<br> <emilio> smfr: unless we do mix() function magic...<br> <astearns> ack smfr<br> <emilio> ... before resolving corner-shape, we probably want to decide whether we want border-shap<br> <emilio> ... because they have interactive functionality<br> <emilio> astearns: #6997?<br> <emilio> smfr: yeah, would be nice to get leaverou's opinion about this too<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10993#issuecomment-2622452204 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 January 2025 17:56:28 UTC