- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 18:58:03 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-shapes-2][css-borders-4] corner-shape support for superellipsis`, and agreed to the following: * `RESOLVED: Add corner-shape: superellipse(k) and bevel / scoop / notch / round / squircle based on it, maybe continuous in the future` * `RESOLVED: Add restrictions to avoid intersecting borders with scoop-like corners, specifics TBD` * `RESOLVED: Initial value of corner-shape is round` * `RESOLVED: corner-shape has longhands like border-radius` <details><summary>The full IRC log of that discussion</summary> <emilio> PROPOSED: Add corner-shape with superellipsis() in some form<br> <emilio> florian: [summarizes prev discussion for fserb]<br> <emilio> fserb: is this because of how I implemented it on the demo or...?<br> <emilio> smfr: q is whehter the iterative solution can be approximated to a bezier<br> <emilio> fserb: I think so because you have the parameterized distance<br> <emilio> ... can work on it a little bit<br> <emilio> ... doesn't have to be as awful as in the demo<br> <emilio> smfr: that sounds promising<br> <emilio> PROPOSED: Add corner-shape with superellipsis() in some form, maybe keywords<br> <emilio> noamr: maybe continuous to approx the apple curve<br> <fserb> q+<br> <emilio> florian: unsure if that's needed given our discussion and k=4 being really close<br> <emilio> smfr: do we have resolutions for bevel / scoop / etc?<br> <emilio> astearns: we didn't resolve on anything yet<br> <bramus> emilio: does not mean tha tif you add the keywords then add the function<br> <bramus> florian: ?? compat problems<br> <bramus> emilio: already ??? between discrete values<br> <emilio> smfr: seems premature to add superellipse() if we don't have the basic keywords yet<br> <noamr> +1 to starting with keywords<br> <emilio> florian: but if you do it then you can't animate<br> <astearns> ack fserb<br> <emilio> emilio: but you'd be able to once you introduce the functional version<br> <emilio> fserb: I think we should have both but it'd be weird to have only the keywords<br> <noamr> any reason not to have both in the spec?<br> <emilio> ... I think we should introduce the obvious keywords, but we should also have the superellipse() one<br> <emilio> astearns: I think even if we only have those keywords we should define those in terms of superellipse()<br> <emilio> fserb: unrelated, did we discuss about what happens about intersecting borders inside?<br> <emilio> ... are we going to tweak border-width / radius to avoid it?<br> <emilio> smfr: we decided we'd add constraints, but handwaved<br> <bramus> emilio: should we propose that as a resolution? add restirctions to prevent some things.<br> <fserb> +1<br> <emilio> florian: I'd prefer to add corner-shape: superellipse() + some keywords based on superellipse()<br> <emilio> noamr: should we resolve on the specific keywords?<br> <emilio> astearns: fine with editor discrection<br> <astearns> ack fantasai<br> <emilio> fantasai: there are keywords in the draft that map to this<br> <emilio> astearns: can you list them?<br> <emilio> smfr: probably bevel / scoop / notch / round?<br> <bramus> emilio: is the initial value round?<br> <bramus> … with this proposal we make it interact with border-radius<br> <noamr> + squircle<br> <fserb> scoop = -round ?<br> <emilio> PROPOSAL: Add corner-shape: superellipse(k) and bevel / scoop / notch / round / squircle based on it, maybe continuous in the future<br> <fserb> \o/<br> <emilio> RESOLVED: Add corner-shape: superellipse(k) and bevel / scoop / notch / round / squircle based on it, maybe continuous in the future<br> <emilio> PROPOSED: Add restrictions to avoid intersecting borders with scoop-like borders<br> <emilio> PROPOSED: Add restrictions to avoid intersecting borders with scoop-like corners, specifics TBD<br> <emilio> RESOLVED: Add restrictions to avoid intersecting borders with scoop-like corners, specifics TBD<br> <emilio> florian: current draft has angle rather than bevel<br> <emilio> TabAtkins: editor discretion seems fine<br> <emilio> [general agreement]<br> <emilio> emilio: Initial value should be round so that border-radius does the right thing right?<br> <bramus> emilio: can we define none in terms of superelipse?<br> <emilio> noamr: maybe none for when there's nothing going on with the corners<br> <bramus> smfr: yes<br> <emilio> smfr: that's a bit different from animating radius<br> <bramus> florian: are we also resolving that we have between 1 and 4 keywords and that they ??? a notch here and a rounded corner there<br> <emilio> noamr: it'd be superellipse(calc(inf))<br> <bramus> …or do we worry about that later?<br> <emilio> RESOLVED: Initial value of corner-shape is round<br> <bramus> noamr: have corner-shape for corners spearately following model of border-radius<br> <bramus> emilio: so corner-top-=left-shape and so on?<br> <bramus> florian: same thing as border-radius<br> <bramus> emilio: makes me sad that the prop deos not start with border-<br> <bramus> florian: what makes me sad is that border-radius is not corner-radius<br> <bramus> ntim: can add an alias<br> <emilio> PROPOSED: corner-shape has longhands like border-radius<br> <ntim> ntim: like we did for font-stretch/font-width<br> <emilio> weinig: Spec has a corners shorthand, but no need to discuss it<br> <emilio> RESOLVED: corner-shape has longhands like border-radius<br> <jfkthame> present-<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-2622578937 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 18:58:04 UTC